Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Meeting ID : 946 175 205Join using your mobile/desktop
Call in using your phone, find your local number : https://zoom.us/u/aetSYKbiMF
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.
https://github.com/PX4/Firmware/pull/14168
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.
#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 #14382
…
https://github.com/PX4/Firmware/pull/14345
master ← 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.
https://github.com/PX4/Firmware/pull/14322
https://github.com/PX4/Firmware/pull/14301
@sfuhrer working on bringing the fixed-wing position controller into the local frame
https://github.com/PX4/Firmware/pull/14298
@Jaeyoung-Lim has catapult launch working in simulation, but it’s not part of CI yet.
PR 14326 PR 14378 PR #14212
master ← 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.
master ← 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:
:
https://github.com/PX4/Firmware/pull/14212
https://github.com/PX4/Firmware/pull/14296
@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.
https://github.com/PX4/Firmware/issues/14402
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.
master ← 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.
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