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!
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.