PX4 Dev Call: February 26, 2020

rroche · February 19, 2020, 6:14pm

February 26, 2020

Agenda

Status update by component
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

Hardware

Flight Testing

Question

Is there any supported hardware that the test team isn’t working with?

Driver

New drivers by @dagar

github.com/PX4/PX4-Autopilot

[WIP] px4_fmu-v5/v5x enable SPI and switch to new InvenSense drivers (icm20602 and icm20689)

PX4:master ← PX4:pr-fmu-v5_new_imu_drivers

opened 12:28AM - 26 Feb 20 UTC

dagar

+153 -73

Similar to https://github.com/PX4/Firmware/pull/14184. This PR switches to the n…ew icm20602/icm20689 drivers on px4_fmu-v5/v5x. The NuttX side (https://github.com/PX4/NuttX/pull/85) still needs to be resolved, but opening this now to enable further testing. - 8 kHz gyro, 4 kHz accel - DLPF disabled - scheduled using data ready interrupts where possible - FIFO is emptied at 1 kHz, but can adjusted via `IMU_GYRO_RATEMAX` from 250 Hz - 4000 kHz. FYI @dinomani - SPI DMA on v5x should help reduce the overload load. - [ ] px4_fmu-v5 - [ ] DMA map - [ ] sensor rotations - [ ] flight test - [ ] closely review CUAV fmu-v5 boards that contain both icm20602 & icm20689 - [ ] px4_fmu-v5x - [ ] DMA map - [ ] sensor rotations - [ ] flight test - [ ] verify ism330ldc performance with SPI DMA enabled

Commander

Enabled RC override on all the auto/modes by @MaEtUgR

github.com/PX4/PX4-Autopilot

Commander: enable RC override during takeoff

PX4:master ← PX4:rc-override-in-takeoff

opened 12:58PM - 24 Feb 20 UTC

MaEtUgR

+5 -2

**Describe problem solved by this pull request** I find myself and other users …looking for why the pilot is not able to take over control by moving the sticks during the auto takeoff. The use cases can be - the pilot seeing things going wrong during takeoff e.g. suddenly something is above the drone - takeoff altitude being to high - pilot being impatient - takeoff waypoint doesn't get reached for some reason like with the problem described in https://github.com/PX4/Firmware/pull/14193#issuecomment-589091770 **Describe your solution** I'm adding the `AUTO_TAKEOFF` mode to the modes where the pilot can take over control using the sticks. Also I'm adding the remaining other auto flight modes which are used more rarely from the list here: https://github.com/PX4/Firmware/blob/f3fefd7d9372ec98d404e2e99da2e251114a2d7e/msg/commander_state.msg#L7-L17 **Test data / coverage** We are flying the takeoff being available to override by the pilot for one client for more than a month now. I quickly rechecked in SITL that it all works like expected.

VTOL

fix by @sfuhrer

github.com/PX4/PX4-Autopilot

VTOL: run vtol state update not only when mc or fw sp are updated

PX4:master ← PX4:pr-run_update_VTOL_state_always-master

opened 01:06PM - 26 Feb 20 UTC

sfuhrer

+15 -17

Currently the VTOL transition state update is only run when there is a setpoint …change of either a the mc_attitude controller or the fw_attitude controller. This is a big problem if, for some reason, they are not updated for some time, eg because of a malfunction. This happened to me recently: After doing a transition to fixed-wing mode in altitude control mode, with a vehicle without GPS, it froze the attitude sp (see https://github.com/PX4/Firmware/issues/14243). Switching back to multicopter was not possible due to the above noted, and it only switched to MC when I also changed to stabilized. **Describe problem solved by this pull request** Ability to switch VTOL state independently of attitude sp changes. **Describe your solution** Check the VTOL transition switch every time the VTOL module runs. This results in slightly increased cpu load, eg the average cycle time of the VTOL module increased by roughly 1% (checked with perf). Changes seem not be significant enough to show on the overall CPU usage. **Describe possible alternatives** Fix https://github.com/PX4/Firmware/issues/14243 and make sure that we have updated att sp even when the FW/MC pos controllers break down. **Test data / coverage** Bench and flight tested.

Multicopter

acceleration-based control/feed-forward by @MaEtUgR

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.

Avoidance

CP/OA Improvements by @mrivi

Simulation

set sensor update rate according to HIL_SENSOR by @TSC21

github.com/PX4/PX4-Autopilot

simulator: set sensor update rate according to HIL_SENSOR bitmask

PX4:master ← PX4:fix/simulator_sensor_rate

opened 11:09AM - 25 Feb 20 UTC

TSC21

+202 -23

**Describe problem solved by this pull request** Fixes https://github.com/PX4/F…irmware/issues/14220. **Describe your solution** A check is made to the bitmask field in `HIL_SENSOR` Mavlink message and according to how the bitmask is set, the respective sensors get updated. This allows to properly set the sensor rate for each sensor source. **Test data / coverage** In SITL, running `uorb top sensor_accel sensor_gyro sensor_baro sensor_mag`: ```console update: 1s, num topics: 69 TOPIC NAME INST #SUB #MSG #LOST #QSIZE sensor_gyro 0 1 249 248 4 sensor_accel 0 1 249 248 4 sensor_gyro_integrated 0 2 249 0 1 sensor_accel_integrated 0 2 249 1 1 sensor_baro 0 1 42 41 1 sensor_mag 0 1 84 83 1 sensor_gyro_status 0 0 10 9 1 sensor_accel_status 0 2 10 18 1 ``` Note that baro is a bit lower than 50Hz and mag lower than 100Hz. The reason is that they are dependent of the Subscription callbacks in Gazebo, which have lower priority than the `OnUpdate()` function thread. A possible fix can be found by running specific Mavlink publishing threads for each of these sensor sources.

Community Q&A

PX4 v1.11 Release

Next beta release on March 9

Hardware Support

mRo

Control 0, hardware status? needs issue report

Drotek

Dropix & Pixhawk 3 won’t be manufactured soon.
New FMUv5 hardware to be released

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.