Custom AC3.1.2 with UART2 enabled for APM 2.5

[David Pérez-Piñar]

Hi all,

I am planning to build a custom version of ArduCopter for my APM 2.5 autopilot. The only modification I need is just to enable the second telemetry port (UART2) which would be running simultaneously with the standard UART0 port. As far as I know, both ports would behave similarly, accepting MAVLink comms; the only difference being that UART0 is the only port supporting CLI (please, correct me if I'm wrong here).

My concern is if this additional task will result in excessive loading of the APM 2.5 microcontroller. This concern has been fueled by discussions on APM being close to hit its limits. It also comes from the fact that the ArduCopter code does not use the second telemetry port when compiled for the APM 2.5 board, and I guess this has been done so for some reason - which could be related to processor loading.

I've been digging for information here on both APM limits and second telemetry port for APM, and despite having found some related information, I've found nothing talking about the additional load that comes from adding a new telemetry port.

I'd be grateful if anyone can shed some light on this: is it safe to add the port without risking too much loading? I'm planning to conduct some tests with performance log enabled, but any previous information will help.

Thanks!

[Randy Mackay]

David,

 

     I think it’s both processor load and RAM that was the big concern.  Also it’s not something that most people use so there didn’t seem much point in enabling it.  You’ll be able to see the RAM usage through the mission planner’s Flight Data screen’s status tab (at the bottom).  I forget the name but I think it’s “freemem” (my MP has frozen up at this particular moment).  There’s another field called “load” that will tell you the current CPU load as well.

 

     It’ll probably work ok but I think you’ll find the rate that it outputs data on that port will be pretty slow.

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[David Pérez-Piñar]

Thank you, Randy. Wasn't aware of the memory problem. I will report my test results.

[Kristian Klausen]

Hi David,

How did this work out for you?

Kristian

[David Pérez-Piñar]

Hi, Kristian

Sorry, I promised to publish my results and I didn't. Here they are.

I customized the firmware to simultaneously enable UART2 and UART0. My setup included an XBee with the required adapter connected to the UART2 port. The main board is an APM 2.6 with GPS and external compass. The frame is an X-quad (coaxial configuration) with 13x4.5 propellers, MT3506-25 motors and 5000 mAh 4S battery. Take-off weight is somewhat below 3 Kg.

I conducted several ground and flight tests with this configuration:

• With respect to processor loading, the customized firmware with two active serial ports showed an average loading of 63.1% (Mission Planner reported loading between 61.1% and 65.1%). Tests with the standard firmware reported an average loading of 59.7% (values measured showed loadings between 57.9% and 61.2%). Thus, the average processor loading with the custom firmware is about 3.4% higher.
  
• With respect to free memory, the custom firmware reported 944 bytes free (freemem status field, average), while the standard firmware showed an average of 1216 bytes. Thus, an average difference of 276 bytes.
• In terms of flight performance and vehicle handling, I didn't notice anything different with respect to the standard ArduCopter firmware.
  
• However, the UART2 telemetry rate was much slower than the standard UART0 telemetry (compared using the same radio link for both ports), as Randy pointed out. I didn't get good measurements on this, but the difference was notable: when using the UART2 telemetry, intervals of several seconds between ground (Mission Planner) updates were common. Mission Planner link stats reported errors in the order of 50% of frames, if not more. And reception errors and ground delays seemed to happen somewhat randomly: sometimes the ground station updated at 4-5 Hz, sometimes it just freezed on the last update for 5 or more seconds.

The reception rate was way too low for me, and I did start searching for the cause, but I finally found another solution to my needs, so I cannot actually tell why the UART2 connection was so error-prone and slow. It could just be something on my setup. Anyway, tests showed (as explained before, and just applicable to the test flight conditions) no noticeable negative effect on flight perfomance. Be aware that my test flights were just that (test flights), mainly hovering at low-mid altitude with little, smooth maneuvering in low wind conditions.

Hope this helps.

[Kristian Klausen]

Hi,

Thanks for the updates, I really appreciate it :)

Kristian

[Jason Short]

Was the update rate delay caused by dropped tasks in the scheduler?

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[David Pérez-Piñar]

I don't know for sure if there were dropped scheduler tasks... didn't log this particular performance parameter in my test notes. With respect to performance measurements in flash logs, tests showed values that seemed normal to me, at least when comparing them with previous performance observations I did before. But, as said, I didn't watch this parameter closely: I just scanned the performance log for too long scheduler cycles and hints like that, but found nothing unusual.

[Jason Rollette]

http://dave.cheney.net/2014/01/25/avr11-building-an-spi-sram-shield-for-an-arduino-mega

This seems to be an easy way to add a ton of extra ram.