rroche
August 3, 2022, 5:00pm
1
Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release
Specify what you are trying to achieve
Specify what environment / platform you are using
Prepare a Link or Document to help understand if possible
First, ask the question on the Slack or create a Github Issue !
If you take over 5 minutes for the question, please continue in Slack or a Github Issue.
Have a custom MAVROS for ROS2, and have been using PlotJuggler for plotting live during flight.
With direct DDS communication, the translation of MAVLink message to ROS topic would be eliminated, which is convenient
DDS connection may suffer from lossy connection (e.g. Over the Air Telemetry Radio), so MAVLink communication can be better there
Let’s say we have 1000 ~ 2000 us range Actuator. And you need to trim it to one side. Would it then leave a ‘deadspace’ in the maximum control signal? (Or does it linearly map the input to output so that we still have full range of motion?)
The trim should be in the hardware level (e.g. PWM in microseconds)?
But that would lead to *multiple trim settings for different output protocols (CAN, PWM, etc)
It is still unclear if we want to bring the airspeed consideration into control allocator, but would be nice to discuss together.
PX4:main ← PX4:pr-fw-rate-control
opened 12:16PM - 13 Jul 22 UTC
## Describe problem solved by this pull request
Yaw rate was previously not con… trolled for fixed wings. This made it hard to integrate offboard control methods that might want to control body rates (and eventually yaw rates) directly.
This is due to the fact that fixed wing attitude control uses separate ECL controllers for each axis (roll, pitch, yaw) and specifically yaw rate control is only calculated using the current roll to maintain coordinated flight.
## Describe your solution
This commit makes the `fw_att_control` share the rate controller as a library with the `mc_rate_control` module.
- Enables passing yaw rate setpoints directly in offboard mode
- Allows controlling yaw rate setpoints in acro mode through the sticks
- Allows controlling yaw rate setpoints in offboard mode
- Removes euler body rate control from the ECL controllers
- By using the rate control library, the fw attitude controller now uses angular acceleration estimates for rate control
The attitude control and turn coordination is still done through ECL controllers
- [x] Add airspeed scaling
- [x] Improve tracking performance (Done by @sfuhrer )
## Describe possible alternatives
A clear and concise description of alternative solutions or features you've considered.
## Test data / coverage
- Tested in SITL Gazebo: [flight log](https://review.px4.io/plot_app?log=9a7a4bf1-fe63-4766-b1c5-250086de104a)
```
make px4_sitl gazebo_plane
```
- NOT tested on hardware
## Additional context
fixes https://github.com/PX4/PX4-Autopilot/issues/12886
Made a change in driver to enable RTCM passing through directly to the Rover
Currently for Rover startup script, it disables UART2.
Currently for Underwater Robot SITL, we are not using hydropressure sensor data, and is now using barometric data.
Exciting possibility of having real-time PlotJuggler plotting generic uORB data via DDS connection
Timestamp setting discussion
PX4:master ← TSC21:pr-add_timestamp_to_msgs
> > This is probably the right change short term, but longer term what we really… need is a timestamp metadata field that corresponds with the actual orb publish. When a sample timestamp is needed it should be added and set explicitly.
> >
> >Think about it from the perspective of log review. What you're plotting is quite often not what the system actually saw at that particular time.
>
> I see your point but currently ROS IDL generators require the timestamps to be explicitly set on the msg definitions, and not autogenerated.
>
This is only because the timestamp (uorb metadata) was manually added to microcdr and urtps, which was a bit of a hack.
A solution that would both be simpler now and better for PX4 long term is to leave the uORB metadata side alone and remove the manual timestamp additions for RTPS.
- https://github.com/PX4/Firmware/blob/master/msg/templates/uorb_microcdr/msg.cpp.template#L150-L162
- https://github.com/PX4/Firmware/blob/master/msg/templates/urtps/msg.idl.template#L73
Then in the small number of cases where you actually need the sample timestamp (IMU) you add that field explicitly in the .msg (timestamp_sample). Later in PX4 we can push the timestamping into orb_publish itself and cleanup the replay system.
Would be better to consider it as a ‘metadata’ instead of a mandatory field user needs to fill in when publishing a uORB message.
PX4:main ← junwoo091400:pr_uorb_service
opened 09:50AM - 18 Jul 22 UTC
## Describe problem solved by this pull request
Currently uORB has no concept o… f a [Service](https://docs.ros.org/en/foxy/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services.html) or an Action, but rather has modules publishing / subscribing to topics in global context.
This is like having people talking loudly to each other in a open space, and we want to make that more into a civilized, one-to-one conversation based architecture where you don't need to hear / interpret what everyone is saying in the room :tea:
### ROS 2
Source: [ROS2 Foxy Documentation](https://docs.ros.org/en/foxy/_images/Service-MultipleServiceClient.gif)
In **ROS2**, Service and Action is used for defining a clear request / response structure between two entities where the messages are guaranteed to be delivered back & doesn't interfere with other modules sending messages in the same topic.
### Current status of PX4
This is useful for example when a certain module wants to do a `vehicle_command` to the Commander, and make sure that it receives the result of that command to know whether it was accepted / rejected / pending, etc.
Currently, PX4 has two separate topics such as `vehicle_command` and `vehicle_command_ack`, which basically implements the Service architecture (one is for sending the command & the other for receiving the result of it), but it never ties those two messages together, with two dedicated entities (e.g. Navigator & Commander) and it is just not so usable.
## uORB Service Architecture
### Google Doc
In [this document](https://docs.google.com/document/d/1Wzh4lwDiQ7evSyO_0ElSq_qMpU89nu0VJ1kMkNyrX2Y/edit#), you can find the architecture proposal.
### Pseudocode
A service has an argument & response.
Pseudocode (does not have to look exactly like this, just as an inspiration):
On **provider**
```
uORB::ServiceProvider<ORB_ID(argument_type), ORB_ID(response_type)> service(SERVICE_INSTANCE_XXX)
run() {
...
while (service.called()) {
argument_type arg;
service.get_call_arg(arg);
response_type response;
// DO PROCESSING
service.handle_call(response);
}
...
}
```
On **caller**
```
uORB::Service<ORB_ID(argument_type), ORB_ID(response_type)> service(SERVICE_INSTANCE_XXX)
// Invoke the service
future<response_type> future = service.call(argument, TIMEOUT);
// check if future is done or timeout
if (future.done() || future.timeout()) {
if (future.done()) {
response_type response = future.get()
} else {
// handle timeout error
}
}
```
## Questions
1. Can we do interoperability with ROS2?
2. What if there are multiple providers of the same service? Could we dynamically add new providers of a service, how would the other modules know which provider to call? -> E.g. multiple flight modes offering a “has_activated“ service
## Resources
- ROS2 Service Internals: https://docs.ros.org/en/foxy/Concepts/About-Internal-Interfaces.html
- https://github.com/ros2/rclcpp
-
Where is the ROS2 implementation / metadata architecture? → RMW libraries &
PX4:main ← PX4:pr-ekf2-multi-hgt
opened 03:56PM - 21 Jul 22 UTC
mostly based on https://github.com/PX4/PX4-Autopilot/issues/19671
#### Conce… pt:
Each height sensor can be independently enabled or disabled through a `EKF2_<sensor>_CTRL` parameter. All those sensors are fused as height observations by subtracting a bias that is estimated from the height estimate and the measurement except for the reference sensor selected by `EKF2_HGT_REF`. Note that the bias estimate and the height estimate are updated in parallel (i.e.: the height update uses the "old" bias estimate and the bias update uses the "old" height estimate) to avoid using the same information twice. When updating the bias estimate, we ignore the correlation between the height estimate and the measurement, making the bias variance optimistic but it still converges towards the reference on the long run.
#### Height source failure handling:
If the height reference is not available or the fusion of this source needs to stop, a secondary reference is automatically selected from a predefined table depending on the `EKF2_HGT_REF` parameter. When the secondary height reference takes over, it keeps its current estimated bias and doesn't get updated anymore; there is no reset of the states. If the secondary source fails as well, a 3rd one is selected and so on.
#### Inertial navigation free-fall detection:
The magnitude and the direction of all vertical aiding sources (height and velocity) is constantly monitored in order to detect a potential issue with the inertial navigation. If 1 source is strongly strongly trying to pull the inertial navigation upwards, the likelihood of having the inertial navigation free-falling is considered "medium" while if more independent sources are doing the same thing, the likelihood is considered "high". When the likelihood is "high" or when it is "medium" and accelerometer clipping is detected, the innovation no longer reject measurements; the fusion is forced but with an innovation limited by the innovation gate size in order to recover the bad inertial navigation.
#### New parameters:
- `EKF2_BARO_CTRL`: en-/disable baro fusion
- `EKF2_GPS_CTRL`: selects GPS hpos/vpos/3Dvel/yaw fusion
- `EKF2_RNG_CTRL`: selects range fusion type ("conditional" is the current "range aid"), replaces `EKF2_RANGE_AID`
- `EKF2_HGT_REF`: is the long-term "non drifting" height reference. GPS height is preferred when using GPS+BARO (+range conditiona); replaces `EKF2_HGT_MODE`
#### Typical configurations:
- Outdoor (default settings):
- `EKF2_BARO_CTRL = 1 (enabled)`
- `EKF2_GPS_CTRL = 7 (lon/lat/alt/3d_vel)`
- `EKF2_RNG_CTRL = 1 (conditional)`
- `EKF2_HGT_REF = 1 (GPS)`
- Indoor (non-flat ground):
- `EKF2_BARO_CTRL = 1 (enabled)`
- `EKF2_RNG_CTRL = 1 (conditional)`
- `EKF2_HGT_REF = 2 (range)` (learns baro bias when hovering)
- Indoor (flat ground):
- `EKF2_BARO_CTRL = 1 (enabled)`
- `EKF2_RNG_CTRL = 2 (always)`
- `EKF2_HGT_REF = 2 (range)`
- External vision (e.g.: VIO, motion capture)
- `EKF2_HGT_REF = 3 (vision)`
- en-/disable other sources as needed
TODO:
- [x] review timeout values
- [ ] bias estimators tuning
- [x] fix inertial nav falling check
- [x] add a ton of unit tests
- [x] parameter migration
- [x] support range aid
Would love to get feedback & test logs!
PR is coming up with all the learnings
And found a bug in Multicopter Attitude controller
PX4:main ← PX4:fix-mc-stabilized-throttle-scale
opened 09:40AM - 10 Aug 22 UTC
## Describe problem solved by this pull request
https://github.com/PX4/PX4-Auto… pilot/pull/12542 made the lowest possible throttle value commanded by stick in Stabilized mode before taking off 0. The real world problem with this is that when takeoff is detected then the entire throttle scaling range jumps from
[0, MPC_MANTHR_MIN] to [MPC_MANTHR_MIN, MPC_MANTHR_MIN].
As a result whenever MPC_MANTHR_MIN is not set to 0 there is a thrust jump on every takeoff just at the moment takeoff is detected even when the stick is moved continuously.
## Describe your solution
Because of this, I suggest reverting to having a higher throttle value from the beginning on because it's less complicated and there's no obvious value in starting out with zero thrust if it's anyways not possible to go back to zero for safety once takeoff is detected.
## Test data / coverage
I tested this in simulation:
## Additional context
I found this problem while working on a helicopter that is really sensitive to thrust setpoint jumps. It twitched frightening on every takeoff in Stabilized mode because of this bug:
Hi, we’ve come across a bug which results in a number of issues with the altitude limit in the Geofence.
In summary, an altitude breach violation can trigger unexpectedly, causing the drone to ascend to an inappropriate set-point. This breach violation will continuously trigger, causing the drone to climb even higher, unless you are aware of it’s behaviour. Below is a more in-depth explanation of trigger cases.
This can be very jarring for the remote pilot and I could easily see this leading t…
@DPatrick has a good understanding of this issue and may join the call to discuss this.
There is a stale PR that tried to implement this:
PX4:main ← junwoo091400:pr_generic_button_based_action
opened 10:16AM - 11 May 22 UTC
## Description
Early on, as described in this issue : https://github.com/PX4/PX… 4-Autopilot/issues/19341, the Mantis Remote controller with a RTL Button / Flight mode switch configuration was discovered to be impossible to configure, as currently the 'Button' mode for RTL is not supported. Remote diagram is added below.
In regards to this, @MaEtUgR created the PR : https://github.com/PX4/PX4-Autopilot/pull/19579, which added unit tests and support for being able to use the "Button based Flight mode switching" work along with the Flight mode selection switch, which was a feature added by this PR back then : https://github.com/PX4/PX4-Autopilot/pull/17270
However, this proved to be unusable on Mantis, as the "Button based Flight mode switching" uses the same flight modes configured as the Flight mode #1 ~ #6 in the Flight mode tab in QGC. Therefore, in order to make RTL button work, one of the flight modes need to be "Return", but this just doesn't make sense as configuring this special button shouldn't need to interfere with the flight mode selection switch.
## Proposal from this PR
This PR aims to bring in these **new changes** about the Button / Switch flight mode switching logic:
1. Support Button input for all the generic flight modes **as well as** other auxiliary functions like Killswitch, Gear, Camera, Video, etc. (Currently Button input is not supported with this flexibility)
2. Allow users to flexibly configure which channel is used for the trigger, and which action it triggers, and whether it is a switch or a button.
Therefore, it will **apply** the following concepts in the existing architecture:
1. Remove dedicated switch parameter / thresholds for the individual mode / actions (e.g. `RC_MAP_RETURN_SW`, `RC_MAP_LOITER_SW`, etc.)
2. Move the ActionRequest & VehicleCommand code from ManualControl module down to rc_update module level.
3. Remove the `manaual_control_switch` uORB message that was used for signaling which mode slot was active, whether RTL switch was engaged, etc.
### Architectural change diagrams
#### Current Architecture
#### Proposed Architecture
## TODOs
- [ ] QGC UI update to expose this setting to the Users
## Additional Context
- Related PR (that introduced `manual_control_switches` uORB message) : https://github.com/PX4/PX4-Autopilot/pull/16270
/attempt #19341
/claim #19341
Recently updated Issues / PRs in PX4-Autopilot Link
Pull Requests Issues
PX4 Dev Call: August 03, 2022
Discussion based on: High-Priority Queue · GitHub
2 Likes
Great notes, thanks for that!
1 Like
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
Project Updates
General Discussions
Weekly Overview
Github
Slack
Last Dev-Call
Release