PX4 Dev Call: March 11, 2020

rroche · March 4, 2020, 6:03pm

March 11, 2020

Agenda

Status update by component/project
Roadmap, and Release discussion
In-Depth discussions
Community Q&A

Join Meeting

Meeting ID: 946 175 205
Join using your mobile/desktop

Call in using your phone, find your local number: Zoom International Dial-in Numbers - Zoom

Component update

Flight Testing

Tony is back 52 Flights 3 Prs

NXPFMUk66 vehicle did not arm retest pending
Fix ecl CPU load, pixracer issues
Board configuration SPI, no issues

Direct download of binaries from Jenkins works thanks to Daniel.
This week it will be rainy and the test team will conduct bench tests and tries to do some indoor flights.

System Architecture

Board config simplifications by @bkueng

github.com/PX4/PX4-Autopilot

Board config: SPI & I2C config simplifications (1)

PX4:master ← PX4:spi_i2c_config_refactoring_boards

opened 04:16PM - 24 Feb 20 UTC

bkueng

+6203 -5709

This brings the 1. iteration from https://github.com/PX4/Firmware/pull/14156: ex…tending board configs with the new SPI+I2C config. With this PR the SPI reset and chip-select code uses the new configuration whereas the drivers still use the existing board config. The SPI address used to be some (arbitrary) board-specific number, which is now set to zero (and allows for extension to multiple instances of the same sensor type on one bus). To avoid having to recalibrate, code was added to do the transition on param import (https://github.com/PX4/Firmware/commit/7e03d4aa6aa80fd958dde8b04e2a64078bf5fd1d). Consolidation of separate Accel vs Gyro ID's was done as well. There's some tricky dependencies during bootup: the board hw detection requires ADC on some boards (v5), and the SPI init requires to know the board version. This leads to some changes in bootup on some of the boards. @davids5 let me know if you see a problem with that (board changes are in https://github.com/PX4/Firmware/commit/5a986aed4869c3c1ecef02390255ef1395e8b6b2). Other: - CPU load increases by ~1% on a pixhawk 2 cube due to the more generic SPI chip-select - FLASH usage: ~+800 bytes on v2 (the SPI config for all hw versions) - there's a fix for missing IO on pixhawk 2 mini Tested on these boards (comparing the boot output): - pixhawk 4 - pixhawk 2 mini (V2M) - cube 2.0 (V30) - mro pixhawk 2 (V2) - mro pixracer (+external SPI) - nxp/fmuk66-v3 - durandal - kakutef7 - omnibusf4sd - pixhawk 3 pro - v5x Next steps (the PR does not depend on those and can be merged independently): - update all drivers - remove the old board I2C+SPI configs

OS / NuttX

STM32F412 support by Jake for CUAV CAN GPS needs to go upstream and be backported.
NXP UAVCAN board work is done on NuttX upstream master.
- @igalloway asks when it can come into PX4 NuttX.
- TODO @david_s5 → will need an upstream merge, a backport is not enough.

Comms

uORB exists check much faster thanks to @dagar

github.com/PX4/PX4-Autopilot

uORB add bitset for faster orb_exists check and remove uORB::Subscription lazy subscribe hack/optimization

PX4:master ← PX4:pr-uorb_exists

opened 08:36PM - 05 Feb 20 UTC

dagar

+918 -199

One of the inefficiencies in legacy `orb_subscribe()` addressed by the new `uORB…::Subscription` was that attempting to subscribe to a topic would create the underlying device node (the orb topic publication). As a result we had several kilobytes worth of unused orb device nodes in many setups. In `uORB::Subscription` we avoid this by checking if the publication actually exists (equivalent to `orb_exists()`), however each `orb_exists()` call is relatively expensive. The short term optimization was to throttle the calls within `uORB::Subscription` after an initial 1000 attempts. The potential problem with this is a subscription might miss initial updates to topics that are only published late in flight. This PR makes those orb existence checks cheap enough we can use them in every single iteration by adding a bitset of atomic integers to the uORB DeviceMaster. Then I updated the orb generation to also create a class enum for ORB_IDs so that we have an index to use with the bitset. ### Master (sensor_accel 0, 1, 2 exist, but 3 and 4 do not) ``` Console orb_exists sensor_accel 0: 100 events, 983us elapsed, 9.83us avg, min 9us max 10us 0.377us rms orb_exists sensor_accel 1: 100 events, 1424us elapsed, 14.24us avg, min 14us max 15us 0.429us rms orb_exists sensor_accel 2: 100 events, 2031us elapsed, 20.31us avg, min 20us max 21us 0.464us rms orb_exists sensor_accel 3: 100 events, 3373us elapsed, 33.73us avg, min 33us max 34us 0.446us rms orb_exists sensor_accel 4: 100 events, 95us elapsed, 0.95us avg, min 1us max 1us 0.219us rms ``` ### PR ``` Console orb_exists sensor_accel 0: 100 events, 968us elapsed, 9.68us avg, min 9us max 10us 0.468us rms orb_exists sensor_accel 1: 100 events, 1408us elapsed, 14.08us avg, min 14us max 15us 0.272us rms orb_exists sensor_accel 2: 100 events, 2027us elapsed, 20.27us avg, min 20us max 21us 0.446us rms orb_exists sensor_accel 3: 100 events, 161us elapsed, 1.61us avg, min 1us max 2us 0.490us rms orb_exists sensor_accel 4: 100 events, 95us elapsed, 0.95us avg, min 1us max 1us 0.219us rms orb_exists sensor_accel 5: 100 events, 89us elapsed, 0.89us avg, min 1us max 1us 0.314us rms orb_exists sensor_accel 6: 100 events, 81us elapsed, 0.81us avg, min 1us max 1us 0.394us rms orb_exists sensor_accel 7: 100 events, 90us elapsed, 0.90us avg, min 1us max 1us 0.301us rms orb_exists sensor_accel 8: 100 events, 90us elapsed, 0.90us avg, min 0us max 1us 0.301us rms orb_exists sensor_accel 9: 100 events, 91us elapsed, 0.91us avg, min 1us max 1us 0.287us rms orb_exists sensor_accel 10: 100 events, 91us elapsed, 0.91us avg, min 0us max 1us 0.287us rms ``` In master `orb_exists()` for a topic that doesn't exist (with valid instance) is quite expensive because you have to search the entire list of topics. On fmu-v3 configured as a multicopter that's `33.73 us` (average). With this PR that same check is `1.61 us`. That might seem small, but it adds up across hundreds or even thousands of calls per second. Overall this saves a little bit of cpu (although quite a lot during the first 5-10 seconds of bootup) and a little bit of memory, despite increasing the size of the orb_metadata struct. More importantly it removes the possibility of subtle unexpected orb update behavior later in flight.

Driver

SPI DMA move primary IMU to new Invensense driver. It was dragging on because of NuttX issues with the dcache. Now it’s ready and we should be able to switch boards over.
- @david_s5 is concerned about the configuration coverage.
- There are PRs to switch over more boards.
- They should be tested and merged soon.

Commander

Cleanup by @dagar
- Outback challange old failsafe modes were alternatively available.
- We want to remove them to clean up Commander, Navigator, FlightTasks.
- It needs more testing.
- TODO > Add to release notes, talk to @dagar

VTOL

@dagar: disabling VTOL for FMUv2.
- The mechanism to inform the user needs to be clear, that’s currently the blocker.
- Call it out, avoid the user to be able to get into a bricked state, add error messages (pop-up in QGC) and inability to arm.
- It also needs to go into the release notes but with the wording, fmu-v2 is not supported by default but only with a custom setup or better with a custom build provided by the build system.
- @LorenzMeier, We should have a Commander function to see if the configuration is valid or unsupported. He has ideas and will do the first proposal.
TODO: call-out on release notes (fmuv2).

Fixed Wing

Move to run FW controller on vehicle_local_position update needs review and testing. by @dagar

github.com/PX4/PX4-Autopilot

FW position controller: move from global to local position

PX4:master ← PX4:pr-fw-pos-control-lpos

opened 09:23PM - 04 Mar 20 UTC

sfuhrer

+70 -59

With this PR the fixed-wing position controller is changed to consume local inst…ead of global position updates wherever possible (global position is still required for lat/long estimation feedback and thus for lateral position control). It thus enables the use of the altitude control flight mode for fixed-wing/VTOL systems that don't have a GPS sensor, or the GPS fails (thus eg fixes https://github.com/PX4/Firmware/issues/14243). **Describe problem solved by this pull request** Have a working fw altitude controller without global pos updates. **Describe your solution** Move subscription of fw pos controller from global to local pos where possible. **Test data / coverage** Sitl tested with a VTOL and plane. **Additional context** All credits to @dagar for initializing and implementing this!

Multicopter

Release block bugs that need testing by @MaEtUgR

github.com/PX4/PX4-Autopilot

mc_pos_control: handle landed and takeoff setpoint limiting the same way

PX4:master ← PX4:pr-fix-idle-thrust

opened 08:42PM - 08 Mar 20 UTC

MaEtUgR

+26 -32

**Describe problem solved by this pull request** @jkflying reported an effect I…'ve seen before: During a normal landing procedure the thrust gets first cut by the reaction to ground detected and then cut by the takeoff logic because the vehicle is back ready for another takeoff. ![image](https://user-images.githubusercontent.com/4668506/76170595-a4b29b00-6183-11ea-9898-7876a6628941.png) The problem is that the thrust and attitude limit while landing is in the loop order after the position controller ran and directly operates on the attitude setpoint skipping the position controllers minimum thrust limit. The takeoff thrust limitation on the other had is before the position controller and amends the input to it. **Describe your solution** I'm unifying the thrust and attitude limit logic to be in one place where it already was for the takeoff. Both logics for takeoff and landing do these things in common: - cut thrust - set roll pitch level - set yawspeed to zero and yaw setpoint to current yaw - reset position control integral I still have to check if reactivating flight task and reseting the hover thrust is also desired otherwise they can be conditional for just the takeoff. **Describe possible alternatives** It's not 100% clear to me if `MPC_THR_MIN` should be the minimum thrust at all times even during landing and takeoff or if the takeoff ramp should always start at zero thrust and thrust should go down to zero after landing. **Test data / coverage** Quick SITL test, needs more testing and review.

github.com/PX4/PX4-Autopilot

mc_pos_control: hotfix for takeoff ramp stuck with NAN

PX4:master ← PX4:pr-fix-nan-takeoff-ramp

opened 11:00AM - 10 Mar 20 UTC

MaEtUgR

+6 -0

**Describe problem solved by this pull request** Follow up to #13973 reported a…nd proposed by @dusan19. Summary: The takeoff ramp can get stuck with an upwards velocity limit of NAN which is a valid value in the interface and means do not limit. **Describe your solution** I propose to make sure just before the takeoff ramp calculation that the value is already the maximum and not NAN anymore. This leaves the interface for flight tasks and solves the problem described in #13973. I admit it's not the nicest of all solutions but with the context that - we want to move towards not constraining the velocity setpoint more than necessary in the middle of the position controller (which is what that variable was originally created for) - having the takeoff ramp class used in in flight tasks I think it's an acceptable fix. All the logic that changes the setpoints after the developer generated them in the flight task is prone to lead to problems. **Describe possible alternatives** #13973 **Test data / coverage** Untested, just quickly pushed for @dusan19 to test. I can test it later as well.

Hover thrust estimator by @bresch.
- suggests we can merge the functionality but not enable it by default.
- Needs to update the unit tests.
- Next steps are to do more tuning, Mathieu can do that on log replays and later on we can make it the default.

github.com/PX4/PX4-Autopilot

Acceleration based control/feed-forward

PX4:master ← PX4:acceleration-control

opened 06:19PM - 22 Feb 20 UTC

MaEtUgR

+236 -266

**Describe problem solved by this pull request** More or less last step to fini…sh splitting up and QAing PX4/Firmware#12072. It's based on #245 and introduces processing acceleration setpoints. This enables acceleration feed-forward which the jerk optimized flight tasks by @bresch immediately make use of. It also heavily reduces dependence between collective thrust and vehicle tilt making the demanded tilt less jerky when the altitude control output is changing. **Describe your solution** I make the velocity control output acceleration in m/s² which in theory would make the controller tuning more independent of the vehicle's thrust to weight ratio (~hover thrust) but for the initial introduction I introduce a scaling factor using the hover thrust to make the existing gains compatible. To separate the high-frequency altitude control changes from the collective thrust from the demanded tilt I'm switching control strategy to apply horizontal acceleration setpoints assuming hover/gravitational acceleration in the vertical direction effectively directly mapping it to the vehicle's tilt. The vertical acceleration gets projected onto the planned tilt and then executed by setting the collective thrust accordingly. Only in the limit case of more than the maximum thrust tilt gets coupled by being limited using vertical acceleration demand to ensure prioritizing altitude control over horizontal navigation. **Test data / coverage** For the basic limit cases, input combinations, failsafe and zero thrust inputs there are unit tests now. I did a lot of SITL testing and multiple outdoor tests with a 250 size, one test on a big multicopter. **Additional context** Refactorings that made this change possible: https://github.com/PX4/Firmware/pull/13247, https://github.com/PX4/Firmware/pull/13248, https://github.com/PX4/Firmware/pull/13262, https://github.com/PX4/Firmware/pull/13347, https://github.com/PX4/Firmware/pull/13701, https://github.com/PX4/Firmware/pull/14017 - [x] I still need to change the jerk limits for manual and auto since the tracking is tighter now. - I discussed with @Jaeyoung-Lim to expose the acceleration on the offboard interface to allow more dynamic flights and a different kind of input that doesn't rely on vehicle internal velocity estimate.

MAVROS / RTPS / ROS2

MicroRTPS time sync

github.com/PX4/PX4-Autopilot

microRTPS: add timesync

PX4:master ← PX4:feature/add_rtps_timesync

opened 05:47PM - 04 Mar 20 UTC

TSC21

+539 -81

Adds timesync for the microRTPS bridge. The agent is the one responsible to init…iate the time sync hand shake and compute the offset. The client, at this stage, just responds to the msgs. Eventually in the future the timesync being done on the Mavlink module will be generalised to be used also on the microRTPS client, but not need to do it right now.

github.com/PX4/PX4-Autopilot

microRTPS: fix timesync support and general cleanup

PX4:master ← PX4:pr-fix_rtps_raw

opened 02:27PM - 11 Mar 20 UTC

TSC21

+250 -226

https://github.com/PX4/Firmware/pull/14297 added timesync for the microRTPS brid…ge, but was only tested using `px4_ros_com`. While testing it with the raw microRTPS bridge (not `px4_msgs` dependent), I have found that the member function naming was different from the ones generated when using the `px4_ros_com` generation, which resulted on compiler errors. This lead to the need of adding some getters and setters to access some required fields on the bridge itself. So this PR: 1. makes sure that the timesync works in both `px4_ros_com` and the Firmware generated agent by adding getters and setters to class member functions (which access the msg fields); 2. adds a check for the Fast-RTPS lib version and uses it for the template code specialisation, instead of the FastRTPSGen version, which is much more convenient, as it allows to better synchronise the code with the version supported; 3. cleans the Publisher and Subscriber template code specialisation with a more convenient usage of typedefs. Tested in SITL with Gazebo, using both agents.

Avoidance

Enabling Bezier trajectories went in with the solution discussed in the last dev call.
Should go to release notes.
We should still discuss how to exclude libraries from builds in a nicer way.

github.com/PX4/PX4-Autopilot

Bezier trajectory avoidance interface

PX4:master ← PX4:pr-bezier-trajectory-interface

opened 04:13PM - 02 Mar 20 UTC

jkflying

+885 -16

**Describe problem solved by this pull request** Currently the avoidance interf…ace only allows specifying single position setpoints. This PR enables sending time-parameterized Bezier messages, allowing smooth flight control from the companion computer while in auto modes. **Describe your solution** Several parts: 1. A simple 5-line function to calculate a position given an N-order bezier curve and the current `T` value, templated on the type of number that is used 2. Use of Dual numbers to calculate the velocity (and even acceleration), from the above simple function, without needing complex formulae for each curve size. 3. Parsing of the bezier mavlink message, and translation into uORB 4. Subscribe to the uORB, and if the newly introduced bezier message has a valid duration, use that to determine the current position and velocity indicated by the bezier curve 5. Pass these values on using the existing avoidance setpoint injection Additionally, in order to save FMUv2 flash space, this PR moves the avoidance to a separate library and excludes it from `CONSTRAINED_FLASH` builds, replacing it with a dummy implementation. Thanks to @julianoes for the pointer with `CONSTRAINED_FLASH` - I think this is sufficient for now, but longer term I'd like to be able to do something like this via the board configuration similar to modules. @dagar any ideas on a good way to make this easy for the future, since I don't think this way scales? I'm sure there are other libraries that we'd like to replace with dummies for constrained flash builds, which can't be easily hoisted out into modules. **Describe possible alternatives** It might be better for this to not go through the smooth velocity interface, if it is shown that the companion can provide smooth enough curves, and rather send the data directly to the position controller. **Test data / coverage** Extensively unit tested. However there isn't yet a planner which can send the bezier messages, so this hasn't been flight or SITL tested. FYI @Stifael , since you did some earlier Bezier work.

MAVSDK

MAVSDK testing is work in progress.
@JulianOes is improving the setup for logging and display when things go wrong and be non-verbose when they pass.
It would be nice to have failing logs as artifacts or uploaded to flight review with a link posted.

github.com/PX4/PX4-Autopilot

MAVSDK testing improvements

PX4:master ← PX4:pr-mavsdk-tests-improvements

opened 05:15PM - 04 Mar 20 UTC

julianoes

+1384 -735

This includes MAVSDK testing improvements. The changes include: - SITL tests… defined in a JSON file. - less verbose output, no logs, unless an error happens - show test summary at the end - support verbose log output while still writing to log files - added colors to output - added cpp files to astyle check and added license header - properly exit on Ctrl+C - added type hints in Python script And this is what it looks like now: ![Selection_006](https://user-images.githubusercontent.com/1419688/76883575-add6f280-687c-11ea-9be9-ffa1807b063f.png)

Simulation

@Jaeyoung-Lim is working on a camera simulation such that the whole camera interface protocol can be tested and simulated.
- TODO: > add to release notes <
Roman looked into improving the dynamics and parameters such that they are more realistic.
- The models are ok but the parameters are too coarse.
- @LorenzMeier, We know much better now we should do improvement steps first just trying to resemble real vehicles than in a more systematic way.
- @Jaeyoung-Lim makes the first proposal, @MaEtUgR can help with testing.

Estimation

Yaw estimator that is able to estimate the heading from accelerometer and GPS data written by @Paul_Riseborough
Initialization of the tilt was based on accelerometer even when high acceleration was present, now it’s guarded to expected 1g ±10% acceleration to infer the initial tilt. by @bresch

Roadmap, and Release discussion

WIP v1.11 release notes

Release Timeline

Beta release - THIS WEEK
RC go/no go (live on dev call) - March 18th
Release go/no go - March 30th

Beta Testing the Release

Beta announcement (create a thread on the forums)
Clear instructions on how to test features and how to report back to the team
- Reach out to the community in general
- heads up to our partner network
Milestone board Release v1.11.0 Milestone · GitHub
(considering organization-wide kanban: v1.12 Release Coordination · GitHub)

@JingerZ : Callout needs to animate people to report successful flights on discuss thread and if they have an issue report it on GitHub starting the title with “1.11: …” such that it’s easy for us to add it to the “Release Blockers” board which users don’t have premissions to do.

Put your “have to have” points to the “Release Blocker” board. If you do you commit to push them through in the next days. Release 1.11 Blockers · GitHub

Community Q&A

https://github.com/PX4/Firmware/issues/14206

In-Depth discussions

@dagar

UAVCAN GPS support
CUAV Nora board
How do we architecturally handle Libraries. @jkflying

https://github.com/PX4/Firmware/compare/pr-cuav_gps

https://github.com/PX4/Firmware/pull/14272

github.com/PX4/PX4-Autopilot

Bezier trajectory avoidance interface

PX4:master ← PX4:pr-bezier-trajectory-interface

opened 04:13PM - 02 Mar 20 UTC

jkflying

+885 -16

**Describe problem solved by this pull request** Currently the avoidance interf…ace only allows specifying single position setpoints. This PR enables sending time-parameterized Bezier messages, allowing smooth flight control from the companion computer while in auto modes. **Describe your solution** Several parts: 1. A simple 5-line function to calculate a position given an N-order bezier curve and the current `T` value, templated on the type of number that is used 2. Use of Dual numbers to calculate the velocity (and even acceleration), from the above simple function, without needing complex formulae for each curve size. 3. Parsing of the bezier mavlink message, and translation into uORB 4. Subscribe to the uORB, and if the newly introduced bezier message has a valid duration, use that to determine the current position and velocity indicated by the bezier curve 5. Pass these values on using the existing avoidance setpoint injection Additionally, in order to save FMUv2 flash space, this PR moves the avoidance to a separate library and excludes it from `CONSTRAINED_FLASH` builds, replacing it with a dummy implementation. Thanks to @julianoes for the pointer with `CONSTRAINED_FLASH` - I think this is sufficient for now, but longer term I'd like to be able to do something like this via the board configuration similar to modules. @dagar any ideas on a good way to make this easy for the future, since I don't think this way scales? I'm sure there are other libraries that we'd like to replace with dummies for constrained flash builds, which can't be easily hoisted out into modules. **Describe possible alternatives** It might be better for this to not go through the smooth velocity interface, if it is shown that the companion can provide smooth enough curves, and rather send the data directly to the position controller. **Test data / coverage** Extensively unit tested. However there isn't yet a planner which can send the bezier messages, so this hasn't been flight or SITL tested. FYI @Stifael , since you did some earlier Bezier work.

@JulianOes

Way forward with PX4 unit tests, ntest, gtest:
Adding ntest for unit testing on NuttX by julianoes · Pull Request #12106 · PX4/PX4-Autopilot · GitHub

@JingerZ

Board classifications: https://docs.google.com/document/d/1PoPjdVciYmKLryhyuTbV_hgi6e-GfO2N2CaUW3S0wfA/edit?folder=1aBXQKeZkXKY5ZAPWJUtawQV1CsiNFutf

@TSC21

uORB topic metadata structure: [RFC] Metadata uORB message · Issue #14366 · PX4/PX4-Autopilot · GitHub

@david_s5

uavcan not working on Pixhawk 4 mini : UAVCAN Does Not Work on Pixhawk4 Mini · Issue #14206 · PX4/PX4-Autopilot · GitHub

Errata and Feedback

Let me know below if I failed to capture anything the right way, and if there are any updates, or you have feedback on the call format.