Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Is new at the beginning such that people with questions can get them answered at the beginning!
Idea for code space-saving on fmu-v2:
@david_s5 Replace module help with URLs on constrained system. He’ll get a number on how much flash we can save.@dagar ’s big suggestion is to remove mixing from the IO. Which would save tons of space and could also solve other reliability and mixer configuration duplication issues. We dumb down the IO firmware and let the FMU do virtually all the work.@LorenzMeier suggests doing airframe specific builds for fmu.@dagar suggests having the option to remove the shell completely.
Security patches are in NuttX now and they’ll be backported by @david_s5 .
Reported issues with I2C drivers were reported.
opened 08:54PM - 12 Dec 20 UTC
Drivers 🔧
in the meantime, does anyone still have an idea how to get the ak8963 magnetomet… er integrated in the mpu 9250 to work externally I2C together with the BMP280? Only a very small Baro/Mag combination sensor fits on the 75 mm whoop (Mamba F405 Mini MK2/Omnibus F4 Target), this is the only one that is really small enough mechanically.
BMP280 I2C, GPS (Cam M8Q) or ThoneFlow UART 6, DSHOT and DSMX RC are already running successfully, only magnetometer is still missing.
There are 2 drivers, the one outside the Ivensense folder allows I2C but lacks the -M parameter to activate the integrated compass.
Neither this MPU 9250 nor the AK8963 driver can find the sensor on I2C.
(in PixRacer, the magnetometer, which is disabled by default in the SPI MPU9250, can easily be reactivated with start -M).
#5677
#10109
Reported pixhawk cubes loosing parameters.@Jacob_Crabill had an issue with a different bootloader before which lead to parameter loss. The exact resolution of that should
opened 07:49AM - 15 Dec 20 UTC
bug
board: cube orange
Hi,
I am facing an issue similar to :
https://github.com/ArduPilot/ardupilot/… issues/13134
https://discuss.ardupilot.org/t/cube-orange-randomly-reset-parameter-to-default/52588
when using cube orange with kore board.
I Don't know if this issue has been resolved on px4 or not..!!!!
Please suggest .....
RC loss failsafe trigger delay.
PX4:master ← PX4:link-loss-delay
opened 04:00PM - 16 Dec 20 UTC
**Describe problem solved by this pull request**
I repetedly see the requiremen… t to have a delay between losing the rc link and triggering the failsafe reaction. The rc loss timeout should not be increased for that because the vehicle will consider the last known stick position and might fly away or into an obstacle not knowing that there's no pilot commanding that. So there has to be an in between state where the vehicle just waits if the link is regained and if so continues as before.
The most simple example use case is flying to the border of RC reception where the signal starts to drop out intermittently. The vehicle immediately switches to RTL and starts to turn 180° even though the pilot might have just not oriented the antenna correctly and would like to continue with the original intent whenever possible.
**Describe your solution**
With this pr the vehicle upon rc link loss by default will wait 15 seconds (`COM_LL_DELAY`) in hold mode `nav_state` but with the original `main_state` for the signal to come back. If the signal is regained the mode/operation continues like before the loss. If the signal is not regained then the originally instant loss reaction is triggered to e.g. change the main state to RTL.
Note: The case where the signal drops in and out continuously is handled by not reseting the link loss timer until 30 seconds after the first loss. This ensures that the vehicle does not get stuck because the delay continues over and over again.
**Test data / coverage**
This was extensively tested both in simulation and with a real vehicle at the border of the link reception range.
**Additional context**
In the following Slack thread @mortenfyhn asked for exactly this feature independently of my development:
https://px4.slack.com/archives/C3B9NSHRQ/p1607501257121200
I suggest he gives this pr a try.
Merged split out manual control switches published up on transition (and every second).
PX4:master ← PX4:pr-manual_control_switches_simple
opened 12:53AM - 25 Nov 20 UTC
- split out switches from `manual_control_setpoint` into new message `manual_con… trol_switches`
- `manual_control_switches` published at minimal rate (~ 1 Hz) or immediately on change
- simple switch debounce in rc_update (2 consecutive identical decodes required)
- ~~commander now polls `manual_control_switches` rather than sleeping~~ revisit later
- `manual_control_switches` logged at full rate rather than sampled at (5-10% of messages logged)
- processing of `mode_slot `and `mode_switch` is now split so we only do one or the other (not both)
- a future step will be to finally drop `mode_switch` and accompanying switches entirely
FYI @RicardoM17 @mhkabir @MaEtUgR
Arm disarm logic to handle command through RC and MAVLink the exact same way in the same place.
PX4:master ← PX4:pr-commander_control_mode_cleanup
opened 05:58PM - 24 Nov 20 UTC
Commander improvements on top of https://github.com/PX4/PX4-Autopilot/pull/16264… .
- keep `vehicle_control_mode` last state in commander and use appropriate flags in place of various main_state and nav_state checks
- consolidate scattered arming requirements in `arm_disarm()`
- there were a number of different requirements from arming via RC vs Mavlink that don't make any sense
- if geofence enabled require valid home before arming
- throttle requirements for manual modes
- remove unnecessary mavlink feedback that differs between arming interfaces (mavlink vs RC)
- let the preflight/prearm checks respond directly in most cases
The horizontal accuracy was used to reset the vertical position
PX4:master ← ShiauweiZhao:xiaowei/gps_height_reset_use_vacc
opened 03:56AM - 09 Dec 20 UTC
Refactor for altitude variance.
PX4:master ← PX4:pr-gps-alt-var
opened 09:39AM - 10 Dec 20 UTC
Review commit-by-commit.
For some reason, the GPS position variance was fused… with an accuracy of `1.5 x reported vertical position accuracy` (introduced here: https://github.com/PX4/PX4-ECL/commit/6b2e2dba909a44430dc3879e73e990231fcc2206#diff-4fbcbe3d9e3bd3fad671899aab33b57ee060d253a71a7c45e9acb78c2d297d22R125-R128).
To me, it seems to be from a copy-pasta of the GPS vertical speed fusion, where the vertical speed accuracy needs to be computed as `1.5 x reported horizontal speed accuracy`. (https://github.com/PX4/PX4-ECL/blob/fbf67bdef99f6033ce6c1fb6736cd7bf67020602/EKF/control.cpp#L698-L699).
Question about automatically switching between baro and GPS altitude.
If one is not available anymore it switches automatically.
GPS as main altitude source is not reliable depending on the flight environment.
Work in progress to fuse GPS and baro altitude
VTOL RTL improvements
PX4:master ← PX4:pr-vtol-rtl-fixes
opened 03:23PM - 11 Dec 20 UTC
Replaces https://github.com/PX4/PX4-Autopilot/pull/14728.
**Describe problem … solved by this pull request**
- currently landing on the landing pattern doesn't seem to work (land pattern = whatever of the mission is after the DO_LAND_START marker)
- high transition altitude (see https://github.com/PX4/PX4-Autopilot/pull/14728 for context)
**Describe your solution**
RTL logic with this PR, changes to current logic in **bold**
(assuming RTL_TYPE is set to 1 (VTOL and FW default, using mission landing if available))
- if close to RTL landing position and in hover, use cone RTL logic (if mission landing is planned that one is used)
- if VTOL and in hover mode, use normal MC RTL strategy (climb to `RTL_RETURN_ALT`, come back and land at RTL landing position)
- if DO_LAND_START is set (landing using mission landing):
- if in FW mode, go to DO_LAND_START marker in FW mode and from there on follow mission landing
- if in MC mode, go to the Land position and land there (don't follow landing pattern as in FW mode)
- if DO_LAND_START is not set
- if VTOL and in FW mode, climb to `RTL_RETURN_ALT`, fly to home, **loiter down until `RTL_DESCEND_ALT` in FW mode**, transition to hover and land
**Test data / coverage**
SITL tested with Standard VTOL and multicopter.
**Additional context**
For VTOL, it is recommended to always fly with a mission landing planned, such that this one can be used during the RTL. Landing approaches using mission landing can be optimized for current wind direction (transition into the wind), and result in less hover time (vehicle transitions over hover, instead of while loitering around home)
TECS improvements
PX4:master ← PX4:pr-tecs_improvements
opened 07:40AM - 10 Dec 20 UTC
The following changes were motivated mainly by two issues consequently observed… in the previous implementation of TECS:
1) Frequent under-and overshooting of altitude when demanding large altitude steps. This was especially critical when commanding low altitudes just prior to landing. Undershooting of around 5m was observed.
2) Oscillations in commanded throttle during level flight.
The fundamental change of this pull request is to move the throttle and the pitch integrator from the energy loops to the energy rate loops. Previously, the integrators were directly applied to the energy loops, which meant that their state would build up during transients when tracking of energy quantities would not be perfect. This was the main cause for altitude over-and undershooting.
Furthermore, rather than calculating the desired energy rate and energy balance rate from their respective energy error quantities, they are now calculated directly from airspeed and height errors. For this calculation two time constants are used, which describe how fast the controller will reduce errors in altitude and airspeed.
**Other changes**
New parameters:
FW_T_TAS_R_TC: True airspeed rate filter time constant -> previously hard coded
FW_T_STE_R_TC: Total energy rate filter time constant -> previously hard coded
FW_T_TAS_TC: True airspeed error time constant -> how fast the controller corrects airspeed errors
FW_T_ALT_TC: Altitude error time constant ->how fast the controller corrects altitude errors
Pitch and throttle loops now have independent integrator gains:
FW_T_I_GAIN_PIT -> pitch loop integrator gain
FW_T_I_GAIN_THR -> throttle loop integrator gain
Pitch and throttle integrator anti-windup is now handled consistently. No truncation of the state but avoid increasing saturation in the wrong direction.
Log more information in tecs_status to facilitate tuning.
The following plots shows altitude and airspeed tracking during a large altitude setpoint step. Notice how the vehicle is not able to follow the altitude trajectory because of it not being feasible. Can't descend fast without increasing airspeed. Notice however, that it does not undershoot the altitude one bit.
These VTOL and fixed-wing changes were flown before contributing to upstream so if there’s no one from the community testing it we can merge them after SITL testing.
Smoother/rounder turns in missions cutting the turn with a constant speed when entering the acceptance radius. Slow down is not needed if radius and/or high acceleration is allowed.
PX4:master ← PX4:pr-mpc-l1-upstream
opened 01:02PM - 11 Dec 20 UTC
This creates more rounded turns in multirotor mission using l1-style guidance lo… gic in corners.
Example of what can be done (default acc/jerk, acceptance radius of from 2m to 8m):
https://logs.px4.io/plot_app?log=616bf543-eb2f-44a8-90fa-63cc4b7795f6
- This will only change mission flights
- The drone doesn't stop at each waypoint but decelerates to make a turn at constant speed
- The turning radius is defined by the waypoint acceptance radius `NAV_ACC_RAD`
- A wide range of accelerations (`MPC_ACC_HOR`), jerk (`MPC_JERK_AUTO`) and velocities (`MPC_XY_CRUISE`) should work.
- Use [MPC_YAW_MODE](https://dev.px4.io/master/en/advanced/parameter_reference.html#MPC_YAW_MODE) "along trajectory" for a nice yaw coordinated turn
Other example:
Smoother yaw setpoints in the orbit approach, restored allowance to fly orbit without RC
PX4:master ← PX4:orbit-approach-yaw-smooth
opened 02:26PM - 16 Dec 20 UTC
**Describe problem solved by this pull request**
- The yaw setpoint during orbi… t approaches by previous design makes steps.
- Found during pr testing: Orbit not usable without RC
**Describe your solution**
- Put slew rate calculation for yaw used in mission into a library `SlewRateYaw`
It uses the existing `SlewRate` library but extends with correct handling of shortest turn deliberation and pi wrapping from https://github.com/PX4/PX4-Autopilot/pull/11920
- Allow Orbit without RC in commander only data link loss triggers failsafe
- Simplify circling yaws setpoint calculations based on my new knowledge.
- Use `SlewRateYaw` in Orbit to smooth out the absolute yaw setpoints
**Describe possible alternatives**
I did not use `SlewRateYaw` in missions yet because there's slightly more dependencies. I'll do that as a follow up to keep this pr lean.
**Test data / coverage**
- Added unit tests for the normal slew rate and wrapping cases of `SlewRateYaw`
- Successfully tested Orbit with SITL jmavsim without RC (data link loss still works), yaw to center and tangential yaw, smoothing, clockwise, counter clockwise, vehicle position in commended circle and outside
Typical yaw setpoint steps before:
Typical yaw ramps after:
Return early depending on the battery reach. Instead of relying on the battery capacity and current measurement, it adds a parameter for the expected flight time of the vehicle.
PX4:master ← PX4:pr-battery-flight-time-rtl
opened 11:15AM - 16 Dec 20 UTC
**Describe problem solved by this pull request**
Currently the RTL is triggered… by a fixed battery level, irrespective of the distance to home, wind conditions, vehicle flight speed etc. This means that the vehicle could run out of battery during a long RTL, or arrive home with still a large fraction of battery remaining during a short RTL.
**Describe your solution**
Take into account the flight time home during the RTL. From the RTL viability checks in navigator publish this information saying how long the RTL will take (taking into account vehicle speeds, wind speed and destination distance/direction), and what fraction of the total battery would be used by the RTL. In Commander, subscribe to this and trigger RTL if the current battery level less the battery used on RTL will take the vehicle below the existing low battery thresholds.
**Describe possible alternatives**
A parameter was used for "total flight time in RTL". This could have been taken from the power module / smart battery telemetry of the current and battery capacity values. However, for multirotor that is risky because power usage in forward flight is higher than hover, so a vehicle hovering far away would RTL too late. The parameter approach also lets users set a hard upper limit on the amount of time they would be happy with the vehicle spending in RTL, which might be useful for regulatory or safety reasons.
**Test data / coverage**
This was tested extensively in Auterion, but I haven't tested it yet since upstreaming. It should get some SITL time to make sure nothing broke in the transplant, but the concept is quite solid.
Note: it might be better to squash this on merge
Do the geofence reaction based on the prediction if it will be breached to make sure the geofence is not breached at all.
PX4:master ← PX4:pr-preemptive-geofence
opened 01:11PM - 16 Dec 20 UTC
**Describe problem solved by this pull request**
Currently, a geofence breach i… s triggered only after the vehicle is already in violation. This can lead to legal issues if the vehicle ends up outside of the expected area, safety issues if an obstacle is hit that the geofence was meant to avoid, and the vehicle can also be 'stuck' if the breach is continually triggered, overriding attempted user actions.
**Describe your solution**
Predict the motion of the vehicle and trigger the breach if it is determined that the current trajectory would result in a breach happening before the vehicle can make evasive maneuvers, if it delayed any longer. The vehicle is then re-routed to a safe hold position (stop for multirotor, loiter for fixed wing).
**Describe possible alternatives**
There was also the idea of 'shrinking' the allowed flight area, however this would not be robust to different vehicle configurations or tuning.
**Test data / coverage**
Extensive testing both in SITL and on real vehicles (fixed wing, VTOL and multirotor) inside of Auterion. I haven't tested it yet since upstreaming, and additional testing from anyone else would be appreciated.
**Additional context**
No updates
SITL tilt rotor was disabled.
Real-time factor of vehicles with aerodynamics seem to have gone down. @Jaeyoung-Lim will check why that could be.
Dec 15, 2020
Call Moderators
@rroche
@JingerZ
Agenda Items
DS-013
Battery manufacture (Fullymax ) visit from Shenzhen (Jinger)
Dail In
Direct link to the meeting:
Meeting Minutes
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.
Master is in quite a good shape. We need to take care to go through the common setups and make sure no one gets surprised with his random hardware configuration. We’ll do a release planning discussion in the new year.
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.
