inav
inav copied to clipboard
iNavFlight
DSHOT ESCs reboot when save on disarm is called.
This is an issue that @rts18 raised in PR #9335. It is not related to that feature, but to save on disarm. Maybe @rts18 could provide more details, as this is just a copy/paste of what was said in the PR.
rts18
If STATS = ON. When the craft is disarmed any ESC using Dshot protocol will reboot.
@breadoven This causes grief with multirotor inflight emergency rearming. https://github.com/iNavFlight/inav/pull/9254 Tested with two F405 flight controllers.
Someone else has reported this matter. Now it has come to a head, with bad results. https://github.com/iNavFlight/inav/issues/8945#issuecomment-1528707401
@Jetrell I guess you never discovered this problem when testing. Maybe because you've never used the stats again. Wise move!!
@DzikuVx If this matter can not be resolved before the 7.0.0 release. May I ask that the release notes make mention of it ?
MrD-RC @rts18 this should really be it’s own issue for visibility.
** @Jetrell **
I haven't used Stats on any of my models since I wrote that post... I'd actually forgotten about it when I was testing inflight rearming.. But I wouldn't have enable it, to prove what I already knew.
I'm sorry if it caused a crash.. Sometimes things slip through the cracks.
rts18
this should really be it’s own issue for visibility.
I was hoping to get some clarity here first. Of why this matter seemed to have been over looked.
But I wouldn't have enable it, to prove what I already knew.
Fair enough.
other than the fact it obviously won't work if the FC reboots ?
It wasn't caused by the inflight rearming software. And it wasn't the flight controller that rebooted after disarming. It was the 4 ESCs. This obviously takes between 2 to 4 seconds for them to play their tune in the reboot sequence. With some reinitializing faster than others. That in turn sent the quad into a spinning tumble. With great similarity to issue 8945.
For what its worth. I did test the inflight rearming on this quad before I stupidly trusted turning on the stats. And it worked with no hitches.
Thanks for adding the issue MrD.
The post above describes what occurs.
But I discovered that having a mixer profile or PID profile within the model settings, makes it manifest itself more.
It also does not happen every time the flight controller is disarmed. It seems dependent on the CPU load. Example, if the blackbox_rate_denom is set medium to high.
It is also difficult to test the effect of ESC reboot on the bench with the throttle raised, in the case of inflight emergency rearming. Because it seems to use the flight detector to choose if the aircraft can be rearmed. You have to run a dummy ground test outside.
The problem is that save to EEPROM is a blocking and long taking operation. FC will not generate valid DSHOT (or any) ESC frames and ESC reboot as it's the safest thing they could make.
Unless anyone finds a way to feed ESC with valid frames during EEPROM operation, my advide is actually not to use STATS at all
It is also difficult to test the effect of ESC reboot on the bench with the throttle raised, in the case of inflight emergency rearming. Because it seems to use the flight detector to choose if the aircraft can be rearmed. You have to run a dummy ground test outside.
It needs to detect that flight has started for the emergency inflight rearm to work. On a MR this just requires the throttle to be raised above hover throttle and some gyro activity, i.e. raise the throttle and wobble the MR about a bit. You also need to move the MR about when you disarm to get the emergency in flight rearm to work. It shouldn't need a GPS signal for this so no need to test outside.
I suppose one temporary solution here is to block EEPROM save if flight is still detected. However, I'm not sure how reliable this would be given it would need to work immediately after disarming when the in flight detection won't be reliable given the MR will have barely moved if it was in a stable hover. Other possibility is to make auto saving on disarm a setting, perhaps OFF completely or with a time delay > 5 s (in flight rearm timeout time) ?
I did manage to accidentally disarm in flight the other day and emergency rearm worked fine other than the fact the "settings saved" message remained on the OSD after rearming. Only cleared after landing and disarming for longer. Don't know if this indicates something isn't resetting properly ?
This would also be an issue with Servo autotrim as well as STATS.
or with a disarm save time delay > 5 s (in flight rearm timeout time) ?
I like that solution.
This would also be an issue with Servo autotrim as well as STATS.
It is an issue with servo auto trim. But doesn't have the same repercussion STATS eeprom save does on a multirotor.
It is also difficult to test the effect of ESC reboot on the bench with the throttle raised, in the case of inflight emergency rearming. Because it seems to use the flight detector to choose if the aircraft can be rearmed. You have to run a dummy ground test outside.
It needs to detect that flight has started for the emergency inflight rearm to work. On a MR this just requires the throttle to be raised above hover throttle and some gyro activity, i.e. raise the throttle and wobble the MR about a bit. You also need to move the MR about when you disarm to get the emergency in flight rearm to work. It shouldn't need a GPS signal for this so no need to test outside.
I suppose one temporary solution here is to block EEPROM save if flight is still detected. However, I'm not sure how reliable this would be given it would need to work immediately after disarming when the in flight detection won't be reliable given the MR will have barely moved if it was in a stable hover. Other possibility is to make auto saving on disarm a setting, perhaps OFF completely or with a time delay > 5 s (in flight rearm timeout time) ?
I did manage to accidentally disarm in flight the other day and emergency rearm worked fine other than the fact the "settings saved" message remained on the OSD after rearming. Only cleared after landing and disarming for longer. Don't know if this indicates something isn't resetting properly ?
This would also be an issue with Servo autotrim as well as STATS.
Would adding a delay make it more likely for people to unplug the fc during save, triggering a config wipe on next boot?
Would adding a delay make it more likely for people to unplug the fc during save, triggering a config wipe on next boot?
It would which is why it's not really a solution. A second or so delay perhaps but >5s seems too long. There is of course the option to only save to EEPROM rather than save and notify which saves then reloads and verifies the current profiles, something that will take longer than just saving. Save and notify was used to try and fix the Config wipe issue but I think something else fixed (?) that in the end,
This has not been fixed yet. The linked change was rolled back as there is some strange issues when using MSP DisplayPort. This will hopefully be fixed in 8.0.