It seems to have been buried in the thread, but somebody needs to check this:
Dave said that he has seen the APM appear to treat "No PPM input signal" as normal operation, holding the last good values from the Rx internally. - I don't know whether that is a misunderstanding, generally true or unique to his setup. It needs to be tested ASAP.
A lack of PPM input must trigger failsafe, regardless of all other inputs. It clearly means that the pilot has no control of the aircraft.
Secondly, Vernon, please calm down and do some more research because what you posted earlier today about PWM is completely untrue.
Here is how PWM works in a microcontroller like the AVR:
In almost all microcontrollers, PWM output is run in dedicated hardware that does nothing more than count and compare every 'tick'. It does not depend on any part of the firmware still going, it merely needs the clock source to be running. - On some MCUs, the PWM 'tick' may be an external clock running at a completely different rate to the rest of the MCU, and on many it even keeps going during 'sleep'.
Thus if the firmware did hang or crash, the PWM signals will keep outputting the 'most recent' values until the MCU is reset - because they are running on dedicated silicon.
In the case of the AVR/Arduino, "Fast PWM" is indeed a hardware PWM. (The ATmega 2560 has 15 semi-independent channels.)
For output to ESC/servos they are set to a 20ms period, and duty cycle between 1 and 2ms. The duty cycle is given new values regularly by the main loop and keeps using those values until a new one is set.
If the main loop doesn't give them new values, they'll keep using the old ones.
Try it if you like - write a program that starts a PWM ouput then goes into a "while (1) {};"
- The PWM continues, even though the AVR is sat in a busyloop doing nothing at all!
On top of that, if the main loop has hung, interrupts will still fire and be processed. - For example, in ArduCopter firmware the PPM input itself is processed by a "capture" interrupt.
This means that if the main loop crashes, the PPM input is still being received - though turning that input into new values to output won't happen because the AHRS and PIDs are in the main loop.
A lot of stuff still happens if the MCU has crashed, you cannot say that a lack of main loop means no output - the result depends very much on how the code operates and what crashed where.
In the case of the ArduCopter firmware, if the main loop hangs at a moment of full-power-all, then it'd continue do that until the MCU is reset.
The only way to prevent the PWM outputs from continuing to send the 'last settings' for period and duty cycle if the firmware has hung is to use the watchdog timer, which will automatically force the MCU to reset if not fed correctly.
- In a quick search I wasn't able to find the place(s) where the wdt_reset() or wdt_enable() are called in the ArduCopter firmware though, which worries me somewhat. They are being used, right?
All that said, a multicopter would probably crash pretty fast if the APM was not running properly, as these need continuous active correction to fly at all.
Should be a good first choice John. There are several discussions about the Turnigy on this forum and other sites. There are quit a few hacks out there for it too.
Replies
It seems to have been buried in the thread, but somebody needs to check this:
Dave said that he has seen the APM appear to treat "No PPM input signal" as normal operation, holding the last good values from the Rx internally.
- I don't know whether that is a misunderstanding, generally true or unique to his setup. It needs to be tested ASAP.
A lack of PPM input must trigger failsafe, regardless of all other inputs. It clearly means that the pilot has no control of the aircraft.
Secondly, Vernon, please calm down and do some more research because what you posted earlier today about PWM is completely untrue.
Here is how PWM works in a microcontroller like the AVR:
In almost all microcontrollers, PWM output is run in dedicated hardware that does nothing more than count and compare every 'tick'. It does not depend on any part of the firmware still going, it merely needs the clock source to be running.
- On some MCUs, the PWM 'tick' may be an external clock running at a completely different rate to the rest of the MCU, and on many it even keeps going during 'sleep'.
Thus if the firmware did hang or crash, the PWM signals will keep outputting the 'most recent' values until the MCU is reset - because they are running on dedicated silicon.
In the case of the AVR/Arduino, "Fast PWM" is indeed a hardware PWM. (The ATmega 2560 has 15 semi-independent channels.)
For output to ESC/servos they are set to a 20ms period, and duty cycle between 1 and 2ms. The duty cycle is given new values regularly by the main loop and keeps using those values until a new one is set.
If the main loop doesn't give them new values, they'll keep using the old ones.
Try it if you like - write a program that starts a PWM ouput then goes into a "while (1) {};"
- The PWM continues, even though the AVR is sat in a busyloop doing nothing at all!
On top of that, if the main loop has hung, interrupts will still fire and be processed.
- For example, in ArduCopter firmware the PPM input itself is processed by a "capture" interrupt.
This means that if the main loop crashes, the PPM input is still being received - though turning that input into new values to output won't happen because the AHRS and PIDs are in the main loop.
A lot of stuff still happens if the MCU has crashed, you cannot say that a lack of main loop means no output - the result depends very much on how the code operates and what crashed where.
In the case of the ArduCopter firmware, if the main loop hangs at a moment of full-power-all, then it'd continue do that until the MCU is reset.
The only way to prevent the PWM outputs from continuing to send the 'last settings' for period and duty cycle if the firmware has hung is to use the watchdog timer, which will automatically force the MCU to reset if not fed correctly.
- In a quick search I wasn't able to find the place(s) where the wdt_reset() or wdt_enable() are called in the ArduCopter firmware though, which worries me somewhat. They are being used, right?
All that said, a multicopter would probably crash pretty fast if the APM was not running properly, as these need continuous active correction to fly at all.
Should be a good first choice John. There are several discussions about the Turnigy on this forum and other sites. There are quit a few hacks out there for it too.
Hey,
Im no expert, there will be many people on here with much more knowledge than me.
But I am a newbie and havent used failsafe or the telemetry side of it yet, but i use the same setup but my controller is a Eurgle 9x.... same thing.
Havent had any probs yet, Reflash it with the ER9X firmware.
-
1
-
2
of 2 Next