Status update by component
Release v1.10
Time for another beta? should we cut an RC?
Join the discussion on the Pixhawk Hardware Standards Call
Currently discussing
Payload Standardization
BMS Standardization (Smart Battery)
Many other topics, including FMUv* and UAVCAN devices.
Introducing the Volunteer Team
Inbound Messages, Flight Testing Support, Assist Component Owners
Open section for the community (Please add your agenda items)
Anyone can propose topics for discussion
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
Small usability fix to the parameters list. Booleans are now documented and you can see the default state. See ATT_ACC_COMP .
Bad weather remains in TJ, fires and very strong winds, unsafe for the team to out to the field some days last week, and this week as well.
Weekly Report
PX4 development testing done by the Dronecode Test Team
Total Flights: 25
PR’s (Assigned / Tested) 2
ekf2_main - Add optical flow innovation pre-flight check #13036
Airspeed selector follow-up #12887
Issues reported: 0
Vehicle Status:
[image]
@dagar
PX4:master ← PX4:pr-icm20602_fmu-v4
opened 07:30PM - 06 Oct 19 UTC
This is a new driver for the Invensense ICM20602 that uses the sensor's FIFO and… SPI DMA (on px4_fmu-v4) to transfer raw gyro data at 8 kHz and accel at 4 kHz. It can also do gyro at 32 kHz, but at that point the bus utilization is a bit too high to peacefully coexist with other sensors.
The intent is to keep these opinionated drivers simple and optimized to the point where it'll likely be easier to carry separate drivers for each sensor with minor differences rather than trying to support everything in one place (see current mpu6000 mess). We'll see how this actually pans out for the ICM20608, ICM20689, etc.
Originally I was going to do a pass and enable SPI DMA everywhere first (https://github.com/PX4/Firmware/pull/12436), but given various problems and delays in that area I think we can move forward incrementally like this.
Features
- 8 kHz gyro (32 kHz possible)
- 4 kHz accel
- FIFO emptied at 1 kHz (we can consider doing this faster or slower as appropriate)
- clip counters
- new low pass filter that operates on an array of data (LowPassFilter2pArray)
- new sensor messages for better visibility
- sensor_{accel, gyro}_fifo: full raw data for optional logging and analysis
- sensor_{accel, gyro}_status: metadata, clipping, etc
- sensor_{accel, gyro}_integrated: delta angles and delta velocities
- eventually these will replace the existing sensor_{accel, gyro} monolith
### Background (notes from @priseborough)
#### IMU Signal Processing
Failure to detect vibration induced inertial navigation failures early enough during system integration or operation has contributed to a number of vehicle loss incidents. In the majority of cases this has been caused by structural resonances excited by motor and propeller blade bassage frequency vibration.
The current practice of using the IMU’s internal DLPF is a major blocker for the following reasons:
1. IMU internal sampling is then limited to 1kHz which makes the ADC step susceptible to aliasing on airframes with high RPM/geared motors and high blade count propellers
2. The use of the IMU’s internal DLPF means that high frequency vibration clipping of the ADC cannot be detected externally until it has affected the INS
3. Data cannot be logged at the ADC sampling frequency so it is not possible to use a data driven approach to resolving vibration induced navigation failures.
Experience working with companies using PX4 has shown that the majority do not understand how propulsion system forcing, structural dynamics, IMU sampling and vibration isolation mount design interact to affect navigation system performance and for those that do, the inability to log the required data prevents the use of normal analytical methods.
The signal chain for autopilot feedback and navigation needs to be split for the following reasons:
1. Logging of raw unfiltered data from the sensors ADC is required if an analytical approach to resolving vibration induced navigation failures is to be adopted.
2. Angular rate control feedback requires data with minimum phase low/group delay with a maximum acceptable level of high frequency content that is application specific.
3. The best general purpose filter in terms of high frequency noise rejection for a given phase delay measured at the rate controller gain cross-over frequency of 5-15Hz is an IIR second order bi-quad filter with a Q of 1/sqrt(2).
4. The angular rate controller should be synchronised to the imu to reduce inter-sampling delay.
5. The angular rate controller should run at a higher rate than the attitude and position/height controllers and therefore needs to run at a faster rate than the INS/EKF.
6. The angular rate controller may be required to run at 1kHz or higher for some applications.
7. The INS/EKF uses delta angles and delta velocities that are obtained by integrating high rate gyro and accel measurements in body frame across the INS/EKF update interval.
8. The INS/EKF is very sensitive to errors caused by clipping and aliasing.
9. Correction for coning errors introduced when downsampling needs to applied as part of the downsampling integration algorithm.
10. It is unlikely that INS data would be required faster than 250Hz.
NuttX/nuttx with SDIO fixes
PX4:master ← PX4:master_SDIO_hang_fix
opened 07:35PM - 29 Oct 19 UTC
This PR addressees hangs when the SD card is removed while writing.
Fixes PX4… /Firmware#12071 (comment)
Fixes PX4/Firmware#13087 (comment)
@PX4/testflights - Please test on FMUv4 and FMUv5
MAVLink update from bi-weekly meeting
Meeting minutes for MAVLink call
@mcsauder looking into issue #13316
opened 01:50PM - 30 Oct 19 UTC
closed 12:17AM - 07 Nov 19 UTC
**Describe the bug**
The online documentation for using the benewake tfmini ran… gefinder states that it should work on GPS2, however, after setting everything up, it doesn't work.
**To Reproduce**
Steps to reproduce the behavior:
1. Turn on Pixhawk2.1 Cube with fresh parameters
2. Choose Airframe Quadcopter x: Generic Quadcopter and reboot
3. Go to parameters and set 'SENS_TFMINI_CFG' to 'GPS 2', make sure benewake tfmini is connected to GPS 2 and reboot
4. Go to MAVLink Inspector and look for Distance Sensor
**Expected behavior**
The distance sensor message data should appear, however, no distance sensor message data appears
**Log Files and Screenshots**
Attached
@dagar Added ICM20602
PX4:master ← PX4:pr-icm20602_fmu-v4
opened 07:30PM - 06 Oct 19 UTC
This is a new driver for the Invensense ICM20602 that uses the sensor's FIFO and… SPI DMA (on px4_fmu-v4) to transfer raw gyro data at 8 kHz and accel at 4 kHz. It can also do gyro at 32 kHz, but at that point the bus utilization is a bit too high to peacefully coexist with other sensors.
The intent is to keep these opinionated drivers simple and optimized to the point where it'll likely be easier to carry separate drivers for each sensor with minor differences rather than trying to support everything in one place (see current mpu6000 mess). We'll see how this actually pans out for the ICM20608, ICM20689, etc.
Originally I was going to do a pass and enable SPI DMA everywhere first (https://github.com/PX4/Firmware/pull/12436), but given various problems and delays in that area I think we can move forward incrementally like this.
Features
- 8 kHz gyro (32 kHz possible)
- 4 kHz accel
- FIFO emptied at 1 kHz (we can consider doing this faster or slower as appropriate)
- clip counters
- new low pass filter that operates on an array of data (LowPassFilter2pArray)
- new sensor messages for better visibility
- sensor_{accel, gyro}_fifo: full raw data for optional logging and analysis
- sensor_{accel, gyro}_status: metadata, clipping, etc
- sensor_{accel, gyro}_integrated: delta angles and delta velocities
- eventually these will replace the existing sensor_{accel, gyro} monolith
### Background (notes from @priseborough)
#### IMU Signal Processing
Failure to detect vibration induced inertial navigation failures early enough during system integration or operation has contributed to a number of vehicle loss incidents. In the majority of cases this has been caused by structural resonances excited by motor and propeller blade bassage frequency vibration.
The current practice of using the IMU’s internal DLPF is a major blocker for the following reasons:
1. IMU internal sampling is then limited to 1kHz which makes the ADC step susceptible to aliasing on airframes with high RPM/geared motors and high blade count propellers
2. The use of the IMU’s internal DLPF means that high frequency vibration clipping of the ADC cannot be detected externally until it has affected the INS
3. Data cannot be logged at the ADC sampling frequency so it is not possible to use a data driven approach to resolving vibration induced navigation failures.
Experience working with companies using PX4 has shown that the majority do not understand how propulsion system forcing, structural dynamics, IMU sampling and vibration isolation mount design interact to affect navigation system performance and for those that do, the inability to log the required data prevents the use of normal analytical methods.
The signal chain for autopilot feedback and navigation needs to be split for the following reasons:
1. Logging of raw unfiltered data from the sensors ADC is required if an analytical approach to resolving vibration induced navigation failures is to be adopted.
2. Angular rate control feedback requires data with minimum phase low/group delay with a maximum acceptable level of high frequency content that is application specific.
3. The best general purpose filter in terms of high frequency noise rejection for a given phase delay measured at the rate controller gain cross-over frequency of 5-15Hz is an IIR second order bi-quad filter with a Q of 1/sqrt(2).
4. The angular rate controller should be synchronised to the imu to reduce inter-sampling delay.
5. The angular rate controller should run at a higher rate than the attitude and position/height controllers and therefore needs to run at a faster rate than the INS/EKF.
6. The angular rate controller may be required to run at 1kHz or higher for some applications.
7. The INS/EKF uses delta angles and delta velocities that are obtained by integrating high rate gyro and accel measurements in body frame across the INS/EKF update interval.
8. The INS/EKF is very sensitive to errors caused by clipping and aliasing.
9. Correction for coning errors introduced when downsampling needs to applied as part of the downsampling integration algorithm.
10. It is unlikely that INS data would be required faster than 250Hz.
@JulianOes A corner was discovered in the failsafe state machine
Action : Send PR to release branch (once we figure out what’s going on)
https://github.com/PX4/Firmware/pull/13294
@sfuhrer This week we are flight testing the airspeed sensor PR.
Action : More testing by @sfuhrer
https://github.com/PX4/Firmware/pull/12887
@igalloway NXP is working with FliteTest to produce a low-cost VTOL with PX4
@sfuhrer
Refactoring in master
Track down the PRs and issues
@TSC21 Currently working on the CI for px4_ros_com in order to add tests to the microRTPS bridge functionality
@jkflying fixes went into master
PX4:master ← PX4:async-transforms
opened 03:46PM - 25 Oct 19 UTC
This reworks the condition variables and mutexes around the point cloud transfor… mation. It should now be a) safer and easier to maintain than before b) lower latency and c) lower CPU usage.
It gets rid of the poll for when new transforms arrive in the transform buffer, uses a single mutex for the each camera's point cloud instead of 2, and gets rid of all (I think) non-threadsafe access to the `camera_` vector.
Tested in SITL, needs testing on a real vehicle.
PX4:master ← PX4:offtrack-smooth
opened 05:11PM - 30 Oct 19 UTC
**Describe problem solved by this pull request**
Before, if a vehicle was pulle… d very off-track (eg. by the obstacle avoidance system) the smooth dynamics planning would plan wrong routes, assuming it was still on-track
In addition, there were some cases where code calculating the optimal speed to go through a waypoint had very complicated / hard to follow logic, which was potentially also a source of problems.
**Describe your solution**
This fixes the angle that is used for the planning, so it uses the angle from the drone instead of from the previous waypoint as the entry angle into the next waypoint acceptance radius.
It also simplifies the logic by adding the capability to 'chain' the constraints from later setpoints' velocities, so that we don't have to override the smoothing to move nicely through waypoints that we don't need to turn for.
Also, I got rid of the MPC_XY_TRAJ_P for the straight line stuff, since it wasn't doing anything in my tests - it is still being used for the acceptance radius calculation. Maybe I'm wrong on this and we should add it back in.
**Describe possible alternatives**
I used a single speed term instead of separate x/y components, but I didn't see an easy way to do separate x/y without rewriting the whole thing. Not sure if this is an issue, but it is also way simpler this way.
**Test data / coverage**
I've flown this in SITL a fair amount.
Current master doesn't fix the tracking on the line after an overshoot. What isn't visible here is that _the vehicle actually flew sideways_, with yaw pointing towards the setpoint but continuing parallel to the flight line.
https://logs.px4.io/plot_app?log=020c2e97-f6db-4b94-a7d3-059876cb0011
This PR tracks the overshoot, correcting it much better, and always flying with yaw straight ahead.
https://logs.px4.io/plot_app?log=0abcbfa8-ffc5-4664-86b1-b8d665f38497
Both the above flown with Iris, without Avoidance running
**Additional context**
IMO this should be pulled into 1.10, it is a pretty serious fix for Avoidance which pushes the vehicle offtrack as part of normal operation. FYI @dagar @julianoes
Battery fixes and Nuttx fixesAction : make sure those are in the release branchAction : cut a beta5 once those fixes are in
make sure we check on this issue before release
opened 06:43PM - 09 Oct 19 UTC
closed 09:30PM - 09 Jan 20 UTC
bug
Drivers 🔧
**Describe the bug**
Cannot fly my holybro s500 kit with `master`. It works fin… e on `v1.9.2`. I've also tracked this on px4 discuss [here](https://discuss.px4.io/t/holybro-esc-issue-on-master/12618/3).
**To Reproduce**
Using this holybro s500 kit: https://shop.holybro.com/_p1153.html
**Expected behavior**
There should be no ESC issues between PX4 firmware versions. There is funny business happening on the actuator outputs during boot.
Below are screenshots of a scope on motor output 1 during first 1 second of boot.
**Log Files and Screenshots**
`v1.9.2`
`master`
As you can see in the images above, `v1.9.2` has 5 pulses of 900us width spaced at 20ms before the 400hz 900us outputs actually kick on. I am not sure if this is related, but it was the only thing I found.
**Additional context**
This has been broken for a while now, I'd really like to be able to fly `master`...
@mcsauder & @dakejahl when we went from 1.9.2 to master we burned two motors (400Hz PWM)
Action : @david_s5 sending a PR that enables two-wire ethernet on the K66
Question : @igalloway I have a general question at some point - relating to localization and how this should integrate with GPS positioning. How to transition from one to another localization system.Answer : @jkflying Estimate offset between one and another, so you can get a smooth handover. You need both overlapping at some point.
Work Group invitations, BMS & Payload
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.
Same airspeed PR as VTOL with testing by @sfuhrer