Replies to This Discussion

Permalink Reply by Vernon Barry on May 22, 2012 at 4:21am

This discussion is relavent to the recommendation of the 9X radio in this thread.

Jake,

Sorry for all the back and forth,but yes, if that is true where the receiver maintains the last signal on rudder, elevator, and aileron, but drops the signal all together on the throttle channel, this seems to be the magic combination that affects the APM 2.0. That would also seem a logical failsafe, say in an electric plane where the ESC directly connected to the receiver would stop the motors and in theory the plane would glide straight and level. In addition, the ESC would likely beep with loss of signal making it an effective plane finder once the thing landed/crashed. Not an entirely undesireable combination in an electric plane. This is bad in other combinations as I believe a servo in a gas plane or heli would maintain the last position (not forcefully,motor not active) but also not close the throttle unless a mechanical return spring was in place on the throttle linkage.That seems to be a warning for some usage scenario of that radio, that while the failsafe seems logical in and electric plane to act as a beep device, it also doesn't in theory work right in gas vehicle with a throttle servo and signal is lost.

Also, just a theory, since I think I have isolated this, is that if the PPM or APM 2.0 firmware (update also effects  APM 1.0) were fixed to remove this bug of maintaining the last known stick position if throttle PPM input is lost but other channels remain valid, then the 9X variants of receiver would in effect become "compatible", as well as increased safety for users against in flight wiring sitatuations that could happen with any radio system.

Also, Update, this also happens on APM 1.0 arducopter 2.5.5

Tested with "Orange Box DSM2" receiver

LP5DSM TX

Test is to arm the system and bring up the throttle.

Turn off TX=motors shut down (also tested the RX with a servo and it sends a low signal on all channels when RF is lost)

Remove power from RX =motors shut down (effectively no input on all channels to APM 1.0)

Remove only the throttle input signal=motors continue to run

Anyway, this is definitely a bug that should be fixed for safety reasons.

• ▶ Reply

Permalink Reply by Jake Stew on May 22, 2012 at 8:00am

Glad we could figure this thing out Vernon.  It took some spirited discussion to flesh out the issue, which should now be an easy fix for the devs.  I think everyone in this thread deserves a big pat on the back!

@Kevin... I think that's the same issue I'm having.  I usually don't turn on the TX until after the APM is booted, so I've only noticed the 15+ sec WOT once or twice.  I have to connect my battery, then quickly flip over the plane and throw a board under the back wheels so the APM gets the proper level.  (I know I should have better switches)

The APM also gooses the throttle for a split sec when I turn on my TX for the first time.  

All of this is a (minor if known) safety issue but needs to be fixed.  I think the APM code just doesn't handle the PWM in/out in a very robust fashion.  It should know to dampen or ignore the first fraction of a sec when the TX is turned on, and it should not inject wild signals in the first little period it's self.

Also the arming code doesn't seem to work for me.  It's always on, I never have to do anything with the controls to get it armed.  Maybe I'm just misunderstanding the term.

Permalink Reply by Vernon Barry on May 22, 2012 at 8:02am

Some source code (not sure if this is the one for APM2.0) but trying to dig through this and see if I can maybe compile a version to fix this.
http://code.google.com/p/ardupilot-mega/source/search?q=ppm&ori...

From what I can tell, we might be able to fix servo2ppm_settings.h


When signal is lost 1= ppm waveform remain on with failsafe values, 0= ppm waveform is off
For use with Paparazzi use "0", the autopilot has it's own failsafe values when PPM signal is lost.
The above failsafe values will kick in only if the servo inputs are lost which cannot happen with
a receiver with dsp processing that provides "hold" or "failsafe" features.
If the receiver only provides "hold" on the last good servo signals received  it is not suitable
for use with the Paparazzi autopilot as it will prohibit the autopilot entering the "AUTO2" or "HOME" mode.
If you use a receiver with failsafe ability then remember to set the failsafe value of the receiver
to 2000 microseconds for the "MODE" channel so the autopilot can go to "AUTO2" or "HOME" mode when the receiver
loose the tx signal. The servo signals on receivers like PCM, IPD and any receiver with servo hold AND failsafe
will not stop outputing servo pulses thus the encoder will never stop producing a PPM pulse train
except if the throttle channel is used as an indication by setting the "RC_LOST_CHANNEL" to a value above 0.
If you use the throttle channel as an indication that the TX signal is lost then:
RC_USE_FAILSAFE set to 0 means that the ppm output will be shut down and if you set
RC_USE_FAILSAFE  to 1 the ppm output will NOT shut down but it will now output the failsafe values
defined above.

 Thus, I think it's not too hard to produce a hex file that "should" work by setting this

RC_USE_FAILSAFE set to 0 means that the ppm output will be shut down.

Or alternatively, you can define failsafe values someplace else?

Permalink Reply by Vernon Barry on May 22, 2012 at 8:10am

Kevin,

I think the full throttle thing at boot is the calibration sequence to the ESCs, but could be totally wrong about that. The thing we are running into is repurposing a system and code that was designed around using ESCs and then trying to drive servos, we get problems from stuff that was specific to getting the ESCs to play nice that was put into the code.

Permalink Reply by Brad Smith on May 22, 2012 at 9:30am

i would think one of the ground vehicle peeps would be able to safely test these theories i just ground tested my plane and it was switching to circle instead of RTL , i might have done this for fear of home not setting and it flying off too my house can't remember or it was some update probably better this way

• ▶ Reply

Permalink Reply by Jake Stew on May 23, 2012 at 12:58am

I just got another cheap programmer from ebay I got to flash my 9X.  I couldn't find the fancier one I have somewhere.

It's an avrdude type programmer I believe.  Anyone know if it will do debugging?

• ▶ Reply

Permalink Reply by Vernon Barry on May 23, 2012 at 1:18am

No, it's my understanding that debugging is only done across a JTAG port, not the 6 pin ICSP port used for programming http://store.atmel.com/CBC.aspx?q=c:100112

So even if you had one of the JTAGs I linked, you would have to wire up a JATG port on the system.

You appear to have a genuine AVR MK2 programmer.

For the record, I have the exact same programmer. I also have several usbtiny prgrammers from adafruit I use more often, because the usbtiny will power the device via usb, while the genuine Atmel requires the device under programming  to have it's own power source. The one caveat is that when burning a bootloader to a mega 2560 or even 1280 chip usbtiny will say it failed (even though it does flash the bootloader) where as genuine atmel of course works fine and throws no errors. For all other operations they seem equal and I believe the genuine Atmel does program faster.

Also, since you brought up avrdude to specifically flash precompiled hex files, I use AVR-Burn-O-Mat as a gui for avrdude. http://avr8-burn-o-mat.aaabbb.de/avr8_burn_o_mat_avrdude_gui_en.html

I used to like command line but now admittedly just am lazy.

• ▶ Reply

Permalink Reply by Vernon Barry on May 23, 2012 at 4:41am

Also, to do debug you need a jtag adapter so here is this if you have an extra arduino around http://balau82.wordpress.com/2012/01/07/ongoing-project-arduino-as-...

http://dangerousprototypes.com/tag/jtag/

http://husks.wordpress.com/2010/02/21/modify-an-arduino-for-debugwire/

then the wiring for the actual jtag plug on the apm

http://code.google.com/p/ardupilot-mega/wiki/JTAG

Permalink Reply by Vernon Barry on May 23, 2012 at 6:09am

Kevin, 

Thanks for the heads up, I thought it was just stuck as a programmer and never really dug into the documentation. The whole reason I even got the MK2 was I was messing with mega 1280s at the time, needed to burn a bootloader and because kept getting errors while trying with a usbtiny from Adafruit, I had to buy something that would work. This makes me feel better about the investment in that tool.

Also, thanks for the link to the Spektrum PPM as well. I have the adapter on an extra APM1 board (I only have one oilpan but 2 red boards).

Oh, I see there are 2 Mk2 that look similiar, but then I realized mine is only a programmer. Oh well, I guess I'll have to go the Arduino JTAG route. You do have the expensive good one.

• ▶ Reply

Permalink Reply by Richard on May 23, 2012 at 2:15pm

In terms of letting the devs know, I think the PPM failsafe issue needs to get reported in the Google Code repo.

It's unreasonable to expect the devs to read every thread on here!

Permalink Reply by Dave on May 23, 2012 at 6:50pm

I've done some further investigation.  Turns out I was looking at old code the other day :-o

According to the doco for the current PPM code :

------------------------------------------
Failsafe mode
------------------------------------------

If a receiver servo channel is lost, the last know channel position is used.
If all contact with the receiver is lost, an internal failsafe is trigged after 250ms.

Default failsafe values are :

Throttle channel low (channel 3 = 900 us)

Mode Channel set to flight mode 4 (channel 5 = 1555 us)

All other channels set to midstick (1500 us)

So it will Failsafe on loss of all signals, but loss of just Throttle could be disastrous.

Turning to the standard Turnigy receiver, I did some more testing and it turns out that, on loss of the Tx signal, not all of the PWM channels disappear.  For some reason that I cannot fathom, Channels 4 and 5 continue to hold their previous settings.  This happens on both receivers I have.  So, the APM would not trigger a Failsafe, but continue on as it was.

So, time to rip out the Turnigy stuff and install the Frsky modules.

• ▶ Reply

Permalink Reply by Jake Stew on May 23, 2012 at 8:01pm

For some reason you can't fathom?  That's the most common sense default failsafe you could have.  Obviously the throttle should go low or to idle.  The most logical thing to do is hold the rest.

This is an APM bug.  There's absolutely nothing wrong with the behavior of the Turnigy module.

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• 6
• …
• 12
• Next ›
• Page