April 22, 2020
- Status update by component/project
- Roadmap, and Release discussion
- Community Q&A
- In-Depth discussions
Meeting ID: 946 175 205
Join using your mobile/desktop
Call in using your phone, find your local number: https://zoom.us/u/aetSYKbiMF
We are looking for new testing partners:
Going forward the developers need to assemble flight cards of what’s supported such that it’s not less multicopter manual flight only testing and includes more real world use case testing of supported features and failsafes.
OS / NuttX
NuttX changes came in for ST32K UAVCAN board. They are separate from currently supported boards.
NuttX is working on getting a 9.1 release out. We’ll probably bringing that into the next PX4 release.
There was a serial DMA issue reported on Firmware which is probably a NuttX problem.
There was a recent change to enable serial DMA on all boards not just fmu-v5 and telem2 which it was limited to before.
SD card still has issues on H7.
@dagar went through the CUAV Nora and X7 boards and added a new driver for the Invensese sensor we weren’t using before
The driver works and is in but there’s problems with SPI DMA on SPI6 of H7 doesn’t work as expected.
Also new ICM2948 driver for mRo Zero not finished yet, maybe needs to be in for the release.
There’s issues on the CUAV V5+ with the second IMU running at the same time as the primary one over a longer period of time. We likely need to hotfix this for the release and disable the secondary one.
If you were flying with GPS as primary hight source or with range aid and you lost that source then the offsets were not handled the correct way in all places which could result in an altitude jump.
Update period change from 8ms to 10ms to solve the covariance numerical issues resulting in the biases destabilizing the estimator after hours of standing on the table. The IMU updates were changed to align with EKF updates in the new intervals.
The option to have an autoland spiraling down is not a bad idea but it’s not the best configuration for all setups.
High wind landing issue because of tilt limit.
@MaEtUgR’s concern for the release he plans to solve.
The hover thrust estimator could generate problems when flying in stabilized and switching to altitude or position-controlled modes. This has been fixed.
Local position reset could lead to a race condition where the mode switches at the same time as the reset happens and the processing of the reset counter change got overwritten.
@JulianOes Continued work on the autogenerated MAVSDK plugins also in C++:
First plugins and templates were the hardest and took most time. Now that ground work is done it gets faster and faster. This will enable to get rid of support differences in the different languages.
MAVROS / RTPS / ROS2
@TSC21 Is continuing work on porting Avoidance to ROS2. Raising awarness for the #ros channel on slack because there’s interesting work and discussion being discussed there. For example direct motor control over FastRTPS.
The Avoidance release needs to be synchronized with PX4 such that it’s obvious what is compatible.
What happened with the FlightGear integration? It should be ready but changes get added so @Jaeyoung-Lim asked if it could be stabilized and squashed such that we can have a minimal working version merged. Last test it didn’t work with the default FlightGear simulation distribution shipped with Ubuntu. Will enable traditional helicopter in PX4 simulation.
Roadmap, and Release discussion
The testing and reports we get from various people is extremely valuable. Anyone who can help with that it is a big help!
Remaining known issues that need to be fixed for the release: https://github.com/PX4/Firmware/projects/17
- Novel IMU and magnetometer calibration algorithm proposed by Saxion University Netherlands
Looking for integration in PX4 with the goal to have an easier more accurate calibration.
Benefits of the algorithm: use all sensors at the same time, random motion, estimate more parameters e.g. rotation and distance between sensors
Contact: Gerjen ter Maat (PX4 slack)
Comments: Start on your fork, share code and questions on the #dev-team channel on slack. It makes sense to first check if the algorithm can run of logged sensor data and it would be vastly helpfull to replay it with logged data later on as well. The suggested approach is creating a standalone module and subscribing to all the data the algorithm needs, publishing results for logging or print output and see how it works and if available microcontroller resources are a problem. When that’s doen we can work together on the plumbing to fit it into the existing infrastructure.
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.