rroche
March 11, 2020, 5:01pm
1
Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Meeting ID : 946 175 205Join using your mobile/desktop
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...
Call in using your phone, find your local number : Zoom International Dial-in Numbers - Zoom
Mar 17, 2020
Call Moderators
@MichaelSchaeuble
@rroche
Agenda
Pixhawk Standard FMUv[5X, 6, 6X]
Pixhawk Smart Battery
Pixhawk Payload
Mailing List
Dail In
Join Zoom Meeting
One tap mobile
+14086380968,567710856# US (San Jose)
+16468769923,567710856# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 876 9923 US (New York)
+1 669 900 6833 US (San Jose)
Meeting ID: 567 710 856
Find your local number: https://zoom.us/u/aetSYKbiMF
Errata and Feedback
Let me kn…
PR #14168 contains a bug, and that’s why it didn’t arm in testing.
PX4:master ← UAV-Pilot:master
opened 12:17AM - 17 Feb 20 UTC
1. Added I2C drivers for 2 IMU sensors: FXAS21002C and FXOS8701CQ
2. Default … SPI speeds of some sensors are too high for some host systems, and there was no way to specify different SPI mode which the sensor supports besides the default SPI mode hard-coded in previous code. The code change provides option to specify alternative SPI mode and spi/i2c bus speed.
3. The I2C read/write code for FXAS21002C and FXOS8701CQ were modified from corresponding MPU9250 code. A buffer overrun bug was found and the fix was back ported to mpu9250 and mpu6000. It looks like the I2C drivers for mpu9250 and mpu6000 were not tested before.
4. Misc minor issues were fixed to pass compilation with gcc and clang compiler on Linux systems, mainly involving type conversion, printf format and unused variables.
PX4 Autopilot Flight Testing, by the Dronecode Test Team. Sponsored by Dronecode.
Link to log archive )
9 PR’s assigned
0 issue reported this week.
[image]
#14087
Added 2 IMU I2C drivers, SPI mode and bus speed option, fixed 1 I2C read bug, etc. #14168
sensors: move to uORB::Subscription and reduce CONFIG_NFILE_DESCRIPTORS 20 → 10 #1…
PX4:master ← volansi:pr-can-sensors
opened 04:15PM - 10 Mar 20 UTC
**Describe problem solved by this pull request**
This PR should allow multiple … sensors of each supported UavcanSensorBridge type (GNSS, mag, baro, etc.) to be published just like "normal" sensor drivers do. One particularly useful change is that you can now calibrate multiple UAVCAN-connected compasses along with your internal compass(es).
**Describe your solution**
- GNSS: use the same publication method as the other SensorBridge sub-classes (to allow multiple ORB instances)
- mag, baro: Use the PX4Magnetometer and PX4Barometer classes to create the sensor driver instances. This gets around the issue of having only one /dev/magx or /dev/barox registered from the SensorBridge class. It also lets those dedicated classes handle the ioctl calls for calibration and scaling.
**Describe possible alternatives**
Specifically for the compass bridge, the alternative would be to re-implement all of what PX4Magnetometer is already doing. Let's not re-invent the wheel here.
**Test data / coverage**
This has all been tested on a private fork; when I get a chance I'll test this specific PR and upload logs.
**Additional context**
I'll also be submitting a second PR soon that allows us to make use of >2 GNSS units connected via CAN (changes to EKF2 to support arbitrary numbers of GPS). My testing to date of this PR's features actually includes those changes as well.
PX4:master ← PX4:spi_i2c_config_refactoring_drivers_1
opened 09:35AM - 13 Mar 20 UTC
Follow-up to https://github.com/PX4/Firmware/pull/14221.
This converts a larg… e set of the drivers to use the new SPI and I2C board configuration. Mostly missing are mag's and imu's.
### General
- bus frequency and SPI mode is now configurable via CLI (with per-driver defaults)
- common driver CLI interface
- driver multi-instance support, also for I2C devices on the same bus (for the ones supporting different addresses). I tested with 2 spd3x airspeed sensors, on different buses and on the same bus with different I2C address.
- compared to https://github.com/PX4/Firmware/pull/14156, driver instances are now maintained in a global linked list (saves a bit of BSS RAM, on the cost of runtime).
- Flash size change is somewhat inconsistent, for some drivers it decreases, for others it increases (mostly due to ifdef'ed I2C code, and more arguments). Overall on v2 ~2KB increase.
- RAM usage decreases by ~0.6KB on Pixhawk 4
- I think if we have a general solution for the SPI vs. I2C device interface, we can get rid of the `instantiate` method.
- The (SPI) bus will only be accessed from the work queue, allowing to remove the SPI locking after all drivers are converted.
### Testing
Tested on:
- Pixhawk 2
- RPi with Navio2
- Pixracer
- Pixhawk 4
- KakuteF7
@UAV-Pilot this will conflict with https://github.com/PX4/Firmware/pull/14168 and I was hoping to get yours in first.
@dagar since you will probably have the fun to review this, let me know if you want to bring this in steps, and which step size you prefer.
PX4:master ← PX4:pr-preflight-status-report
opened 11:12PM - 07 Mar 20 UTC
This is essential for the operator to know if the system is ready to fly.
PX4:master ← priseborough:ekfYawResetLogging-wip
opened 11:08AM - 05 Mar 20 UTC
Required to log additional data required for flight testing when ecl version upd… ates to latest master containing https://github.com/PX4/ecl/commit/4669aa63121c6f91e2e034b6da05e35fbba98ca1
@sfuhrer working on bringing the fixed-wing position controller into the local frame
PX4:master ← PX4:pr-fw-pos-control-lpos
opened 09:23PM - 04 Mar 20 UTC
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!
@Jaeyoung-Lim has catapult launch working in simulation, but it’s not part of CI yet.
PR 14326 PR 14378 PR #14212
PX4:master ← PX4:pr-fix-idle-thrust
opened 08:42PM - 08 Mar 20 UTC
**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.
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.
PX4:master ← PX4:pr-hte-tuning
opened 05:08PM - 12 Mar 20 UTC
Follows #14182
Summary of the changes:
- Use a low-passed value of the signe… d innovation test ratio to trigger
the state variance boost. The threshold of 0.2 has been chosen using log
replay and simulation scenarii.
- Do not reset the learned accel noise during a state variance boost.
After a few tests, this does not seem to help at all.
- Continue to learn the accel noise even if the measurement got rejected
to avoid ignoring sudden changes of noise
- Lower the acceleration noise time constant and increase min/max
values to avoid learning quickly a small variance that could temporary
destabilize the filter
- Update filter time constants. Increasing the speed of the residual lpf
improves the quality of the learned accel noise
Replay from log https://review.px4.io/plot_app?log=82ee3e29-5422-450b-8030-df6a93b81a88 (given by the test team: https://github.com/PX4/Firmware/pull/14182#issuecomment-592782692)
Original data:
Replayed with tunning proposed by this PR:
:
PX4:master ← PX4:acceleration-control
opened 06:19PM - 22 Feb 20 UTC
**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.
PX4:master ← PX4:pr-mavsdk-tests-improvements
opened 05:15PM - 04 Mar 20 UTC
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:
@TSC21 porting avoidance to ROS2
@jkflying
@Jaeyoung-Lim MacOS homebrew has conflicting dependencies and is currently broken. There will be a fix soon.
PX4 v1.11 Release Notes
Beta flight-testing.
opened 05:35PM - 16 Mar 20 UTC
closed 05:50PM - 07 Sep 20 UTC
# v1.11 Release Notes
Following the significant stability improvements on v1.… 10.0, the PX4 team is preparing for a new release, which will see lots of quality of life improvements, as well as internal robustness in the system architecture to allow for more straightforward board configuration.
# Release Notes
## Highlights
* Major sensor calibration improvements ([Gyro](https://github.com/PX4/Firmware/pull/13632), [Mag](https://github.com/PX4/Firmware/pull/13623), [Level](https://github.com/PX4/Firmware/pull/13666))
## Main Features and Improvements
### Migration Guide
* **DEPRECATED:** VTOL is no longer supported in FMUv2 hardware
### Hardware Support
* [Holybro Durandal](http://docs.px4.io/master/en/flight_controller/durandal.html), (Manufacturer Supported)
* [NXP IMX-RT, S32K](https://nxp.gitbook.io/ucans32k146/), (Manufacturer Supported)
* [Holybro PIX32V5](http://docs.px4.io/master/en/flight_controller/holybro_pix32_v5.html), (Manufacturer Supported)
* [Cube Yellow](http://docs.px4.io/master/en/flight_controller/cubepilot_cube_yellow.html), (Manufacturer Supported)
* [Cube Orange](http://docs.px4.io/master/en/flight_controller/cubepilot_cube_orange.html), (Manufacturer Supported)
* [CUAV X7](http://doc.cuav.net/flight-controller/x7/en/), (Manufacturer Supported)
* [CUAV X7 Pro](http://doc.cuav.net/flight-controller/x7/en/x7-pro.html), (Manufacturer Supported)
* [CUAV Nora](http://doc.cuav.net/flight-controller/x7/en/nora.html), (PR #15536) (Manufacturer Supported)
### Drivers
* Enable SPI DMA adds centralized DMA map (PR #14207)
* Move primary IMU to new InvenSense driver (PR #14356)
* FMUv5, FMUv5x
* ModalAI_fv-v1
* Drivers CLI interface consolidation (PR #14386 )
### System Architecture
* Board config simplifications for SPI & I2C (PR #14221) and PWM timers (#13871)
* Adds UAVCAN node `cannode` (PR #14148)
* Adds CAN interface runtime (PR #14367)
### Multicopter
* New hover thrust estimator (PR #13981)
* XYZ-synchronized motion in auto modes (diagonal climb) (PR #13596)
* New Notch filter (PR #13549)
* Acceleration feedforward (PR #14212)
* Mag power compensation (PR #14457, [Docs](https://docs.px4.io/master/en/advanced_config/compass_power_compensation.html))
* Takeoff failure detection (PR #14428, [Docs](https://docs.px4.io/master/en/config/safety.html#failure_detector))
* Horizontal velocity limit close to ground (PR #13561, [Parameter](https://dev.px4.io/master/en/advanced/parameter_reference.html#MPC_LAND_VEL_XY))
### VTOL
* Tiltrotor: Use tilt to accelerate the vehicle forward while in hover (PR #13779)
* Weather vane improvements (PR #13782)
* Active path and deceleration tracking during transitions (PR #14405)
### Fixed Wing
* Improved airspeed failure detection (PR #12353)
* Enables fallback estimation without airspeed sensor. (PR #12887)
### Rover
* Major improvements to offboard control
* Enable offboard attitude setpoints (PR #13323)
* Enable offboard velocity setpoints (PR #13225)
* Enable ActuatorControl setpoints in offboard mode (PR #13314)
### Underwater Vehicles
* New mixers for underwater vehicles Generic & HippoCampus (PR #14079)
* New UUV default specific parameters and autostarting (PR #14079)
* New Mixer for UUVs with X-shaped thruster configuration (PR #14079)
* New `uvv_att_control` controller for UUV attitude control (PR #14079)
### PX4/ECL - Estimators improvement
* Emergency Yaw recovery using EKF-GSF estimator (PR PX4/ecl#766)
* Pre-flight accel bias estimation stability fixes (PR PX4/ecl#818)
### Onboard computer / middleware improvements
* Adds ROS 2 Dashing and Eloquent support to the microRTPS bridge (PR #13907)
* Adds ROS 2 Foxy support to the microRTPS bridge (PR #15227}
* Adds time sync to the microRTPS bridge (PR #14297)
* UART link data stream fixed in the microRTPS bridge (PR #15354)
### PX4/Avoidance
* Smoother flight planning with improved repeatability (PR PX4/Avoidance#555)
* Bezier trajectory avoidance interface (PR #14279)
* Bugfixes and improvements
### Simulation
* Multi-Vehicle simulation with Gazebo
* Adds support for multiple distance sensor instances. (PR #14143)
* Adds support for UUV vehicles. (PR #14079)
* Adds support for boats. (PR PX4/sitl_gazebo#409 )
* Adds Catapult and Hand launch support for fixed-wing. (PR PX4/sitl_gazebo#393 )
### Failsafe / Commander / Navigation improvements
* New Hover Thrust estimator (PR #13981)
* Commander, Navigator state clean-up (PR #14307)
* Navigator fixes heading drift after takeoff (PR #13965)
* Enable RC-Override in Take-off (PR #14022)
* Takeoff failure detection (PR #14428)
* Pre-flight check: Disable mag field strength check via parameter (COM_ARM_MAG_STR) (PR #13766)
### OS/NuttX
The release includes a change from [NuttX-7.29 ](https://bitbucket.org/nuttx/nuttx/src/101f3bddecb70cfb8dc78c5b4fad98f3480ae399/ReleaseNotes#lines-21789) to [NuttX-8.2](https://bitbucket.org/nuttx/nuttx/src/efff9b9438e69ea6c70e879b7ee4d49bff1b0988/ReleaseNotes#lines-25651)
See [NuttX release notes](https://bitbucket.org/nuttx/nuttx/src/efff9b9438e69ea6c70e879b7ee4d49bff1b0988/ReleaseNotes#lines-25651) for the details of changes in NuttX-8.2 details.
Included as backports are:
* STM32[F4 F7 H7]
* spi_exchange (no DMA) with for STM32xx_SPI_DMATHRESHOLD
* STM32[F7 H7]
* SDMMC internal pull up usage fixed
* Add check_format tooling
* nxstyle - output compiler like error format
* STM32H7
* fix stm32h7x3xx_dmamux.h: add missing underscore to defines
* STM32F7
* stm32f7:Add Serial Tx DMA
* stm32f7:ethernet: Add some delays so that ifup() does not
* NXP IMX-RT, S32K
* S32K add support for Nxp drone boards
* imxrt: Adds the ability to run from OCRAM
* imxrt: Add USB Device support for i.MX RT
* imxrt: added missing i2c prescale mask
* imxrt: interrupt serial storm, add DTCM and set up I and
* imxrt: Allow clock setting for SPI and I2C from board.h.
* imxrt:lpi2c Fix interrupt storm on failed write.
* imxrt:lpi2c ensure that on an error status reflects it.
* imxrt:lpi2c imxrt_lpi2c_reset uses GPIO with SION
* imxrt:gpio Support readback on OUT GPIO
* imxrt1020-evk: Enable the GPIO based CD.
* imxrt:lpspi: Fixed race on register setting.
* imxrt:lpspi: Remove hack setting LPSPI1 daisy irrespective
* imxrt:lpi2c.c:Added configurations to fine tune LPI2C Time
* IMXRT106x USDHC: Support regular GPIO for CD and inversion.
* IMXRT106x:pinout add ALT 8 GPIO_GPT2_COMPARE3 & fix GPIO_G
* IMXRT106x:pinout add ALT 8 GPIO_GPT1_CAPTURE[1|2]
* Kinetis renamed TJA1100 to TJA110X registers
## v.1.11.0 Changelog
https://gist.github.com/mrpollo/7173f6c89d2fdacb923eb4481b486e41
Discussions about when to cut a feature freeze. @dagar is concerned about e.g., the CPU load on some older resource-constrained boards. These might require additional driver “features” to improve performance. It’s a fine line between freezing and slipping the release. We should have a low barrier beta announced, but make sure the testers don’t have a horrific experience.
The hover thrust estimator could be enabled by default in the beta, and in case we still find any significant issues, we could always disable it for the release.
PX4:master ← PX4:pr-enable-hte
opened 05:16PM - 18 Mar 20 UTC
Following the decision taken during today's DevCall, we're going to enable the h… over thrust estimator by default for the beta to see if there are any issues. We can still disable just before the release if we see that something is really broken and that we can't fix it immediately.
FYI: @mrpollo
@JulianOes
Idea making C++ standard library available on the MCU might also help for UAVCAN 1.0. But that’s a big task. The proposition to get existing unit tests that are now SITL test over to gtest. What’s necessary on the MCU is a HITL style integration test with realistic timing and all drivers still running in the background with constant monitoring of all the resources during flight.
@dagar How do we handle the optional configuration of FMUv2 without VTOL? (from above)@LorenzMeier seems to have some ideas to do that.
coder_kalyan:
Difference between Main and AUX output, he wants to have his Octocopter running with DSHOT?
Is there support for brushed motor output to control a non-BLDC motor? @dagar offered pointers offline
The idea about redundant RC values via duplicate MAVLink. We have to be careful about link differences e.g., latency. It might require a high complexity, and that could induce more failure cases than what we have right now.
In mission mode or autonomous landing, there’s ALT1 and ALT2 to slow down the landing. Questions about how it works and how to configure not to land too slow or too fast. @MaEtUgR offered offline suggestions.
by @rroche
Survey about postponing, canceling for this year?
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.
about the redundant link issue that was talked on call.https://mavlink.io/en/guide/message_signing.html
1 Like
rroche
March 23, 2020, 6:29pm
3
Thanks to everyone who sent their notes and contributed to the call this week.
The weather condition is still not suitable for flight; it looks like it will be raining all week. There were multiple indoor tests conducted.
PR #14168 contains a bug, and that’s why it didn’t arm in testing.
F4 and F7 DMA changes were upstreamed to NuttX and are pending testing.
UAVCAN SocketCAN driver was updated in NuttX, and we can start testing that It’s still sending 0.9 UAVCAN messages above the transport layer.
UAVCAN Sensor drivers PR
Big driver refactors for better reusability and scalability.
Significant improvements in the preflight checks user experience.
There are a lot of smaller cleanups going on.
Further discussion needed on how to handle the optional configuration of FMUv2 without VTOL
@sfuhrer working on bringing the fixed-wing position controller into the local frame
Fixed-wing is still not supported by MAVSDK.
Only outdoor testing open PR 14326
Hover thrust estimator testable by parameter PR 14378
We should have this for the release, still pending a fix of the integrator problem PR #14212
Improved testing ready to be merged, running in CI, giving better feedback
Next step: extend to automated real-world testing
@TSC21 porting avoidance to ROS2
New MAVROS support for the bezier interface that was later added to the flight control. @jkflying