September 23, 2020
Agenda
- Status update by component/project
- Roadmap, and Release discussion
- Community Q&A
- In-Depth discussions
Join Meeting
Meeting ID: 946 175 205
Join using your mobile/desktop
Call in using your phone, find your local number: https://zoom.us/u/aetSYKbiMF
Component update
Hardware Workgroups
Summary:
- discussed v5x and v6x schematics further
- demo of fmuv6 by Gummstix, will be an open-source design
System Architecture
Giving up on the idea to have different PX4 rotation than what’s available in MAVLink. There’s static asserts now to have it in sync. It also captures new rotations on each side because of the maximum number changes. Custom rotations are the next desired step.
Possibility to have a custom rotation per sensor instead of a fixed enum. We need to think about how to deal with board startup script capturing internal sensor rotations.
Bumping the maximum number of uORB topic instances up to 10 which will help with the multi-EKF, multi-battery setups.
Publication with queue size > 1 it will overflow depending on the publish rate and total runtime. Contribution to avoid losing samples when running for months.
Startup script potential problems depending on the environment. @dagar intended to do a ROMFS cleanup where the calls from one script to another would decrease but not go to zero. The absolute path could be passed in as a variable through the top-level script. We don’t need to assume on POSIX to have everything at the root path. Input: it’s probably because Arch and Cygwin use bash as symbolic link from sh.
OS / NuttX
NuttX update merged
There’s known issues:
- Bootloader update problems
- Hardfault reported on NXP FMU K66
- Something with navigation and control work queues seems to be corrupted, visible with
ps
Minor F412 fixes come in from upstrem NuttX for e.g. CUAV GPS cannode board:
@david_s5 Saw NuttX discussion about Cygwin toolchain being broken so we might be able to bring it in and profit.
There is a possible way to dynamically configure ethernet. @david_s5 will upstream it and we’ll have that available.
Today the next NuttX release 10.0 was announced to happen in about a month.
Driver
LPS33 barometer driver should run even if it’s not able to detect the sensor immediately. At least the option to have the driver not exit when the sensor is not immediately detected is desired for all drivers in the future. Otherwise sensors that are supposed to be there can go missing silently.
There’s a magnetometer that will be obsoleted. Holybro will change to the next generation sensor on existing boards. How do we handle the detection of that? We encourage a way to make a new board and be able to detect the hardware/board version because clients expect to have the same thing if they buy the “old”/same board. We can support the sensors if they change it anyways. mRo stopped producing certain board because certain sensors reached end of life. We need to follow up in the thread Holybro asked.
Commander
Preflight check improvement, don’t ignore timeouts in the checks. Treat content of checks and data timeouts separately and have them both fail. We need to completely avoid slipping through and ignoring that data is missing.
Estimation
Paul added monitoring the EKF instances and gyro and accel biases. It was tested in SITL. We need real-world tests on different boards and vehicles and especially go through the cases where resets are not handled in controllers and setpoint generation to make sure we don’t run into glitches or crashes upon switching to a different IMU multiple times. So far we don’t have enough testing on non-primary IMUs. Might be that multiple of one sensor type is better than all different ones.
In cases where mag interference is only present while flying e.g. mostly constant current close to the sensor, it’s useful for the EKF to learn and save them. Right now it requires 2 minutes of flying in circles until the learned biases are considered worthy to be saved and this pr tries to change the strategy for the acceptance.
Lookup declination before full GPS checks pass since a rough position is enough.
Related to that there are cases where people take off without home position because GPS is not accurate enough even though it would be better to have a home position that’s less accurate than not having one quickly at all. @MaEtUgR will create an issue. We need to untangle GPS validity and home position validity conditions. EDIT: https://github.com/PX4/Firmware/issues/15805
VTOL
No update
Fixed Wing
TECS discussion about altitude coming in from navigator versus the position controller (/TECS) doing the right thing.
Multicopter
Regression needs to be addressed further:
Avoidance
No update
Simulation
When switching to Jinja MAVSDK tests fail. Because the test runner doesn’t find certain things. Should we adjust the test runner to not look for a hardcoded path? Would it be an option to have the generated models in the build folder? We’d need to move all the models over. We could do that just like with NuttX.
Regarding multi-EKF are there any necessary actions? Faking multiple IMUs with different latency and noise might be worth to discuss. How would it work with lockstep? Would having lockstep always on ID 0 help? There needs to be more discussion. We should split make targets from running SITL with different options.
Benjamin Perseghetti: How about we run the simulation and it starts a PX4 SITL instance instead of the opposite like how it’s done now? That would be a welcome improvement. We should try to not have everything in Firmware build scripts. It should still be simple but could be a bit more complicated if it then was more obvious what’s happening.
Community Q&A
Benjamin Perseghetti: Possibility to use secure boot on Gumstix board?
There will be an extra call with Ben, @dagar, @david_s5 today. Everyone interested please contact them on slack to take part.
Errata and Feedback
Let me know below if we failed to capture anything the right way, and if there are any updates (not present here), or you have feedback you would like to share with the dev-team.