LEGO NXT - Datalog ability - adjustments of external mode or other solutions?

My question is related to the datalog ability with external mode turned on. What is the sampling rate for the recieved data in the simulink scope? And is there any way to influence this rate?

My problem is that i have a highly dynamic system and i need a high sampling rate for the sensor input signals. With external mode enabled task overruns are very likely to occur, but disabling the external mode is not a solution for me.

The best solution would be if there was any offline datalog solution. So you can save the data on the nxt brick and retrieve it afterwards. I know that the original firmware supports this, but i couldn't find any solution in simulink or even in the api the used firmware offers. Is there any way to implement this?

The other approach i would like to try is to decrease the "communication rate" between simulink and the nxt brick. This would be also satisfying as i only need to get an idea of what is going on. If the sensor values are drifting away i.e. And therfore the time sampling rate does not have to be as high as for the computing algorithm running on the brick. Is there any way to control this?

Answer 1

[Guy Rouleau]

Here are a few info that might help you based on my experience:

- Typically, external mode is a lower priority process. If you model has a fast sample time, external mode values will be dropped and sent "only when there is time". In my experience, if I go 4ms for a model, I begin to loose a lot of points, but I don't see overrun on the target.

- I do not know if any way to store data on the brick with the Simulink NXT support package.

- External Mode will send data at the rate of the Sink block. If you use a scope, you use the Decimation or sample time property of the scope to control that.

- As for alternate approach, I like to use the Bluetooth blocks. Those are designed to communicate between bricks, but with a bit of work it is possible to receive the packets on the host. This is significantly more lightweight than external mode and will not drop packets.

[Dominik]

Thank you for your quick and helpful answer! I had no time to try your ideas yet so i can't confirm if it solves my problem, but at least it gives me a much better insight in what is actually going on. I also already thought of using the Bluetooth blocks, but I didn't focus on this approach because i was not convinced enough that it will give me a better performance. What configuration do you use to recieve the Bluetooth packets on the host? Does MATLAB/Simulink offer proper interfaces or do i have to write my own client, i.e. with Python and do the further processing with i.e. numpy?

[Guy Rouleau]

Here are a few options to get the data in MATLAB:

- With MATLAB, you can use basic fopen/fread/fclose to open the serial port and get the data.

- The Instrument Control Toolbox has functions to interface directly the bluetooth connection. I personally never used those, but I heard they can work.

- If you dig through the files in the following MATLAB Central submission, you will find example MATLAB scripts and mex-file that you can use to directly the bluetooth. I have used those extensively with the Simulink support package for Lego NXT.

http://www.mathworks.com/matlabcentral/fileexchange/13399-embedded-coder-robot-nxt-demo

Answer 2

[Dominik]

So i decided to try your version 3.

It took me all day long to understand your approch and to implement it myslef. Actually i didn't have an idea about what .mex files are and all this other matlab magic, but I got it working finally. I am not completly satisfied at the moment, but my method could still use some refinement.

To resume:

NXT-Brick side:

I use the Simulink support package for Lego NXT. There i use the 'Bluetooth Outbound Mailbox' with the 'Mailbox Nr.' set to 1. The inport is connectet to a MUX-Block where i 'append' all the signals which i want to transfer simultaneously. The MUX-Block only accepts data of the same datatype, therefor i have to convert the different signals into one uniform datatype. I use the Conversion Block for this task, and select the option not to change the byte representation. My 'transfer datatype' of choice is 'int32'.

MATLAB side:

I downloaded the package you pointed me to and took the w32serial function from it. I use it to establish a connection on the proper COM port and have a infinite loop reading the bytestream recieved and writing it to a file. The file created is the raw byte stream recieved.

I created a function to extract the data from this byte file. There i use the knowledge about the package format and the typecast function to get the proper representation of the byte data.

Problems:

The packages are not corrupt but the data does not arrive at its send order. Actually i think that this isn't any faulty behaviour, but just the way bluetooth works. Therefore i use the Timer-Block to send a timestamp with every package. My Simulink modell is pretty simple. I use 3 input blocks(timer, gyro, rotary encoder), draw the signal value on the display and transfer them after conversion to the 'bluetooth mailbox'. The sampling time is 0.1ms for the whole circuit. So if i order my recieved data, the difference between two neighbour packages should be 100ms. This is true for about half of the packages, but there are a lot of gaps in between. varying from 150-250ms.

And there is another thing wich makes me curious: I get a lot of packets with the same timestamp. Some of them are just duplicates, but there are even some which vary in the sensor data. How can this happen?

"statistical data":

observing time: 30.5s

packets recieved: 307

unique timestamps: 268

duplicates: 39

[Guy Rouleau]

It is good to see that you figured how to implement what I described. I agree that this is not something straightforward that work out of the box.

About your latest problem, I am surprised... I never had timing problems like what you describe. I used this technique with a model sampled at 4ms and logging the timer block always gave me 4ms as expected, unless I put too much computation and got overrun.

As you probably know, it is difficult to debug timing problems with sensor blocks because they depend on external factors. What if you send through Bluetooth the Timer block, the Discrete Clock from the Simulink library and let's say a counter which increment by one every step. How does that match?

[Dominik]

Got it!

I changed the sampling time to 500ms and still observed timing problems like mentioned before. It started messed up, worked pretty well in between for about 10 values, was messed up again, was ok again, and so on.

After looking at the raw byte data in binary format i found some pattern and finally found the underlying problem: the datatype conversion!

The simulink part works fine. As i preserve the underlying byte presentation, the conversion is more of a cosmetic thing.

The serial stream to file conversion is the bogeyman. I recieve packets with the fopen function on the w32serial object. As there is no 'byte' datatype i thought that any 8 bit datatype will work and my choice was 'int8'. But I did not care about it while calling the fwrite function on the file object. This messed the data up and caused this wierd number behaviour. Now everything works as expected, the packets are well ordered and equally spaced even with a 4ms sampling time.

It is more of a "beta" than a satisfing and well programmed solution but it works nicely for now and i can finally start with the real project ;)

Thank you for your support and guiding me the right way!

[Guy Rouleau]

Thanks for sharing your adventure.. I hope it can help others!

[Alexander]

Dear Guy Rouleau,

I am working now on my Thesis in Germany and have to programm a Lego NXT made roboter with the VU-LRT Toolbox. I made already some schorts programm but they didn't work. May be you could help me. I received always the same error:

1-The call to lrt_make_rtw_hook, during the after_make hook generated the following error: Build failed during Make all

The build process will terminate as a result.

2-Build failed during Make all

3-Parsing successful for chart: "Messwerte/Packet"(#21)

Please could you help me Thank you for all

Alex

[Shivanand]

Hello Alex,

I am also working with VU-LRT, I have installed program on NXT the data is also displayed on Matlab but i couldnt save this data. When i added more blocks like Timer, Scope it gives errors as enlisted by you. Please tell me if you get any answer to resolve this issue.

-Shiv

[Shivanand]

 Hello Rouleau,
I could recieve packets on my PC connected to NXT using USB Blocks.
The packets are displayed on matlab screen.
I want to store the data recieved for different sampling time to check wheather the data recieved is complete or it has some lapses.
How should i do that?
Please help me.

-Shiv