Last call FMUv6 was discussed. The design is close to be released. Some documents are still being checked. Standard will be announced. Gumstix will make a prototype board.
System Architecture
Logger changes about the default logger profile. Potentially remove the replay logging from default profile to make sure we can use cheap SD cards for longer.
@JingerZ The board Yellow and Orange are not listed as supported currently. They should be listed as experimental/community supported. There will be a follow up discussion with @dagar
Commander
No updates
Estimation
Progress on Python EKF derivation:
Master of Firmware is out of date with ecl. New geo table doesnāt fit FMUv2. We might want to compensate the flash size increase with the auto code generation (Python derivation) savings.
What path should we go update everything at the same time or small pieces and save flash with other means in between.
Goal: Have a validity flag. Additionally @dagar found a bug with the delta-time.
Testflights needed after check of @MaEtUgR comments. No major change anticipated.
Avoidance
No updates
Simulation
@JulianOes CI: we changed gazebo to be able to load different models. There was a race condition where gzserver was not yet present when trying to load the model and then there was no model and the tests failed.
Main difference how user callbacks get called. Before there was a thread pool for the callbacks that caused potential threading issues. Now the callbacks are called from one thread and you have to do short callbacks and/or start new threads yourself if you call other blocking code.
Thereās a new feature and tutorial to be able to use a joystick.
MAVSDK on ARM improvements
Failure injection.
Bug fixes, see notes
MAVROS / DDS / ROS2
Testing of the serial link with ROS2 using a Pixhawk 4 and seeing good throughput with parallel topics.
What happened with Serial TX DMA in NuttX? There are issues like the GPS ones we had before. Thatās what @david_s5 meant we need to look into it before updating NuttX.
UAVCAN
PX4 UAVCANv1 work ongoing, no particular updates at the moment.
Release
For the 1.11 release we have the land detector issue that is pending. Itās now reviewed and needs final testing.
We should revive the tester GitHub group and add community volunteers such that they easily get notified when tests are needed.
Would be good to have @hamishwillee and/or @bkueng in the call for further discussion. @dagar motivates to think about trying to not miss out on any opportunities to rule exclude e.g. value ranges. Check MAVLink FTP performance, itās probably not performing as well as it could/should.
QGC uses a different protocol than MAVLink FTP to download logs. We need a mechanism to slow everything else down while transmitting the file and then switch back to normal operation.
UAVCAN rangefinder support
@dagar everything seemed fine except for they add their own custom DSDL which we should not carry that in PX4. We should forward the information into parameters.
@JingerZ FMUv5x Holybro is making a new prototype. Does @dagar and @david_s5 want one? @david_s5 has the old prototype and we need to communicate the required changes for the updated specs clearly.
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.
The protocol is designed to fetch data from the vehicle that is invariant after boot - parameter metadata, version info, supported mission items etc.
It could also be used to get all actual parameters on boot (instead of existing param protocol) and then monitor for changes on individual params. This would be more efficient than what we do now.
It is tempting to say well why donāt we allow requesting this dynamically at any time, and further that we then take a particular split that weāre interested in. This is do-able but Iād prefer we looked at a new API for that.
We are currently thinking about requesting the values of all parameters after boot using the component_info approach. This might be more efficient than getting them using the normal PARAM_REQUEST_LIST approach. This is in line with the protocol.
You may recall Tridge talking about a maybe having a new param protocol where params could be more efficiently packed and requested in big chunks. I think the suggestion is that we allow something similar in the COMPONENT_INFO message - ie you be able to request smaller chunks than āall paramsā. What I am saying is that I do not think this aligns with our thinking around the protocol.
Nor do I think it necessary because once you have uploaded most params in a file, keeping track of individual changes is easy enough and you no longer have the big inefficiency of the current protocol.
Ardupilot probably agree - since they now have a model where they upload params in a file on boot just as we are planning.
What we could do is provide a mechanism to request that the information be dynamically regenerated. That makes sense for parameters and would not be outside of our current thinking.
I get all that part and agree. I specifically donāt get this: āIt is tempting to say well why donāt we allow requesting this dynamically at any time, and further that we then take a particular split that weāre interested in. This is do-able but Iād prefer we looked at a new API for that.ā
