-
Notifications
You must be signed in to change notification settings - Fork 13.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Commander refuses to arm, no error message/reason #3125
Comments
@mhkabir The problem is that the transition from ARMING_STATE_INIT to ARMING_STATE_ARMED is invalid. The commander should have switched from ARMING_STATE_INIT to ARMING_STATE_STANDBY before |
So you will need to put some printfs to see what's going on :) |
Thanks, I'll have a look. Looks like the issue is coupled to the sensor calibration of external mags. If I disable the UAVCAN mag and recalibrate, it's just fine. |
@Tumbili I spent nearly two hours on this today without being any closer to finding out what the fail is. Some help please :/ |
https://github.com/PX4/Firmware/blob/master/src/modules/commander/state_machine_helper.cpp#L250 Kind of a impossible situation. No reason why it should do that. How does the How even :
All I get is the first message, and sensor_feedback_provided is true. How is this even possible?? |
The issue we need to solve for is to report every sensor once, but not all the time. We might need an arming error bit mask and report only if the bit is not already set. The bit mask should be re-set once a new link connects, which will automatically re-send the errors then. |
A secondary issue is why its failing the check in the first place, of course. |
Here, if this is set: then we would need here roughly this code: So in addition to fRunPrearm checks, a completely new if statement below that one: /* re-run the pre-arm check as long as sensors are failing */
if (!status->condition_system_sensors_initialized && (new_arming_state == vehicle_status_s::ARMING_STATE_ARMED ||
new_arming_state == vehicle_status_s::ARMING_STATE_STANDBY)
&& status->hil_state == vehicle_status_s::HIL_STATE_OFF) {
prearm_ret = prearm_check(status, mavlink_fd);
} The issue you will run into is that it will spam you on boot. Which is why the vehicle_status needs to get that sensor fail bit mask and the pre-arm check should only report something via MAVLink if the failure bit is not already set. Then the whole reporting logic can be simplified based on that. Let me know if you think you know what to do, else I'll have a go at this. |
@LorenzMeier Ah, I see. I'd be glad if you had a try at fixing this. I spent nearly 3 hours on this. Kinda frustrated, sorry. I'll be happy to join in back tomorrow when I've got my head in order. |
@LorenzMeier Woohoo! It works! No spamming, just like we wanted :) #3171
Still tracking down a thing or two, so PR is WIP |
Thanks for fixing this! |
@LorenzMeier I am also getting this error. I cant arm from the ground station GUI or from my remote. ESC is just beeping waiting and seems to be stuck in programming mode. LED safety switch is flashing quickly red and all sensors seem to be configured ok. |
I presume you have 1) The beta firmware installed (if not, please install it instead of the default) and 2) USB NOT connected? |
I digged deeped into the issue in #3122, and it seems that this is an independent problem.
After full system setup (calibration and everything), once I reboot, the LED flashes red on startup and refuses to let me arm (symptom of failing pre-flight checks or incomplete boot ?)
QGC shows this :
No reason for rejection is shown.
Entering via USB console and doing a commander stop-start results in the system going to standby mode with the normal blue LED heatbeat.
@LorenzMeier Any ideas? I'm running a Pixhack board, and it's rather difficult to access the serial console for now, since it is mounted deep inside the airframe. Is there any way to dump bootlogs/console output to a file on the SD card?
The text was updated successfully, but these errors were encountered: