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
Comments
"So can we use the "===" or a single "=" as the termination char ?"
I used "=============" just as a visual separator of the received data not as a line character
If data is arriving faster than groundstation can process it then data will always be lost.
Earl's method loses data as it goes, but the data that is parsed is always up to date.
With the linefeed character as a terminator the rx buffer will gradually fill until it is full and then incoming data will be lost. This will not be noticable as groundstation is still processing complete lines from the back of the buffer 6s behind where the data is being dropped. Because you are reading from a full buffer it can always find a complete line to parse.
Earl
Looking foward to the new GCS software.
Earl
I see that termination character was changed from 1 to 2 ( GSmphFT.vi and GSmphFT2.vi respectively in Earl's code). However it appears that 1 or 2 are not recognized as valid termination characters....which makes sense oterwise serial port might be terminating read on valid data....
So this code appears faster because it does not process ( parse-out, display, etc. ) all the data.
I modifies the code to see exactly what comes out per each read - I added "===========" after each serial port read. Since termination character is not valid, and Serial Read requests 200 bytes, code tries to deliver 200 bytes, or as much of 200b as it can before timing out ( 512ms).
So practically this is what's happening ( don't mind the numbers, this was done on the bench and not real flight..)
=============
Ready to FLY.
+++ASP:0,THH:1,RLL:11,PCH:-11,***
+++ASP:0,THH:2,RLL:
=============
11,PCH:-11,***
+++ASP:0,THH:3,RLL:11,PCH:-11,***
+++ASP:0,THH:4,RLL:11,PCH:-11,***
+++ASP:0,THH:5,RLL:11,PCH:-11,***
+++ASP:0,THH:6,RLL:11,PCH:-11,***
=============
!!!LAT:37632179,LON:-122491289,SPD:0,CRT:0,ALT:18,ALH:54,CRS:173,BER:0,WPN:7,DST:0,BTV:10,RSP:0,***
+++ASP:0,THH:7,RLL:11,PCH:-11,***
+++ASP:0,THH:8,RLL:11,PCH:-11,*
=============
**
+++ASP:0,THH:9,RLL:11,PCH:-11,***
+++ASP:0,THH:10,RLL:11,PCH:-11,***
+++ASP:0,THH:11,RLL:11,PCH:-11,***
+++ASP:0,THH:12,RLL:11,PCH:-11,***
+++ASP:0,THH:13,RLL:11,PCH:-11,***
!!!LAT:37632198,L
=============
ON:-122491238,SPD:0,CRT:0,ALT:30,ALH:54,CRS:10,BER:0,WPN:14,DST:0,BTV:10,RSP:0,***
+++ASP:0,THH:14,RLL:11,PCH:-11,***
+++ASP:0,THH:15,RLL:11,PCH:-11,***
+++ASP:0,THH:16,RLL:10,PCH:-12,***
+++ASP:0
=============
,THH:17,RLL:10,PCH:-12,***
+++ASP:0,THH:18,RLL:10,PCH:-12,***
+++ASP:0,THH:19,RLL:10,PCH:-12,***
+++ASP:0,THH:20,RLL:10,PCH:-12,***
!!!LAT:37632265,LON:-122491187,SPD:0,CRT:
=============
Due in part how parsing is done in the code, only balded lines will be processed and displayed. As you can see a lot of data is just "lost" ( all the stuff that's not balded. Also note that some data set come in only partially such as " !!!LAT:37632265,LON:-122491187,SPD:0,CRT: " in this example. What that means is that data display will not be up to date on all values ( since only partial data is received) and, in other cases display will appear 'jerky'. For example if this comes in
+++ASP:0,THH:1
instead of
+++ASP:0,THH:16,RLL:10,PCH:-12,***
THH display will appear to jerk from 16 to 1 to 16...Same applies to other displays.
Hope this makes sense.
(New GCS is coming out soon...)
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....
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
The GCS beata3 was made with LV9.
Glad I have a student edition I bought !
Earl
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
-
1
-
2
of 2 Next