Replies to This Discussion

Permalink Reply by Vernon Barry on June 6, 2012 at 3:08pm

My configuration setting is zero throttle and neutral control surfaces

You just did the same thing the 9x variants do which is BAD. You should never go to 0 on any channel, at least output a VALID value to close a throttle servo ~900

The 9x variants do the same thing out of the box (drop the throttle signal altogether) and have caused some issues. Null is bad because then a servo just sits at it's last position as if it's not powered on. The assumption is that an ESC would shut off with no signal, but that doesn't work in every situation, which is why setting a failsafe at the lowest value is better than no value. Then you know it shuts it down.

It's known the PPM encoder current shipping firmware will ignore a null value on the throttle channel if the other channels are valid. There is an update posted for PPM that corrects this loss of throttle signal while other values are correct.

http://diydrones.com/forum/topics/what-do-you-think-the-apm-should-...

Again, you just need to output a low value not a null value, and it's not a bad idea to update the PPM in case the unthinkable happens when the throttle wire only gets loose.

 

DeveloperPermalink Reply by John Arne Birkeland on Sunday

I have updated the ArduPPM firmware for the APM2 (v2.2.67) so that it will detect a missing throttle signal and set the the throttle value to 900us. APM1 version will come later.

Binaries: http://code.google.com/p/ardupilot-mega/source/browse/#git%2FTools%...

How-To: http://code.google.com/p/ardupilot-mega/wiki/APM2Encoder

• ▶ Reply

ModeratorPermalink Reply by Mark Harrison on June 6, 2012 at 3:36pm

@Vernon, I think Fred meant "zero throttle" to mean "lowest stick postion."

I've got the same setup on my FrSky... you bind by holding the bind button on the Rx, position your sticks and switches, and then click the bind button again.

I position my APM mode switch to the setting I've mapped to RTH.

@John, thanks for the patch!

• ▶ Reply

Permalink Reply by Fred Forbes on June 7, 2012 at 6:22am

Mark.  Thanks.  That's what I meant.  Poor choice of words on my part.

You guys are too smart for me.  My question was simply, am I wrong to assume that in MANUAL mode APM2 passes the rx failsafe settings to the outputs unchanged?  My testing indicates that APM2 changes the throttle output such that it doesn't stop the motor (which is the rx's failsafe throttle position).

This is a concern to me as I thought (and want) the APM2 to be out of the loop in MANUAL mode.

Fred

• ▶ Reply

Permalink Reply by Vernon Barry on June 7, 2012 at 7:14am

APM will always be in the loop from a hardware perspective. There is no way around this. The very PWM signals going to the servos are generated by the ouputs of the mega2560 on the APM, Your input signals from the radio go through the PPM encoder to the APM main processor mega 2560. 

What I was stating and is a problem is that there is one scenario on the PPM encoder your signal always must go through, that IF you have valid signals on channels 1,2,4,5,6,7,8, but no or an invalid (too low) of a signal on channel 3 (AKA Throttle), then the current firmware on the PPM encoder on the APM 2.0 board (FYI my testing says APM1.0 does this too) then the PPM is passing the last good throttle signal to the APM which is what actually drives the servos and your ESC.

Again, the fix is to raise your failsafe setting to the same output that would be found at minimum throttle stick (not 0 or whatever value you set) and also follow the directions to flash the PPM with the updated code provided in my first post.

Normally, with 90% of the radios out there, the stock, unaltered failsafes work just fine with the stock firmware. Only the 9x variants and now your specific settings that you entered cause the glitch in the stock PPM encoder firmware.

As a test, before you go changing things, what does a servo do when plugged intop the receiver throttle channel when failsafe (TX is turned off) is invoked? I think (and I think, but could be wrong) the servo may not respond and turn to minimum value.

• ▶ Reply

Permalink Reply by Jake Stew on June 6, 2012 at 3:48pm

I would update the PPM encoder firmware as JB mentioned.  I think there's every reason to be very concerned with the current default firmware.

A big thank you to JB for addressing this important issue!

• ▶ Reply

Permalink Reply by Vernon Barry on June 6, 2012 at 4:47pm

My concern here is that while there has been tons of pressure on the PPM side of the house. I don't see anyone adressing the Radio side of the house in the same manner.

I know @Mark said I assumed he meant low throttle, not null, but it still should be discussed.

Point being that proper failsafe is not to put an invalid or null signal out on RF loss, especially for the throttle channel. The reason is, you need a valid low signal in the range a servo can hit so in the event the system is used in anything that doesn't have an electronic speed control (that we assume shuts off with no signal) so that a real throttle servo would be closed by the low signal in the case of a gas heli or plane. I know that some have quoted no signal as being logical, but I say that is completely wrong-especially when in traditional cases (anything with a servo) it would cause a runaway. I would like to see equal and fair discussion on that front (in the appropriate thread, not here).

The reason why that's relavant, is this exact thread. A user set failsafes to something I do not consider failsafe and the results were a non-desired action. We can have the chicken and egg battle all day, but the truth is 2 wrongs don't make a right. In general, failsafe should be low throttle not null, and there is now a fix on the PPM side firmware to adress detection of null as failed. I just feel we need to address both, and thus train users on what valid failsafe is as a "standard", and further show folks they should update to the new PPM if their setup fails the failsafe test. I also advocate that all users probably should update to the latest PPM as a prevenative measure. I'm just afraid some members have turned the PPM into a witch hunt (think "if the PPM weighs the same as a duck, then it's made of wood", and =witch), when really, there are two sides to the problem and nobody but me seems to agree the radio fail safe setting has just as much blame and is just as important of an issue both training and documentation wise.

Again, my reasoning is that the same radio gets used in non-UAV equipment and has no extra failsafes. So our training, documentation and settings in general, should follow what is good practice in the regular RC world. These deviations only stand as a place to bite somebody later. Say you get tired of the quad or crash it and get a shiny new .30 or .50 sized nitro heli and drop that receiver you knew you put "what you thought were valid" failsafe settings on and now suddenly find yourself with an upside down lawnmower coming at you with the throttle stuck because in your logic, null throttle was safe. In the case of box stock 9X users, they don't even have a choice unless they upgrade the RF sections TX and RX to FrSky or other aftermarket "upgrade".

Also, just as a heads up, I think everyone should also be testing your ESCs while we are on the subject of unexpected actions. I know for a fact, that the 3DR and RC Timer ESC continue to run for a short time after the signal cable is disconnected as part of a function of their firmware. It's far too long IMHO and that topic also hasn't gotten attention.

Test for yourself:

Run the throttle up.

Unplug the signal wire.

Note the ESC continues at the last speed for a period of time.

Not good in my book either-but that's also adressed by flashing the ESC firmwares which does resolve that problem too.

I wouldn't be suprised if that short run-on feature of the stock firmware hasn't actually been the cause of a flip or two when the APM browned out but the motors continued to run on, just long enough to flip.

• ▶ Reply

Permalink Reply by Brad Hughey on June 6, 2012 at 5:27pm

How many people caught the "Holy Grail" reference in that post?  Hilarious...

Forget the failsafe, I really want to go back and face the peril!

• ▶ Reply

Permalink Reply by Jake Stew on June 6, 2012 at 8:14pm

You mean this scene?

http://www.youtube.com/watch?v=yp_l5ntikaU

It's been many years.  You guys are a hoot!

• ▶ Reply

Permalink Reply by Jake Stew on June 6, 2012 at 8:27pm

> there has been tons of pressure on the PPM side of the house.

 

I'm sure those 7 lines of code in the patch were backbreaking.  Hopefully the dev team took plenty of breaks during this heroic effort.

 

All kidding aside, I don't see that there's much that can be done about the radios.  The PPM signal itself is pretty strange and old fashioned.  I think it would be much better, and more logical, if the terms were rephrased to make more sense in a digital manner.  The radio and PPM encoder people both probably would have avoided these problems if the signal wasn't designed and referenced in such a wacky manner.

 

I also don't think it's very appropriate to be using analog signals for inter-processor communication.  Maybe that can be upgraded in the next hardware version.

• ▶ Reply

Permalink Reply by Brad Smith on June 6, 2012 at 9:19pm

i must be missing something ! i have a stock turnigy 9x and the failsafe is fully programmable from 0 to 100% on every channel what else could or should it do ?

• ▶ Reply

Permalink Reply by Jake Stew on June 6, 2012 at 9:32pm

That feature doesn't actually work with the stock TX/RX module.  It only works in PCM mode modules and receivers.

The stock module uses PPM (analog), while PCM is a digital method of encoding the signal.

• ▶ Reply

DeveloperPermalink Reply by John Arne Birkeland on June 7, 2012 at 1:48am

Those 7 lines of code increase jitter in the PWM code by 0.2-0.3us meaning we are loosing 20-30 steps of stick resolution.

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page