rroche
February 26, 2020, 6:09pm
1
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
Quick statement about feedback on the dev-call
Status update by component
Development focus
Open section for the community (Please add your agenda items)
Anyone can propose topics for discussion
PX4 development testing done by the Dronecode Test Team
Total Flights: 72
PR’s (Assigned / Tested): 1
MC rate controller: do not disable integrators at min/max throttle #11560
Issues reported: 1
Pixhawk 4 and Pikhawk 4mini v5 not disarming. #11569
Vehicle Status:
[image]
Backports from @dagar and @david_s5
PX4:px4_firmware_nuttx-8.2 ← PX4:px4_firmware_nuttx-8.2_ocram_usbdev_pb
opened 12:56PM - 02 Mar 20 UTC
PX4:px4_firmware_nuttx-8.2 ← PX4:pr-stm32_spi_dma_threshold
opened 11:43PM - 02 Mar 20 UTC
Backport of https://github.com/apache/incubator-nuttx/pull/420.
@david_s5 Planning to improve DMA for SPI.
@bresch (3% perf gain on F7)There was a fix for GPS blending
TODO : Figure out testing for regressions
PX4:master ← PX4:pr-fix-hgt-fusion
opened 09:46AM - 04 Mar 20 UTC
Summary:
- reduce CPU load: https://github.com/PX4/ecl/pull/767 (fixes https://… github.com/PX4/Firmware/issues/14204)
- fix earth rate gyro compensation
- make test with clang
- use switch statements in controlHeightFusion
Diff:
https://github.com/PX4/ecl/compare/3fa5f501ae7edc4a793f0973e156706afcc8b419..230c865fa9c02b07b0371df050b339bc37ce0c29
PX4:master ← CarlOlsson:pr-fix_gps_blending
opened 03:21PM - 02 Mar 20 UTC
Solves
https://github.com/PX4/Firmware/issues/14223
https://github.com/PX4/Fir… mware/issues/14232
https://github.com/PX4/Firmware/issues/14276
https://github.com/PX4/Firmware/issues/14251
TODO: Find reviewer for this PR
PX4:master ← PX4:pr-tiltrotor-comments
opened 12:49PM - 27 Feb 20 UTC
This PR changes some comments and a variable inside tiltrotor.cpp to indicate th… at also the rear motor(s) can be used for actuation in fixed-wing flight .
No logical changes.
PX4:master ← PX4:pr-fw_attitude_control_ecl
opened 10:19PM - 02 Mar 20 UTC
Let's merge this back into PX4/Firmware. A large proportion of the code simply g… oes away if the work is handled in place.
ECL side (required first): https://github.com/PX4/ecl/pull/765
First step is to copy in place as is, then we can incrementally refactor easily with the submodule gone.
@TSC21
PX4:master ← PX4:feature/add_rtps_timesync
opened 05:47PM - 04 Mar 20 UTC
Adds timesync for the microRTPS bridge. The agent is the one responsible to init… iate the time sync hand shake and compute the offset. The client, at this stage, just responds to the msgs. Eventually in the future the timesync being done on the Mavlink module will be generalised to be used also on the microRTPS client, but not need to do it right now.
@jkflying
PX4:master ← PX4:pr-bezier-trajectory-interface
opened 04:13PM - 02 Mar 20 UTC
**Describe problem solved by this pull request**
Currently the avoidance interf… ace only allows specifying single position setpoints. This PR enables sending time-parameterized Bezier messages, allowing smooth flight control from the companion computer while in auto modes.
**Describe your solution**
Several parts:
1. A simple 5-line function to calculate a position given an N-order bezier curve and the current `T` value, templated on the type of number that is used
2. Use of Dual numbers to calculate the velocity (and even acceleration), from the above simple function, without needing complex formulae for each curve size.
3. Parsing of the bezier mavlink message, and translation into uORB
4. Subscribe to the uORB, and if the newly introduced bezier message has a valid duration, use that to determine the current position and velocity indicated by the bezier curve
5. Pass these values on using the existing avoidance setpoint injection
Additionally, in order to save FMUv2 flash space, this PR moves the avoidance to a separate library and excludes it from `CONSTRAINED_FLASH` builds, replacing it with a dummy implementation. Thanks to @julianoes for the pointer with `CONSTRAINED_FLASH` - I think this is sufficient for now, but longer term I'd like to be able to do something like this via the board configuration similar to modules. @dagar any ideas on a good way to make this easy for the future, since I don't think this way scales? I'm sure there are other libraries that we'd like to replace with dummies for constrained flash builds, which can't be easily hoisted out into modules.
**Describe possible alternatives**
It might be better for this to not go through the smooth velocity interface, if it is shown that the companion can provide smooth enough curves, and rather send the data directly to the position controller.
**Test data / coverage**
Extensively unit tested. However there isn't yet a planner which can send the bezier messages, so this hasn't been flight or SITL tested.
FYI @Stifael , since you did some earlier Bezier work.
There will be a release branch and beta on March 9. for testing.
How to call for community testing on the released beta?
We need to go over release notes draft
Beta Testing the Release
Release Timeline
Beta release - March 9th
RC go/no go (live on dev call) - March 18th
Release go/no go - March 30th
https://docs.google.com/document/d/1esQKwDQT6a9dUG_Y8GssKOPMgGXI9jO5y1O5g3eoUQg/edit
@MaEtUgR
Acceleration feed-forward: offboard issue, what do we support?
No clear documentation on what’s supported. ROS CI should work, MAVSDK tests should work, additional testing is nice to have. Discussing with @JulianOes & @Jaeyoung-Lim because they had offboard problems with and without the pr as well.
PX4:master ← PX4:acceleration-control
opened 06:19PM - 22 Feb 20 UTC
**Describe problem solved by this pull request**
More or less last step to fini… sh splitting up and QAing PX4/Firmware#12072. It's based on #245 and introduces processing acceleration setpoints. This enables acceleration feed-forward which the jerk optimized flight tasks by @bresch immediately make use of. It also heavily reduces dependence between collective thrust and vehicle tilt making the demanded tilt less jerky when the altitude control output is changing.
**Describe your solution**
I make the velocity control output acceleration in m/s² which in theory would make the controller tuning more independent of the vehicle's thrust to weight ratio (~hover thrust) but for the initial introduction I introduce a scaling factor using the hover thrust to make the existing gains compatible. To separate the high-frequency altitude control changes from the collective thrust from the demanded tilt I'm switching control strategy to apply horizontal acceleration setpoints assuming hover/gravitational acceleration in the vertical direction effectively directly mapping it to the vehicle's tilt. The vertical acceleration gets projected onto the planned tilt and then executed by setting the collective thrust accordingly. Only in the limit case of more than the maximum thrust tilt gets coupled by being limited using vertical acceleration demand to ensure prioritizing altitude control over horizontal navigation.
**Test data / coverage**
For the basic limit cases, input combinations, failsafe and zero thrust inputs there are unit tests now. I did a lot of SITL testing and multiple outdoor tests with a 250 size, one test on a big multicopter.
**Additional context**
Refactorings that made this change possible: https://github.com/PX4/Firmware/pull/13247, https://github.com/PX4/Firmware/pull/13248, https://github.com/PX4/Firmware/pull/13262, https://github.com/PX4/Firmware/pull/13347, https://github.com/PX4/Firmware/pull/13701, https://github.com/PX4/Firmware/pull/14017
- [x] I still need to change the jerk limits for manual and auto since the tracking is tighter now.
- I discussed with @Jaeyoung-Lim to expose the acceleration on the offboard interface to allow more dynamic flights and a different kind of input that doesn't rely on vehicle internal velocity estimate.
Attitude setpoint generation: what do people expect from yaw/heading in mission and manual position flight?
PX4:main ← PX4:attitude-generation
opened 10:34AM - 20 Nov 19 UTC
**Describe problem solved by this pull request**
Currently, the position contro… ller generates a thrust vector setpoint and forwards the desired yaw heading in the world frame. The setpoint generator then calculates an attitude that aligns the body z axis with the desired thrust (basic multicopter dynamics) and incorporates the world frame yaw heading in a way that the body x axis projected onto the world x-y-plane always point to the desired world yaw heading. This seems like a viable solution depending on the use case of the yaw setpoint but I see one big disadvantage of this solution: **The body yaw rate is coupled with a thrust vector**
**Describe your solution**
I calculate the desired attitude by aligning the body z axis with the thrust vector like before but this time directly using quaternion math. See https://github.com/PX4/Matrix/pull/55 for implementation details. Then yaw is applied on top with a different strategy: If the vehicle is level the yaw is the world frame heading but if the vehicle is tilted it just does the shortest roll/pitch tilting without correcting the body yaw angle to allign the body x-axis in to a world frame projection. This results in no body yaw rate corrections resulting from roll and pitch adjustments.
Note that all the **3-axis** gimbals for drones I have tested do the right thing when generating the attitude the way proposed in this pr and yaw off the desired world frame heading when aplying the current PX4 conversion.
**Test data / coverage**
SITL tested and I adjusted the existing unit tests in the following way:
- structure refactoring https://github.com/PX4/Firmware/pull/13535/commits/4b18af1c9fcb120cd97113bfa38becd60557c9d0
- additional body z-axis direction and thrust magnitude checks https://github.com/PX4/Firmware/commit/4b18af1c9fcb120cd97113bfa38becd60557c9d0#diff-ab7081b2f8b080c822f0c8b98f2cef20R47-R48
- adjustment to the new attitude generation strategy https://github.com/PX4/Firmware/pull/13535/commits/0faf1f8dba5ba562bd68226f08b42e11ac6c8083
@jkflying
How do we architecturally handle Libraries which are part of a module on flash constrained targets? #ifdefs and dummy interfaces?Bezier trajectory avoidance interface by jkflying · Pull Request #14279 · PX4/PX4-Autopilot · GitHub
@JulianOes
@dagar (On vacations) What support is needed?
UAVCAN GPS support
CUAV Nora board
How do we architecturally handle Libraries. follow-up from this week by @jkflying
https://github.com/PX4/Firmware/compare/pr-cuav_gps
PX4:master ← PX4:pr-bezier-trajectory-interface
opened 04:13PM - 02 Mar 20 UTC
**Describe problem solved by this pull request**
Currently the avoidance interf… ace only allows specifying single position setpoints. This PR enables sending time-parameterized Bezier messages, allowing smooth flight control from the companion computer while in auto modes.
**Describe your solution**
Several parts:
1. A simple 5-line function to calculate a position given an N-order bezier curve and the current `T` value, templated on the type of number that is used
2. Use of Dual numbers to calculate the velocity (and even acceleration), from the above simple function, without needing complex formulae for each curve size.
3. Parsing of the bezier mavlink message, and translation into uORB
4. Subscribe to the uORB, and if the newly introduced bezier message has a valid duration, use that to determine the current position and velocity indicated by the bezier curve
5. Pass these values on using the existing avoidance setpoint injection
Additionally, in order to save FMUv2 flash space, this PR moves the avoidance to a separate library and excludes it from `CONSTRAINED_FLASH` builds, replacing it with a dummy implementation. Thanks to @julianoes for the pointer with `CONSTRAINED_FLASH` - I think this is sufficient for now, but longer term I'd like to be able to do something like this via the board configuration similar to modules. @dagar any ideas on a good way to make this easy for the future, since I don't think this way scales? I'm sure there are other libraries that we'd like to replace with dummies for constrained flash builds, which can't be easily hoisted out into modules.
**Describe possible alternatives**
It might be better for this to not go through the smooth velocity interface, if it is shown that the companion can provide smooth enough curves, and rather send the data directly to the position controller.
**Test data / coverage**
Extensively unit tested. However there isn't yet a planner which can send the bezier messages, so this hasn't been flight or SITL tested.
FYI @Stifael , since you did some earlier Bezier work.
https://github.com/PX4/Firmware/pull/14272
@SalimTerryLi
Need help from the community finding hardware to test PR14269 Navio2, BBB, OCPOC
TODO : Found a problem with k66 where it won’t arm @david_s5 is looking into this
https://github.com/PX4/Firmware/pull/14269
https://github.com/PX4/Firmware/pull/14087
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.
Flight Testing sponsored by Dronecode
found the EKF2 performance bug by @bresch (3% perf gain on F7)
Move fixed wing control out of the ecl submodule
working on the timesync for RTPS bridge @TSC21