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

[WIP] Offboard mode topic restructure #3031

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Conversation

hamishwillee
Copy link
Collaborator

@hamishwillee hamishwillee commented Feb 1, 2024

This attempts to improve the offboard mode topic so it is more clear how things work and to ease splitting it in future.

Still thinking about it.

Comment on lines 5 to 14
The _Offboard_ mode allows PX4 to be controlled by some source that is external to the flight stack, such as a companion computer.

The offboard controller supplies a stream of position, velocity, acceleration, attitude, attitude rate, or thrust/torque setpoints, which are injected into the [PX4 control architecture](../flight_stack/controller_diagrams.md) as though they had been generated by the equivalent internal controller — the corresponding internal controllers that would otherwise have generated the setpoint (in another mode) are turned off.

The setpoints may be provided using MAVLink (or a MAVLink API such as [MAVSDK](https://mavsdk.mavlink.io/)) or by [ROS 2](../ros/ros2.md).
PX4 requires that the external controller provides a continuous 2Hz "proof of life" signal, by streaming any of the supported MAVLink setpoint messages or the ROS 2 [OffboardControlMode](../msg_docs/OffboardControlMode.md) message.
PX4 enables offboard control only after receiving the signal for more than a second, and will regain control if the signal stops.

Different vehicle frame types implement different [control architectures](../flight_stack/controller_diagrams.md).
As a result the setpoints and setpoint combinations that can be set depend on the vehicle.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@beniaminopozzan How you going? This is my understanding of how offboard mode works (irrespective of ROS2 or MAVLink). Is it correct?

Specifically, the bit about how we inject in the control architecture, and the bit about different vehicle frames implementing different architectures being the reason we can't use the same setpoints/setpoint combinations in all cases.

There might also be a subtlty that some combinations just aren't tested.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @hamishwillee . Nicely busy :) How about you?

Yes, this is how offboard control works.
The setpoints are injected in different ways between MAVLink and ROS 2, in particular MAVLink adds a level of abstraction as MAVLink messages are converted in uorb. The ROS 2 approach instead goes straight at the uorb level. This is why MAVLink offboard control does not require the "prof of life" while ROS 2 does.
There is activity in trying to simplify this though: PX4/PX4-Autopilot#22530

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @beniaminopozzan - busy too. A bit refreshed from my holiday though which is good.

So what we have now in docs for ROS2 is that:

  1. you stream OffboardControlMode at 2Hz to configure which controllers to turn off, and as proof of life.
    • After streaming for 1s at this rate you can enable Offboard mode. If you stop streaming at this rate the system will fall out of offboard mode.
  2. You call the setpoint messages for the external setpoints you want.

But what is missing here is that:

  1. Before you switch to offboard mode or after falling out of it there is nothing in PX4 that will stop the setpoints from being set. In other words the whole proof of life thing does affect changing the offboard mode, but unlike with MAVLink this isn't actually any kind of safety feature on its won.
  2. You can fall out of the mode.

How are you expected to handle this case? I don't think the docs cover this? My guess from the linked PR is that you are supposed to monitor the mode as well, and only send the setpoints when the mode is enabled. What's the right way to do that?

As I understand the linked PR everything can work exactly as above.
What is added is some "proxy" offboard topics for some of the topics. If you're in offboard mode these are used to set the real offboard topic, and if not, then they don't. So you would write to those topics instead and using offboard mode would be like MAVLink but without the need to stream setpoints at a minimum rate for proof of life.

It's going to be a bit more messy to describe, but not much more than now.

@hamishwillee hamishwillee changed the title [WIP] Offboard mode restructure [WIP] Offboard mode topic restructure Feb 6, 2024
Copy link

github-actions bot commented Feb 7, 2024

No flaws found

@@ -2,12 +2,17 @@

[<img src="../../assets/site/position_fixed.svg" title="Position fix required (e.g. GPS)" width="30px" />](../getting_started/flight_modes.md#key_position_fixed)

The vehicle obeys position, velocity, acceleration, attitude, attitude rates or thrust/torque setpoints provided by some source that is external to the flight stack, such as a companion computer.
The setpoints may be provided using MAVLink (or a MAVLink API such as [MAVSDK](https://mavsdk.mavlink.io/)) or by [ROS 2](../ros/ros2.md).
The _Offboard_ mode allows PX4 to be controlled by some source that is external to the flight stack, such as a companion computer.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self. Intent is to push the ROS 2 specifics and MAVLink specifics as far as possible into those instructions. The MAVLink part more or less done but the ROS 2 not yet done, as is pending response to #3031 (comment)

When that is done probably merge the content in the top of page and description into the description (as far as possible) as there is duplication now.

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

Successfully merging this pull request may close these issues.

None yet

2 participants