Lab View Ground Station time lag cut to less than 1/2 second.

GSmphFT.vivideo_2010-03-16_00.07.44.m4v

After playing with lab view and the ArduPilot with the ArduIMU I have finally managed to get the time lag from the plane to the displayed action on the GroundStation to less than a half a second.
New VI file 1 AM 3/17/2010
Here is my rather crude video.

Earl

Here is the new VI for labview
The file name GS = Ground Station mph = Miles per hour FT = feet

GSmphFT.vi

Here is my latest version.
GSmphFT2.vi

Views: 263


3D Robotics
Comment by Chris Anderson on March 16, 2010 at 7:59am
Congrat's Earl! Once you get some sleep, can you tell us what the trick was?

Admin
Comment by Morli on March 16, 2010 at 10:07am
looks almost real time, congrats , looking forward to see the magic & implement

Developer
Comment by Jason Short on March 16, 2010 at 10:41am
Was it some type of buffer issue?
I know from other implementations of Serial into PCs that the input buffer will try and fill to a certain amount before it's read in. On mine I look for specific characters like null or \10\13.

Developer
Comment by Mark Colwell on March 16, 2010 at 11:20am
Earl mentioned buffer was too big.
Comment by Earl on March 16, 2010 at 1:10pm
Here is what I changed .
Earl

GndSta.JPG
Comment by Earl on March 18, 2010 at 4:35pm
On further investigation, the one that made the most difference is what was a 10 (line feed) detection in the serial stuff.
Changing it to a 1 (?? null ??) seamed to do the speed up.
We need a Labview person to figure out what I ACCIDENTALLY got to work !
Earl

Earl
Comment by Morli_ on March 18, 2010 at 4:39pm
good accident Earl , pls keep doing it ;-)
Comment by Earl on March 18, 2010 at 5:24pm
I am downloading my Labview 9 update because I have 8.6
The GCS beata3 was made with LV9.
Glad I have a student edition I bought !
Earl
Comment by tychoc on March 18, 2010 at 6:56pm
Earl,

I work as a software engineer in LabVIEW R&D at National Instruments in Austin. I can probably help a little with this code, however, there're several SubVIs missing. Do you have the whole project accessible somewhere? There seems to be some opportunity for cleaning up this code :)

-tychoc
Comment by automatik on March 18, 2010 at 11:48pm
Ok,
based on the Earl's picture (I don't have time to 'debug' the code now, maybe over the weekend...)


All of my comments are applicable to our specific case and component performances and not general form ( i.e. applicable to every conceivable device with serial port :) )


- "512" by the 'VISA Serial' vi ( "white box") - that's timeout value. I think Jordi originally had 3000. What that setting does is to instruct a serial port how long to wait before timing out for read operation ( and write but we don't write yet...). So if serial port has nothing to read for 512ms it will indicate timeout notification/error ( Jord's was 3 sec ). If everything is OK, both values will perform the same since in our case data coming from AP is more frequent. This setting DID NOT improve GCS speed

- 512 by the yellow box and I/O Buffer text in the lower right corner ( it's a VISA Set I/O Buffer Size) - This sets serial IO buffer size. Default is 4k (if function is used but value not wired, otherwise it will depend on some other configurations) and '512' sets it to 512bytes. In some application if buffer size is wrong ( not optimal) in can cause problems but I doubt this is the case here...Also I am not 100% sure that FTDI driver supports custom buffer size allocation, but I suspect that it does. Termination character is enabled and serial port should of stopped reading the message ( data from AP) when it received it. It would send it GCS application, and start reading the data again until another termination character came along ( see next point for termination character). AP data is typically less then 4k ( default) or 512b, and with termination character enabled, this doesn't come into play (if number was set lower to 50b or 80b it would be an issue - I forgot exactly how big is the longest AP data string...)

- Termination character - That' s "1" in the little blue box. Originally it was set to 0xA (hex) or decimal 10. 0xA ( or 10 ) is representation of line feed character ( \n). That means that serial port will stop reading incoming data ( and send it to GCS) when it encounters linefeed in AP data stream. Linefeed is part of Serial.println command in Arduino environment. So in Arduino code, when you Serial.println ("something here");
this is what's send out over the serial line
something here \n\r or something here linefeed carrige return

By changing termination character from '10' to '1' you are basically telling serial port " every time you see number one stop reading and send data out" . So if you have attitude data coming in that looks like
+++ ASP: 25, THH:30, RLL:11, PCH: 10, ***
you are telling serial port to stop reading and send data out 3 times...

So why does GCS with this code change appear faster ? I have to look at the code before I say for sure but I suspect that some data might be lost/discarded, hence not processed, hence things run faster...Again this is just speculation at this point until I look at the code


I do not think that this is correct way of doing things ( i.e using 1 as a termination character).

In my opinion, observed lag in original GCS code is in part due to things being done sequential (i.e everything needs to finish ( as in display, calculations, etc.) before new data is acquired ) and display of artificial horizon for pitch and roll - it's a picture that is manipulated and operations are performed on pixel by pixel basis which takes a loooong time. So over time data read operations can not keep up and things start to lag ( i.e buffers get full, maybe even on the Arduino/GPS as well...)

With new GCS ( coming out soon ! ) among other things, architecture is changed and things are done in parallel, there is no pixel by pixel manipulations, I did change termination character though but for different reasons, etc. With new GCS code I did not experience any human noticeable data lag after one hour of continuous operation ( there is some Tx/Rx delay as in any system, nothing is instantaneous....). I am still doing some testing on this....

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service