Replies to This Discussion

ModeratorPermalink Reply by Dean Wynton on June 2, 2012 at 3:08pm

This Thread is "What do you think the APM should do on fail safe" Jake you are in effect hijacking this thread? for the second time please start your own, if you wish to discuss this matter? it is not polite..

• ▶ Reply

Permalink Reply by Jake Stew on June 2, 2012 at 3:41pm

Sorry, I should have posted in the other thread or started another one I guess.  OTOH it's hard not to notice and comment when half the thread disappears.

The one and only things that matter to me is that:

#1 the PPM encoder does NOT continue to put out a signal when it's not getting one (APM control takeover is fine).

#2 The plane does NOT crash under power.

#3 The throttle is cut in a flyaway situation when it exceeds a certain range.

The way I see it #1 should be easy, just fix the PPM encoder bug.  

#2 requires an altitude on the plane and a failsafe hard deck where the throttle is cut.  

#3 is partly implemented with the geofencing.  But in a true out-of-control situation it's not going to work, so there needs to be another failsafe fence or max range where the throttle is cut.

All of these need to be ensured at all times.  Anytime any of these can't be guaranteed the throttle needs to be cut.  I think the easiest way to implement this is to ensure that we're using a hardware watchdog timer on both the processors to protect against hangs and blocking errors.

#2 + #3 could be implemented with a timer scheme.  If the autopilot looses altitude info it should set a timer based on the last known good readings.  So for quads it would just assume freefall or use the other sensors for an estimation, but on a fixed wing and you're flying straight and level you could assume you're holding altitude.  If you're getting tossed about or other sensors are questionable also you could assume you're falling and kill the throttle based on the last known altitude.

For the fencing you could also use a timer or another fence to know when you've lost hope/control and need to kill throttle.

The only thing I see as making it non-reckless to start a machine and let it fly around under the control of a microprocessor is if there are good safeguards to prevent it from crashing under power.  Manual control is the main safeguard, but in an out-of-range condition the autopilot has to take over the job of hitting the kill switch when things are totally out of control.  This is the main safety issue.  It really doesn't matter much what else it can do.  

I think loiter for X minutes, then RTL makes perfect sense.  If you're on a mapping mission or the like then it should probably just follow the mission plan and not worry about loss of signal.

• ▶ Reply

Permalink Reply by Eagle on June 5, 2012 at 7:42pm

Jake I deleted my posts.  Doing so... I deleted 1 Ellison post. But I already PM Ellison about it.

I'm sorry about what happend.  I'm now a regular member 

Regards,

-Eric

• ▶ Reply

DeveloperPermalink Reply by John Arne Birkeland on June 3, 2012 at 5:17am

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

Permalink Reply by Brad Smith on June 3, 2012 at 6:43am

Thanks John !!

• ▶ Reply

Permalink Reply by Vernon Barry on June 3, 2012 at 10:19am

Thanks John for helping to bring this to a close.

• ▶ Reply

Permalink Reply by Jake Stew on June 3, 2012 at 12:33pm

Some people may actually want a working passthrough though.  From my point of view it is still a logical design flaw to have it outputting signal when it is not receiving one.

It will still be altering the input signal in a manner that could caused undesired or unexpected behavior.

Is there some particular reason you can't just pass things along as one would expect?

By not replicating the input you are destroying information that may be useful.  It might be useful for some people to know if they have a range failsafe or a broken throttle wire.  By obscuring the signals the APM can't tell the difference.

Despite my comments, thanks for the work.  You've made a major improvement in safety which will almost certainly save gear and reduce the potential for injury and property damage.

• ▶ Reply

DeveloperPermalink Reply by John Arne Birkeland on June 3, 2012 at 1:44pm

Jake: The PPM Encoder as the name implies, outputs a PPM stream to the APM main chip. It is impossible to skip a channel since a standard PPM signal is a pulse train with 8 channel values, where all channels must contain a value.

• ▶ Reply

Permalink Reply by Jake Stew on June 5, 2012 at 7:18pm

I guess I don't understand enough of the specifics.  Why is it not possible to encode a zero or skip a pulse?

I guess I don't understand the specifics of RC PPM.  I would think that a zero could be encoded and that a missing pulse per frame would be easy to do.  Is the signal entirely differential to each previous pulse and not the frame?

I'm also not really seeing why the PPM is going to the main chip.  I thought the PPM/PWM would be decoded from the input and sent to the main processor in a binary format?

Any resources you could point me to so I can get a better understanding?

• ▶ Reply

Permalink Reply by Richard on June 6, 2012 at 11:35am

Apologies if I'm teaching people to suck eggs.

The PPM Encoder takes up to 8 individual inputs from the Rx and re-encodes them as a single pulse train.

This allows all the Rx inputs to be received by the main APM MCU (2560) on a single pin with a single interrupt, thus freeing up hardware I/O and MIPs for autopilot functions.

For PPM, the channels are encoded as a "SYNC" or "Start" pulse of defined width, followed by one pulse for each channel.

The first pulse after SYNC is channel 1, the second is channel 2 etc.

Edit - Picture from MFTech:It is self-evident that pulses cannot be skipped as the APM would then shuffle channels 'up' one for each skipped channel, having no idea of which channel(s) were skipped.

RC servo control pulses are nominally 1000uS to 2000uS in width. Thus 900uS is considerably shorter than nominal.

You can however force most RC equipment to output 900uS by trimming as short as they go, hence it can be programmed as a failsafe level that will not be output under normal conditions.

This makes it a very good value to use as an 'invalid data' marker.

• ▶ Reply

Permalink Reply by Jake Stew on June 6, 2012 at 1:02pm

Still not quite getting this.  If I were to skip a channel why exactly would this screw up the ordering?

I don't see how this is "self-evident".

To me it is "self-evident" that you have a 22.5 ms frame with a sync pulse and 8 time slots.  It seems really strange to me that they'd use variable time slots.  A fixed time slot system would be easier, more reliable, and use less processing power I would think.

Anyways, thanks for the explanation.  Maybe you can clarify my confusion even further since a variable frequency control scheme seems like chaos to me.

I don't know much about analog signals other than digitizing them.  Maybe a simpler PWM->binary scheme would work better in the long run?

• ▶ Reply

Permalink Reply by John Wiseman on June 6, 2012 at 1:26pm

I assume that the APM is using edge-triggered interrupts to detect the start of each channel in the multiplexed signal, which is really simple (simpler than synchronizing based on a clock signal, I'm guessing).

But it should still be possible to signal invalid or other conditions using the edge-triggered approach, using pulse lengths that won't be output by a receiver under normal conditions, as Richard pointed out.

• ▶ Reply

• ‹ Previous
• 1
• …
• 9
• 10
• 11
• 12
• 13
• Next ›
• Page