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

ArduRemoteID - Uncontrolled descent or loss of control #34

Open
sborenstein-ift opened this issue Aug 26, 2022 · 2 comments
Open

ArduRemoteID - Uncontrolled descent or loss of control #34

sborenstein-ift opened this issue Aug 26, 2022 · 2 comments

Comments

@sborenstein-ift
Copy link
Contributor

In order to meet the requirements of MOV 7.7.1.2, the RID module must report an emergency status (overrides SELF ID) when the UA experiences uncontrolled descent or loss of control.

Possible solutions may include a flag or code from the AP OpenDroneID module to the RID module to indicate this status.

@friissoren
Copy link
Contributor

The flight controller is sending Location messages regularly to the transmitter module.

When this situation occurs, the flight controller should set the status field field to MAV_ODID_STATUS_EMERGENCY. The transmitter module will include that in the next ping that it is transmitting.

Optionally, the flight controller can send also a SelfID with some further textual clarification of the type of emergency to the transmitter.

The transmitter module doesn't really need to be aware of any of this. It is just a "dumb" relay entity that gathers the information from the latest MAVLink message of each type and pings that out on the air. If the flight controller detects that the emergency is over, it just changes the status value to Airborne in the next Location message that it is sending (and optionally also sends a cleared SelfID message, if that is used).

What does needs to be figured out, is how the GCS and the flight controller deal with reporting emergencies, to avoid overwriting each-other. E.g. if the GCS loose the GPS/has low battery/whatever, since it is not sending the Location message regularly to the transmitter module, there are several ways to deal with this:

  1. A separate message is defined that the GCS uses to inform the flight controller about the emergency. The flight controller then keeps sending Location messages with the emergency status set until the GCS tells it to stop doing that.

  2. The GCS sends a Location message with the emergency status set (going to both the flight controller and the transmitter module) and the flight controller records this and also starts sending the emergency status in the Location messages that it is outputting (until the GCS sends a Location message with the emergency status cleared)

  3. The transmitter module is made smarter, so it is aware of Location messages coming from both the flight controller and the GCS. If either of those has set the emergency status, it stores that and overwrite this field in whatever Location messages it receives after that, until the entity that declared emergency clears it in another Location message.

Personally, I don't really like option 3. I think it would be better to keep the transmitter "dumb" and contain any intelligence to the flight controller and the GCS.

@friissoren
Copy link
Contributor

@ThomasDebrunner @tridge: Please see the above comment. It would probably be a good idea if both ArduPilot and PX4 align on a similar strategy to solve this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants