Telemetry stream rates

Hi all,

 

I understand that since the release of Arduplane 2.33, one may:

"ask for any stream rate that is a multiple of 20ms"

 

Does that mean that I may request all the telemetry data(attitudes, raw sensor, PWN in and PWM out, airspeed etc) to be streamed back to APM at 50Hz(max) now?

(all the numbers displayed under mission planner's status tab)

 

If so, can someone pls tell me where on mission planner do I make this setting, or is it something that has to be done in the source code?

 

Have been using APM 1 and APM 2. Owned Xbees, much not 3DR radios (yet).

 

My application right now requires me to get all the sensor data, including the PWM in and out at a rate of at least 50Hz. Apparently this is too much for the onboard memory to handle.

 

Thanks in advance!

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • I don't think the data throughput rate you desire is possible without very extreme customization. Assuming that you could modify the 3DR-Radio Firmware, APM Firmware, and Ground Station Software to suit your needs, you have the following issues to consider.

    Up in the plane, you need to calculate how many bytes of telemetry data you need to send down in each packet.

    Here is the route the data must follow:

    1. Each telemetry reading must be collected by the Air-APM-CPU from the various devices either through, uart, twi, or sbi interfaces. The APM-AVRmega-CPU chip provides no real buffering (ie. hardware fifos) of these interfaces, so you must deal with each telemetry collector on a round robin(byte by byte) basis. Utilizing interrupts provided by the telemetry devices would help speed things along.

    2. Then at a 50hz rate you have to pack up a message from the collected telemetry and send it from the Air-APM-CPU to the Air-3DR-Radio at a baud rate of 57,600. Also, remember there is a start and stop bit added the to front and back of each byte of data. So, your throughput is calculated on 10-bit bytes, not 8-bit bytes.

    3. Then when the bytes arrive at the Air-3DR-Radio, they do not stream down in realtime. They are buffered into a message payload of 64 bytes max. It's not until the full message is collected, that transmission starts. If your full message is longer that 64 bytes, then you have to split it up into multiple payloads to be transmitted down. But not so fast, each message payload has bytes added to the front and back. This can constitute another 5 to 10 bytes.

    4. The message is then transmitted at an air rate of 64000baud to the Ground-3DR-Radio. Of course, depending the distances involved you may have to cut the air rate to 48000baud...or even 32000baud.

    5. The Ground-3DR-Radio must collect a full packet before presenting it to the Ground-APM-CPU.

    6. Then the Ground-APM-CPU has to send it through the USB Port to the Ground-Station.-PC.

    7. This last leg may be able to run at a higher baud rate than 57,600 depending on the capabilities of your USB connection. Also the Ground-APM-CPU firmware could stream this message byte by byte...rather than getting the full message from the radio...and then forwarding the full message to the PC.

    Of course none of this assumes any messaging going up from the ground to the plane. The radios are half duplex, meaning that they can't transmit and receive at the same time. Even a simple one or two byte acknowledgement from the ground would slow things down considerably.

    So, I think you need to do some brainstorming with pencil and paper.

    Full customization could (or would) require software changes to 3DR-Radio, APM, and Ground Station code to minimize or eliminate any unecessary messaging in either direction. For instance, there is no reason to transmit GPU data at 50hz if the GPU only collects data at a rate of 10hz. Thus you should only send GPU data every 5th packet.

    Which brings up another possible technique to improve efficiency, Why send down telemetry data that hasn't changed since the last time it was sent? A customized version of software would only transmit telemetry that had changed in value.

    If you use a one byte Data-Identifer-Field in front of each data field, you could have 256 different types of data fields. If a particular data field was variable length it would require and additional "Length-Byte" following the ID Byte.

    The end result is that the message processing on the Ground-Station-PC would essentially become one big "Case Statement:" that parces thorough the message payload based on the Data-Identifier-Field.

    So, assuminging that each telemetry collector is able to issue an interrupt(over an external output pin), you would write an interrupt handler on your Air-APM-CPU for each telemetry chip/board. You would also have a timer interrupt that would pop at a 50hz rate.

    Here's what the pseudo code would look like:

    Telemetry Interrupt Handler:

       Loop until all fields are sampled:

         Sample a field.

         If the field is different than last time, add the field to the end of the MessagePayloadBuffer$ using the CurrentLocationPointer.

       End Loop IRET

     

    50Hz Timer Interrupt Handler

       If MessagePayloadBuffer$ is "empty" (CurrentLocationPointer==0)

          then IRET

       Else

          Send MessagePayloadBuffer$ to Radio FIFO

          Send Transmit Command to Radio

          Reset the CurrentLocationPointer of the MessagePayloadBuffer$ to Zero.

          IRET  

     

    The bottom line is, if you have a lot of empty MessageBuffers then you don't need to maintain a 50hz message rate.

    The poping of Telemetry Interrupts and 50hz Timer Interrupts is totally random. It's only when the Timer pops, and if "there is data" in the MeMessagePayloadBuffer$...that the message is sent.

    That means the message contents and order of the data are totally random(well almost). This does make message processing on the ground by your PC more CPU intensive. But your PC runs at Ghz, and minimizing(or eliminating) the bytes transmitted through the air is well worth it.

     

This reply was deleted.

Activity

DIY Robocars via Twitter
yesterday
DIY Drones via Twitter
RT @chr1sa: After more than a year of only virtual races, @DIYRobocars returns to the newly renovated @circuitlaunch on May 22 for the resu…
Apr 11
DIY Robocars via Twitter
RT @DAVGtech: And now available with LiDAR 🔥 https://twitter.com/Heavy02011/status/1381137016381964293
Apr 11
DIY Robocars via Twitter
RT @Heavy02011: #VirtualRaceLeague: @DIYRobocars Race #9 - #ParkingLotNerds #thunderhillracetrack, CA Join us for the next race April 24th,…
Apr 11
DIY Robocars via Twitter
RT @DWalmroth: Weather's finally cooperating, looking forward to racing 1:10 scale autonomous cars outdoors again! @diyrobocars, @NVIDIAEm…
Apr 7
DIY Robocars via Twitter
RT @AIDRI_: I finally succeeded in optimizing the trajectory and speed of a car on a #racetrack. Next step: implement a 2d controller and…
Apr 7
DIY Robocars via Twitter
@jetdillo @circuitlaunch Actually the second *in person* event in a year. We do virtual races every month
Apr 2
DIY Robocars via Twitter
Update: we're moving it back one day to Sunday (the 4th) at 11:00am instead
Apr 2
DIY Robocars via Twitter
@GrantEMoe @circuitlaunch Update: we're doing it on Sunday (4th) at 11:00am instead
Apr 2
Laurie J. Troy liked Jasper Kueppers's profile
Apr 1
DIY Robocars via Twitter
RT @chr1sa: Maybe we should have a mini @DIYRobocars race in our lower school's playground https://t.co/xLFeua1R6X
Mar 29
DIY Robocars via Twitter
If anybody wants to join us for an informal outdoors hack/race we're going to be meeting at the @CircuitLaunch park… https://twitter.com/i/web/status/1375907409223249923
Mar 27
DIY Robocars via Twitter
RT @SmallpixelCar: Ready to reopen, innovation has to continue. Inside/outside, LiDAR/GPS, race/delivery https://t.co/jpmvttoHEd
Mar 26
DIY Drones via Twitter
RT @DAVGtech: By far best race yet! Congratulations to the winner @Heavy02011 🥇🏆🍾👏👏👏 @diyrobocars @donkey_car @NVIDIAEmbedded https://t.co/…
Mar 20
DIY Robocars via Twitter
RT @Heavy02011: #VirtualRaceLeague: @DIYRobocars Race #8 - #ParkingLotNerds ⁦@DAVGtech⁩ ⁦@DWalmroth⁩ ⁦@OttawaAVGroup⁩ - join us tomorrow h…
Mar 20
DIY Drones via Twitter
RT @mrpollo: 11 years ago, the pxIMU was announced to the world on @DIYDrones, and it changed the life of many (mine included). The followi…
Mar 18
More…