Hi @geofrancis,
That’s possible but if I were to implement it I’d prefer we make it safe and useful for everyone. So another solution would be to replace the arming-required with an auto-arm feature. So it boots up disarmed but then automatically arms once it’s ready
is there a way to check the ekf status over mavlink?
I thought it could auto arm already ? or is that only plane?
This seems like the most useful solution that is in keeping with good design philosophy.
Hi @Yuri_Rage,
Thanks for the vote of confidence. I’ve gone ahead and created an issue here. I’m not going to overburden the enhancement too much but Rover inherited this behaviour from Plane so maybe we can get the Plane guys to adopt this as well
Could be used in a remote deployment scenario where the vehicle sits on a charger (or largely dormant) and power is applied remotely via a separate link and a latching relay affair. Might be a nice addition to some of the search and rescue ops.
I have creative solutions, not necessarily good solutions 
@rmackay9 @Yuri_Rage
just maybe a stupid idea for a first test:
Isn’t it possible by a script to repeatly check the state and if this is ready to arm process the arming.
Yes, could be scripted. Might be a nice native improvement rather than relying on scripting.
Yes, for sure. Only an idea for someone who don’t can will wait for a well tested new feature
Check on autotest there is a method to check ekf state
From what I can find It should be able to be checked using estimator status message by checking the status flags
https://mavlink.io/en/messages/common.html#ESTIMATOR_STATUS
https://mavlink.io/en/messages/common.html#ESTIMATOR_STATUS_FLAGS
So from testing my quadcopter running a h743, a bare pix hawk and omnibusf4 running rover for a week on latest firmware i didn’t see anything unusual in the logs. I will try again soon with a built rover in case It’s something hardware specific, but it’s possible the issue has been fixed since I was last testing about a year and a half ago.I’m going to be doing some more testing with some more complete rover setups to see if I can replicate the behaviour.
Hi @geofrancis,
Great, thanks very much for the testing and feedback!
@rmackay9 do you have many issues with H743 chips corrupting their memory when you brown them out. The main reason I have the external controller was that if you let the battery run out and the voltage comes up slowly as the batteries charge then H743 will corrupt its memory and need erased using STM32cube programmer and reflashed before it will start up again. I can reliably make all my Matek h743 controllers corrupt just by turning the voltage up and down slowly a few times. My understanding is that this is an issue with the H743 chip itself, but is it just terrible on the Matek boards or is it because no one else is solar powering flight controllers? Could you connect some H743 controllers like a cube to a bench power supply and slowly turn the input voltage between 0 and 5v over 10 seconds a few times to see if the corruption is repeatable on other hardware.
I have also had it happen when using a long usb cable that had too much voltage drop, and with the WLITE controllers if there is a capacitor on a device plugged into the servo rail, it causes the voltage to come up slowly.
Its so bad now that I downgraded one of my rovers to a clone pixhawk and its been totally fine, I have never corrupted a F4 controller.
I started a test and then stopped for a couple of reasons: I was testing an H757 on a Cube Orange+, so that’s not really what you wanted. Additionally, it’s very hard to get most of these premium boards into DFU mode if you screw with 'em too much, and I don’t want to ruin my hardware.
I think you should explore using a cutoff switch that cuts the power abruptly on a low voltage signal rather than risking corruption. Expecting a brownout sounds like poor practice that could damage/corrupt a good many bits of hardware.
I have a separate esp32 that does exactly that but it’s slowly getting to the point where I have nothing connected to the flight controller other than a mavlink connection, compass and GPS because I can’t trust it with any other hardware, I can’t plug servos into it incase one fails or stalls on startup and takes out the flight controller.
I am looking forward to ardupilot on esp32 controllers as they seem to be far more resistant to corruption.
What about using another pdb with better power control and some hysteresis to prevent struck some hardware ?
I tried switching it at the battery using the BMS but the capacitors in the motor controller would take just long enough to discharge to cause problems with the voltage dropping slowly. so now I have a pair of relays, one for switching on the 48>12v regulator and a second that switches power to the flight controller so it can be shut down in stages.
Hi @geofrancis,
Thanks for the report, I have never heard of this before. I’ll tell some other devs but this is all new info to me.
For the brief test that I did today (only one cycle from simulated battery voltage to dead via bench supply), I used a Cube brick and Cube Orange+. Nothing bad happened, but I stopped after one try when I realized I wasn’t testing an H743 and before I did any harm.
I wonder if the onboard BEC/PDB on the Matek hardware has some disadvantageous voltage regulation.