First this IS NOT a bashing session this is a search for answers and opinions so try to be respectful and courteous !
me personally i think the APM is capable of bringing my plane back and landing if the rx fell out ! do i think DIY should be responsible to implement it ? no but they are flying too so if we come up with a good proposal i,m sure they would try to make it happen !
this discussion is intended to come up with scenarios where your platform would go out of control ! and what we can do ! there should be a sister post Mitigating the chances of losing control .
i,ll start out . with Geofencing(here after to be referred to as GF) turned on i can't see how your platform can fly away so maybe GF should be turned on from default with a tiny box that you have to adjust to your area,platform,and conditions ? but not all of us carry a laptop to the field so maybe we should be able to save it and recall a few different versions for different fields and or conditions that way you could program it at home and go fly , but if you turn it on to far away from the place you selected as home it should lock up and beep or flash an error that way it wont try to fly 40mls back to your house (00) a safe configurable selectable autoland function tied too GF would be nice too.
at least this would protect the DIY community from litigation and put responsibility on the user and would save a newbie from a painful costly learning experience !!! feel free to poke holes in my ideas !
Questions leads to answers and isn't it wonderful we need not wait another second to make the APM better and if we do a good enough job maybe the government will force the AMA to use our product on all there large dangerous aircraft ! and would help in the UAV community acceptance into the sport
now have at it
What would the watchdog guard against? Radio signal loss?
A watchdog timer is simply a hardware timer on the chip which has to be reset by the software/code every so often or it causes the chip to reset. It prevents a hang or lockup from causing your device to freeze until you manually reset it.
What you are doing is constantly checking if things are OK and resetting the timer if they are. If you fail to reset the timer it is because there must be some problem and the timer just automatically triggers a reset.
Essentially it's a "deadman switch". The term comes from the setup where if you don't keep holding the trigger down (possibly because you've died) the bomb explodes or the train stops or the machine shuts down, etc..
This timer would guard against everything. If at any time any critical function fails to report OK it would reset the APM, which would shut down the motors. When power comes back on it would not enable the motors unless the critical condition reported it was OK again.
This would prevent or mitigate all sorts of freezes, lockups, hangs, and bugs. It's basic microcontroller programming 101, so I'm really surprised it wasn't implemented from the beginning.
There should probably be at least one watchdog and several other timers that would generate an interrupt or reset if they don't get serviced.
Heh, heh. I know what a watchdog timer is. I've even programmed a few in my day. ;-)
My question really is what you want the timer to guard? We can enable it, but then the question is what we will do, in case of a watchdog timer reset? This will also only guard against CPU lockup.
For the radio signal loss, if the receiver continues to send the last pwm signal to the APM's decoder chip we can't really detect the condition reliably. This is why I'm suggesting that we use the acceleration at high speed to the ground as an indication of fault or in some cases reckless flying.
Well, the PPM processor and the main unit should both have watchdogs to guard against hangs and intermittent bugs. It seems there's quite a few intermittent bugs which are causing lockups for some people.
The 9X systems, which started this whole thing off, drop the throttle signal (ch 3) while holding some others. This couldn't be any easier to detect. If you've got a cheaper system the best thing would be to throw it out and get a 9X, they're only around $55. If you've got a more expensive system you're probably not going to eat crow and get a 9X, so just set your failsafe to do something detectable I guess. Someone posted some code (maybe Kevin) that compares values and increments a counter if they're the same.
So if you set your failsafe to put out 5% throttle and you don't have a deadband on that stick it should be constantly varying a little bit whenever your have radio signal, but completely frozen at 5% when signal is lost. The code should be able to detect the 5% setting AND the fact that it's not varying at all. Alternately you could detect that all channels are frozen. Or in another case you could detect that the throttle shot directly from cruise to 5% without passing all the intermediate settings you would have to go through if you were moving the stick.
Luckily the most popular TX/RX (the 9X) smartly drops the throttle signal altogether, which is easily detectable. I think that should be implemented first since it is the easiest and will help the most people.
For the future I also think it would be good to have a rule that nobody codes anything that by default intentionally ignores signal inputs (or the lack thereof) or defeats built in safety features of TX/RX systems.
Watchdog is a different thing to radio failsafe.
I agree with Jake that it should be enabled, but not his reasoning why (mostly because the watchdog doesn't do what his post implies).
Without the watchdog, an unforeseen bug in the main loop or ISRs could cause the processor to hang, and thus not update the AHRS and PWM outputs.
The latter would cause the motor outputs to 'freeze', possibly at a power that keeps the aircraft in the air.
With a watchdog, such a bug would cause the APM to reset.
State information would have been lost so a copter would probably crash anyway*, although it might be possible to catch a fixed-wing craft.
- For example, the old I2C lockup bug was such an issue. That could easily have caused a stable fixed-wing aircraft to power off into the sunset!
(A copter would probably crash pretty fast, and IIRC they did.)
I would go for a fairly long watchdog timeout, perhaps two seconds.
- Watchdog reset is likely to cause a crash and thus should be a very last resort - it's "crash or fly into the sunset", and is unlikely to actually rescue the aircraft.
*The APM may wake up with a copter spinning in freefall, so no idea which way is up.
Catching that is a non-trivial problem!
Auto resetting the APM in flight could cause numerous problems as in what would happen if it reset too close to the ground or at edge of GF boundary or in the middle of a high speed dive ! this might be feasible if it was happen after it flies to a safe alt and a safe position too allow it to stay in the preset boundary while resetting. but would be great if it would abort launch and sound buzzers or flash led,s while still on the ground
Watchdog doesn't do what you think it does. The following is not entirely inaccurate:
Imagine being knocked unconscious while flying.
The watchdog wakes you up, but you have no memory of what you were doing beforehand and only a vague idea of how long you were out.
The only thing you know for sure is that you were doing something pretty important!
good one Richard i must have missed this some how (lol literally) the watchdog seems like an idea for the next version of the APM to me personally
And without a watchdog, you simply don't wake up.
We would have to be careful of taking away control of the pilot under unknown conditions then it would be our fault if it crashed and hurt someone ! but this could be great on the ground before take off flashing an error code on the led,s and buzzers to let you know your gps or throttle or mode switch is intermittent or not present
Everyone wants to talk about what things you could think of for the APM to do in various situations.
Isn't that exactly what we're talking about? Without the APM this device is a dumb device with no sensor input or decision making abilities. If the APM were to fry I would expect the craft to stop, completely, and become inoperable. Since we need the APM to make decisions (autopilot) why does it not do exactly that? My radio signal was lost and because the PPM encoder cannot talk to the APM, and the APM isn't designed with safety in mind, my heli flew away at full throttle. The same thing could have happened at Chris's talk at Maker Faire, only he had an audience 10ft away, I did not.
Why can't the APM monitor signal quality or presence through a sensor and make decisions based on that info as well as all the other sensor info it's receiving? I'm not talking about doing black magic here, the PPM encoder, the one piece of hardware that interacts with the signal from the remote the pilot is using, cannot or does not talk to the APM, thus the APM has no idea what's going on with the signal. Not to mention that fact that it forces the same code to run on all platforms, which isn't the best answer. Why not replace the current PPM encoder with something a little more intelligent or communicative to the APM so the autopilot we have all bought into can auto-pilot when there is a need to?
First, even if the signal was lost, and the receiver continues sending the last signal to the decode, the craft will not fly away at full throttle, unless that was the last signal sent. My idea is that because we have all the sensors on the IMU, the craft should never be allowed to fly away at full throttle. With geo-fencing fully implemented, the craft should only fly within preset limits.
From my point of view, I don't think that the decoder is the place to put any kind of failsafe algorithm. It's task is simple to decode the PWM signals coming from the receiver. It's got a small memory, and the code on it needs to run as fast as possible, without complicated delays, that may be introduced to figure out failsafe.