Skip to content
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

Transition Denied: ARMED to INIT while midflight #14158

Closed
mickeyhorn opened this issue Feb 13, 2020 · 10 comments
Closed

Transition Denied: ARMED to INIT while midflight #14158

mickeyhorn opened this issue Feb 13, 2020 · 10 comments

Comments

@mickeyhorn
Copy link

Describe the bug
Seemingly randomly while flying, QGC would print out the following warning message:
"TRANSITION_DENIED: ARMED to INIT"
Nothing besides the warning would happen. QGC would just yell it out and the drone continued on its merry way.

To Reproduce

  1. Drone connected to laptop running QGC via USB.
  2. Mission file uploaded to the drone.
    Chir_Test_2.1.20_medpoints_sortie0.txt
  3. Drone disconnected from laptop. Powered on with LiPo battery.
  4. Mission started. Drone flies normally.
  5. Warning randomly pops up a few times midflight, but no change in drone behavior.

Expected behavior
I expect no warning to appear.

Log Files and Screenshots
https://review.px4.io/plot_app?log=80aa1e55-af2c-4483-bb2e-b60055cb08fb
You can see the warning message at the very bottom of this page.

Drone (please complete the following information):
It's a custom-built hexarotor using a Tarot 690S frame, a Pixhawk 2.1, the DJI E800 propulsion system, a Here+ RTK GPS, a FrSky X8R receiver, a Holybro 915MHz telemetry radio, a Mauch 4-14S BEC, and a Mauch current sensor.

Additional context
I am still running PX4 version 1.9.2 on this drone. It has flown multiple times before without receiving this warning, and has received minimal changes since it's last flight without the warning. The only change I can remember offhand is replacing the SD card in the Pixhawk, because we were having errors with our logs being cut short.

@julianoes
Copy link
Contributor

Nice pattern you flew there 😄.

My only guess is that somehow you sent a calibration command to the vehicle, and you would then end up here:

https://github.com/PX4/Firmware/blob/342e0da7961f9a3301706ed3835cfc163b14b2ed/src/modules/commander/Commander.cpp#L3266-L3279

Was any other ground station connected? Or anything like MAVSDK or MAVROS sending commands?

@mickeyhorn
Copy link
Author

Hm, I don't believe we tried to start a calibration of any sort during the flight. And no, we only had the one ground station and 1 Taranis controller communicating with the drone.

@julianoes
Copy link
Contributor

I'm very confused then. Is there any other hint what went different on that flight? Any other observations?

@mickeyhorn
Copy link
Author

Not that I can remember. I'll try to push for our group to do another flight this weekend to try and replicate it.

@smnogar
Copy link
Contributor

smnogar commented Feb 24, 2020

I just had this happen, also running 1.9.2 (although slightly modified). We were sending offboard commands to the flight controller from MAVROS trying to test RC failsafe behavior. We had someone walk away from the vehicle holding the RC controller. When the RSSI signal went to zero, we got the error Transition Denied: ARMED to INIT instead of the RC failsafe triggering. The motors continued to spin. However, we have modified the state machine such that if RC is lost while receiving offboard commands, the RC failsafe triggers.

We repeated this test several times after this failure, and it worked as intended (i.e. the motors stopped spinning). So I'm not sure what was different about this test that we got this error.

Hardware was a pixracer and radios were spektrum.

@smnogar
Copy link
Contributor

smnogar commented Feb 27, 2020

On further investigation, I don't think this error caused the RC failsafe behavior. I think it was coincidental and that RC was never lost.

@MaEtUgR
Copy link
Member

MaEtUgR commented Mar 30, 2020

that somehow you sent a calibration command

It's enough to switch to the radio tab in QGC to send out such a command and trigger this warning.

@MaEtUgR
Copy link
Member

MaEtUgR commented Mar 30, 2020

It's reproducable in SITL by opening the Radio tab see #14527

@dagar
Copy link
Member

dagar commented May 4, 2020

Should be fixed in #14825.

@dagar
Copy link
Member

dagar commented May 6, 2020

Fixed in #14825.

@dagar dagar closed this as completed May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants