I just encountered an accidient this afternoon.. and I'd like to point out this IS a potential safety issue
the thing happened is ..
it seems the datalink (3dr radio) was semi-lost while writing configurations to fc... and suddenly the hexa flip to one side.. and the VH hud shown the hexa is upside down when it is upright..
##motor stop at arm is set in code
the throttle is full down.. but something definitely took over the throttle and cause the issue...
so here is the suggestion.. and I would suggest to implement it asap cuz people could get KILLED because of this issue
regard less of whether the motor is arm or whatever.. when the throttle is full down.. the motor MUST NOT be spinning regardless on any flight mode it is in... the all-down-throttle should take fully control over anything else for safety
thanks for looking
safety feature needed
Re: safety feature needed
That is what this does:
/* motors will not spin when the throttle command is in low position
this is an alternative method to stop immediately the motors */
#define MOTOR_STOP
/* motors will not spin when the throttle command is in low position
this is an alternative method to stop immediately the motors */
#define MOTOR_STOP
Re: safety feature needed
already set and still happened
Re: safety feature needed
One safety positive of the motors spinning when it is armed - is you know its armed! I have had some close accidents with knocking a throttle and not knowing its armed....
Also - for awareness, if you put a powerfull tx near to a controller board you may affect its operation.
If I put my tx near to one of my boards it does something to the gyro... immediately flips when throttle is opened up. Have to power cycle the board to fix it. Can see it in the GUI... gyro values go to very high value and stay there.
Also - for awareness, if you put a powerfull tx near to a controller board you may affect its operation.
If I put my tx near to one of my boards it does something to the gyro... immediately flips when throttle is opened up. Have to power cycle the board to fix it. Can see it in the GUI... gyro values go to very high value and stay there.
Re: safety feature needed
it was more like after send "write" in gui over datalink.. and bad thing happened.... was tuning pid...
Re: safety feature needed
jy0933 wrote:it was more like after send "write" in gui over datalink.. and bad thing happened.... was tuning pid...
Nope, commands are checksummed and invalied packets are discarded.
Re: safety feature needed
This is probably not something you're gonna be fixing on atmega with software PWM.
All it takes is for the code to take a shit temporarily and miss short pwm pulse and it becomes long, and the esc will go full throttle. As long as you have software handling things that should be done by hardware.
I wonder if anyone has done timing on how long tarduino takes to write eeprom and how that affects software PWM generation.
All it takes is for the code to take a shit temporarily and miss short pwm pulse and it becomes long, and the esc will go full throttle. As long as you have software handling things that should be done by hardware.
I wonder if anyone has done timing on how long tarduino takes to write eeprom and how that affects software PWM generation.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: safety feature needed
RAM is in very short supply on the 328 but is it possible to hold PID variables in RAM until landing, then write the data to eeprom if they were changed during flight?
Re: safety feature needed
timecop wrote:This is probably not something you're gonna be fixing on atmega with software PWM.
All it takes is for the code to take a shit temporarily and miss short pwm pulse and it becomes long, and the esc will go full throttle. As long as you have software handling things that should be done by hardware.
I wonder if anyone has done timing on how long tarduino takes to write eeprom and how that affects software PWM generation.
what is even worse is that the motor keeps spinning until i unplugged the battery