rroche
November 7, 2023, 5:00pm
1
The maintainers meeting is a meeting for the developer team to coordinate on pressing issues and to plan the development of the PX4 Autopilot project, the community is welcome to join and listen, but won’t be able to speak unless specific access is granted ahead of time.
Finalize maintainer role description
Identify maintainer opportunities
Open mic for maintainers
PR is ready for final reviews
We need help with testing
Last examples goto and maybe flip
PX4:main ← PX4:external_modes_ros2
opened 09:16AM - 06 Dec 22 UTC
### Goal
Create a library and interface for writing ROS2 applications that cont… rol the drone. This includes high-level navigation tasks all the way down to direct actuator controls.
It goes much further than the existing offboard mode:
- the ROS2 mode behaves the same as an FMU-internal mode:
- it can provide a name that is selectable in the GCS
- it can provide its own arming checks and mode requirements
- integrated into failsafe state machine
- there are clear rules for who is controlling the drone (see mode executor below)
- it's well-defined which setpoints can be sent
- a ROS2 mode can replace an FMU-internal mode
- multiple ROS2 modes & executors can co-exist and run (up to 8 can be registered)
### Concepts
This adds a few new concepts based on existing ones:
**Flight Mode**
- Is passive, does not execute other modes (or commands)
- Is activated via a mode executor / user / FC
- Selects and sends setpoints to the FC (e.g. velocity)
- Has a name displayed by the GCS
- Can configure its mode requirements
**Mode Executor**
- Can select modes and send commands when it is in charge (and wait for completion)
- Selects exactly one ‘owned’ mode. This is typically a custom mode that then generates the setpoints to perform the desired task.
- The executor is in charge when the owned mode gets selected and stays in charge until failsafe is triggered or the user switches modes.
- There can be multiple executors, but at most one is in charge at any given time
- In terms of FMU implementation, the `navigator` module corresponds to the mode executor (it currently does more than that though, also implementing several modes)
- Note that this is not a recursive definition (executors cannot activate other executors)
**Config Overrides**
Both, modes and executors can define configuration overrides. Two are defined and implemented currently:
- disable auto-disarm. Allows for landing and then taking off again
- ability to defer non-essential failsafes. Allows for e.g. an executor to execute a critical action w/o being interrupted by low-battery failsafe.
**Mode Replacement**
An external mode can replace an internal one, for example a sophisticated RTL. Both triggering RTL failsafe or a user selecting RTL in the GCS will then use the external mode instead. If the external mode crashes, the internal one will be used as fallback. This is currently based on regular arming check request timeout (could later be extended to include setpoint timeouts too).
**Mode Completion**
For an executor to know when to continue, there's a new topic `mode_completed` added, published by takeoff, rtl, etc.
### Example Usage
A flight mode looks like this:
```cpp
class FlightModeTest : public ModeBase
{
public:
FlightModeTest(rclcpp::Node &node)
: ModeBase(node, Settings{"My Mode"}, ModeRequirements::manualControlledPosition())
{
setSetpointUpdateRate(60.f);
}
void checkArmingAndRunConditions(HealthAndArmingCheckReporter &reporter) override
{
// custom checks
}
void onActivate() override
{
setpoints().configureSetpointsSync({});
}
void onDeactivate() override {}
void updateSetpoint() override
{
// send setpoint
}
private:
};
```
And a mode executor in the form of a simple state machine:
```cpp
class ModeExecutorTest : public ModeExecutorBase
{
public:
ModeExecutorTest(rclcpp::Node &node, ModeBase &owned_mode)
: ModeExecutorBase(node, ModeExecutorBase::Settings{false}, owned_mode),
_node(node)
{}
enum class State {
Reset,
WaitForArming,
Arming,
TakingOff,
MyMode,
RTL,
WaitUntilDisarmed,
Shutdown,
};
void onActivate() override
{
runState(State::WaitForArming, Result::Success);
}
void onDeactivate(DeactivateReason reason) override
{}
void runState(State state, Result previous_result)
{
if (previous_result != Result::Success) {
RCLCPP_ERROR(_node.get_logger(), "State %i: previous state failed: %s", (int)state, resultToString(previous_result));
return;
}
RCLCPP_DEBUG(_node.get_logger(), "Executing state %i", (int)state);
switch (state) {
case State::Reset:
break;
case State::WaitForArming:
waitReadyToArm([this](Result result) { runState(State::Arming, result); });
break;
case State::Arming:
arm([this](Result result) { runState(State::TakingOff, result); });
break;
case State::TakingOff:
takeoff([this](Result result) { runState(State::MyMode, result); });
break;
case State::MyMode:
scheduleMode(ownedMode().id(), [this](Result result) { runState(State::RTL, result); });
break;
case State::RTL:
rtl([this](Result result) { runState(State::WaitUntilDisarmed, result); });
break;
case State::WaitUntilDisarmed:
waitUntilDisarmed([this](Result result) { runState(State::Shutdown, result); });
break;
case State::Shutdown:
rclcpp::shutdown();
break;
}
}
private:
rclcpp::Node &_node;
};
```
### Other
- Implements and depends on https://github.com/mavlink/mavlink/pull/1915
- I have some example modes if anyone is interested
- Flash usage is ~20KB, and ~8KB for flash constrained builds
### TODO's (for later)
- main missing part: control interface (defining setpoints)
- test on hw
- param handling
- move the lib into own repo, add `px4_ros_com` (the transformations)
- metadata handling for custom checks
- CI: run tests
- mode activation by command with configuration (e.g. orbit)
- log mode names
- ...
PX4:main ← PX4:px4_sdk
opened 01:48PM - 20 Sep 23 UTC
Documentation for https://github.com/PX4/PX4-Autopilot/pull/20707.
Some bits … are still missing & it needs integration with the other pages.
@hamishwillee if you want you can already take a first pass. @tstastny will go through the steps to see if anything is missing.
PX4:main ← PX4:pr-uxrce-dds-service
opened 08:41PM - 05 Nov 23 UTC
### New Feature
- Add minimal support for requests and replies over micro xrce_… dds.
- The service `/fmu/vehicle_command`:
```
VehicleCommand request
---
VehicleCommandAck reply
```
replaces `/fmu/in/vehicle_command` and `fmu/out/vehicle_command_ack`.
### Base services
The virtual class `SrvBase` allows to define new services, each new service must implement its new constructor, the `process_request` method, which is called whenever a new request is received the `process_reply` method, which process and send the reply. `VehicleCommandSrv` gives an example of implementation.
The registration of new services is performed by `UxrceddsClient::add_replier()`, the maximum number of services that can be instantiated is fixed by `MAX_NUM_REPLIERS`.
### How to test
The easiest way to test this PR is in simulation.
The PR requires custom versions `px4_msgs`: PX4/px4_msgs#31 , which defines the new `px4_msgs::srv::Vehicle_Command` service.
Then a modified version of `px4_ros_com`: PX4/px4_ros_com#207 , which implements a version of the `offboard_control` node using `px4_msgs::srv::Vehicle_Command`.
### Changelog Entry
For release notes:
- Documentation: need to update documentation of https://docs.px4.io/main/en/middleware/uxrce_dds.html and https://docs.px4.io/main/en/middleware/uxrce_dds.html
- Documentation PR:
Question: Should we allow actuator control through external interfaces?
PX4:main ← PX4:pr-split-actuator-and-thrusttorque-offboard
opened 09:26PM - 15 Oct 23 UTC
### Solved Problem
- The `actuator` flag of the `offboard_control_mode` was ref… erring to _thrust_ and _torque_ control, requesting `vehicle_thrust_setpoints` and `vehicle_torque_setpoint`.
- direct actuator control (bypassing the control allocator) was not possible.
### Solution
- The current `actuator` flag of the `offboard_control_mode` is renamed `thrust_and_torque`.
- The new `actuator` flag disables the control allocator module. The offboard controller has then to provide `actuator_motors` and `actuator_servos` messages.
- New topics added to the uxrce_dds bridge (subscriptions). No additioal load is introduced as the topics are only used if published by the offboard controller.
- `vehicle_thrust_setpoints` and `vehicle_torque_setpoint`
- `actuator_motors` and `actuator_servos`
### Changelog Entry
For release notes: new feature: direct actuator control in offboard mode
Documentation: Need to clarify page https://docs.px4.io/main/en/flight_modes/offboard.html
November 14, 2023
Meeting Link
Agenda
Meeting Notes
External Flight Modes in ROS 2