Support OBC reboot/shutdown using GCS commands

[mhkabir]

@LorenzMeier @vooon
We need to support commands from GCS for shutting down or rebooting the OBC. Currently handling of commands from GCS is rather difficult, since mavros has no API for that.

This is a system-critical feature, as I have managed to do disk damage by improper shutdown of OBC.

@dogmaphobic interested as well :)

[vooon]

That task require processing gcs commands. So currently there no other choice than process it in gcs_bridge.

Another difficulties that halt requires root privileges, and i can't recommend to run bridge as root.
So extra step for sudoers config.

[vooon]

Or you think that gcs bridge also need plugin system?

[vooon]

Another option is to add somehow "power" button to OBC and setup OS to poweroff on long tap?

[LorenzMeier]

I would think that ROS has already an API to stop or reboot the machine - can we just use this / send a command to it?

[mhkabir]

@vooon
I did a sudoers config for my OBC for this very purpose, and I think it's easy enough for most users to pull off.
I think a plugin system for the GCS bridge would be very welcome, especially as we are expanding our capabilities. It would be useful for e.g sending back datalink quality data, images (already done in custom bridge) and handling the GCS commands meant only for the OBC.

@LorenzMeier ROS doesn't have a proper API for controlling the system power states. I can see vague references to custom scripts for the PR2 robot which allow this, but cannot find any actual code.

[dogmaphobic]

@dogmaphobic interested as well :)

Sure, if I lived in Venus maybe. At the least the days would be long enough to have time to do everything I want to do :)

Receiving data directly from GCS opens the door to a whole new level of interaction though. Not just the ability to shut it down.

[mhkabir]

@vooon I think this is mostly done by event_launcher. What else needs to be done?

Also, on a separate note :

Receiving data directly from GCS opens the door to a whole new level of interaction though. Not just the ability to shut it down.

[vooon]

Perhaps in 0.16 we may introduce plugins for gcs_bridge. But that means that internal bridge go away.

In case of that issue you need node that listens to /mavlink/to and interpret COMMAND_LONG/COMMAND_INT and trigger event_launcher to shutdown/reboot.

[mhkabir]

@vooon Any updates on this? Would you mind guiding me on how we can achieve this? :) Or could you maybe implement the plugin system for GCS bridge?

Opened #450 to track.

[vooon]

@mhkabir currently i'm little aware from flight projects (season ended + too expensive).

Topic issue may be achieved with one simple node:

1. subscribe to mavlink/to
2. handle COMMAND_LONG
3. call trigger service, e.g. obc_shutdown

digraph G {
FCU -> mavros -> gcs_bridge -> QGC;
QGC -> gcs_bridge -> mavros -> FCU;

mavros -> event_launcher;
gcs_bridge -> gcs_command -> event_launcher;
}

[vooon]

Also i'm thinking about change architect for ROS2: instead of plugins make it a bunch of nodes (more like nodelets). Then make mavlink message bus where each "plugin" will subscribe/publish. In that arch purpose limitation are gone: every one can directly access messages.

Downside is that current intraprocess or ros2 does memcopy for each subscriber (can't pass original pointer). Also there will be harder to support global state storages like UAS.

[TSC21]

@vooon any update on this? @mhkabir do you still require this? I'm also interested btw so maybe we can figure it out together?

[vooon]

No updates. :(

[TSC21]

In case of that issue you need node that listens to /mavlink/to and interpret COMMAND_LONG/COMMAND_INT and trigger event_launcher to shutdown/reboot.

Having a listener to /mavlink/to to interpret MAV_CMD_PREFLIGHT_REBOOT_SHUTDOWN may be hacky but should work. Though, the GCS plugin continues to be an interesting move.

[TSC21]

@mhkabir Should we close this and add a checklist to #450 in order to iterate over the feasability of this?

[vooon]

No, leave it open. Perhaps later i reiterate on that.

[TSC21]

@vooon the idea of closing it was not to abandon the implementation but to centralize it on a general GCS plugin that would allow this and other features. I see it as a must for a question of ease of UI that will allow the interaction of the user with the OBC running ROS.