PX4 Dev Call: November 09, 2022

rroche · November 2, 2022, 5:01pm

November 09, 2022

Join us

Agenda

Community Announcement
Community Q&A
Project Updates
General Discussions
Weekly Overview
High priority queue
Release

Community Announcement

Community Q&A (No deep technical discussions)

Guideline for asking a Question

Specify what you are trying to achieve
Specify what environment / platform you are using
Prepare a Link or Document to help understand if possible
First, ask the question on the Slack or create a Github Issue!
If you take over 5 minutes for the question, please continue in Slack or a Github Issue.

Q.1 : PX4 has projection errors when vehicle is far away - Jay

When 20km out, you get ~30m altitude error.

github.com/PX4/PX4-Autopilot

Geocoordinate projection errors by assuming the earth is a sphere

opened 09:58AM - 09 Nov 22 UTC

Jaeyoung-Lim

bug-report

## Describe the bug The current Map projection assumes that the earth is a sphe…re, https://github.com/PX4/PX4-Autopilot/blob/9246d38667311b8f53c3b38a13e35bf4a3969f70/src/lib/geo/geo.cpp#L71-L92 However, this can result in large errors when projecting WGS84 coordinates to a tangential local coordinate frame. The projection should be done through a geodetic to cartesian conversion as in https://proj.org/operations/conversions/cart.html#cart ## To Reproduce Steps to reproduce the behavior: 1. Run SITL (`make px4_sitl gazebo_plane`) with the following branch: https://github.com/PX4/PX4-SITL_gazebo/tree/pr-geographic-lib 2. Fly out 20km or more and compare the geoprojection 3. Compare the projection errors using Geographiclib using topocentric projection vs projection using spherical earth assumptions ## Expected behavior A clear and concise description of what you expected to happen. ## Log Files and Screenshots The figure below shows the difference between the altitude differences when flying 20km out between the spherical assumption, and a conversion using geographic lib The log was generated in SITL Gazebo with the `plane` model. sitl_gazebo uses the same projection: https://github.com/PX4/PX4-SITL_gazebo/blob/3162519888b825a167fc3fff49c32903f81f7bce/include/common.h#L260-L280 Logged topics show - `/vehicle_global_position/alt` : GeographicLib conversion - `/vehicle_global_position_groundtruth/alt`: spherical assumption (PX4) It can be clearly seen that the altitude errors amount to ~30m at 20km distance ![image](https://user-images.githubusercontent.com/5248102/200797669-53a86420-2fef-457d-a1ac-b1f02b6d6e90.png) *Always* provide a link to the flight log file: - Download the flight log file from the vehicle ([tutorial](https://docs.px4.io/main/en/getting_started/flight_reporting.html)). - Upload the log to the [PX4 Flight Review](http://logs.px4.io/) - Share the link to the log (Copy and paste the URL of the log)

Simulation is fixed
For a ‘new gazebo’: we have a different option too.
We could move the ‘origin’ of EKF2, when we are very far away

Q.2 : Idle Throttle not set-able in DShot - Chris

With an airplane, having this motor twitching on the ground isn’t ideal. For D-Shot.

Danger of auto-throttle upon acceleration: Users can get hurt with e.g. Pusher flying wing configuration, if the motor starts spinning unexpectedly!

Project Updates

P.1 : Fixed Wing revisions - TJ

github.com/PX4/PX4-Autopilot

Fixed-wing takeoff and landing revisions

PX4:main ← PX4:more-fixed-wing-takeoff-and-landing-revisions

opened 04:00PM - 02 Nov 22 UTC

sfuhrer

+519 -367

General improvements to the fixed-wing auto takeoff/landing logic and controller… done by @tstastny and me in the last weeks. ## New things (more info contained in the commit messages) ### Runway takeoff Procedure: - ramp in throttle - hold throttle and clamp to runway until reaching rotation speed - rotate (ramp in relaxed pitch and throttle constraints, TECS controls, takeoff airspeed setpoint) - control aircraft to max climb and prescribed takeoff airspeed until reaching clearance altitude Details: - explicit runway takeoff rotation and climbout airspeed setpoints (new params `FW_TKO_AIRSPD` and `RWTO_ROT_AIRSPD`, deleted param `RWTO_AIRSPD_SCL`) - don't use climbout mode for runway takeoff climbout - ramping in of constraints and setpoints on all transitions (avoid jumps) --> remove param `RWTO_MAX_PITCH`, introduce `RWTO_ROT_TIME` ### Landing flare Procedure: - once range finder detects imminent impact (see `FW_LND_FL_TIME`), start flare - TECS is switched to height rate control at `FW_LND_FL_SINK` m/s - pitch min/max constraints, throttle max constraint, and height rate setpoint are ramped in using a *square root* function of the time since flare start (over `FW_LND_FL_TIME`) - square root to be more aggressive in the flaring action for these states - throttle setpoint and L1/NPFG periods for ground roll are ramped in linearly - if enabled, `FW_LND_TD_TIME` determines the time after flare start that touchdown is expected. after this time, touchdown clamping (for runway ground roll out) will be ramped in over a hardcoded 0.5 seconds. I.e. pitch constraint for runway. if disabled - the flare constraints will be held throughout until land is detected. More details: - use path following throughout flare (instead of changing to heading hold mode) ### Landing abort - don't allow automatic landing aborts after flare has started (manual aborts are still always possible) - disable early landing config during a landing abort - rename `MIS_LTRMIN_ALT` param to `NAV_MIN_LTR_ALT` and only consider on loiters which are *not part of a mission - use new specific param `MIS_LND_ABRT_ALT` for landing abort altitude - remove param `FW_CLMBOUT_DIFF` ### General changes - explicit landing airspeed (new param `FW_LND_AIRSPD`, replaced param `FW_LND_AIRSPD_SC`) - vehicle_attitude_setpoint: rename fw_control_yaw to fw_control_yaw_wheel to make more explicit - splitting wheel and yaw control and enable steering wheel in control allocation (allows wheel control in stabilized via yaw stick independent of attitude controller) ## Test data / coverage Most of it has been test-flown on both hand-launched and runway-takeoff vehicles. Auto take-off: https://user-images.githubusercontent.com/8026163/201090349-9300a150-b1d3-4794-aa49-d9e279bf641b.mp4 Auto land. Note in this video, just before reaching the ground, you can see the flare start, and the touchdown time initiated nose down action. https://user-images.githubusercontent.com/8026163/201090378-8dded870-6082-45c4-ac2c-c699bbe7eeaf.mp4 ## TODO: - [x] provide videos - [x] param translation - in follow up doc pr ... update documentation!

Has lots of cleanups & improvements.

Will add a video to show auto-landing & take-off

Catapult launch: Cool, but be careful and configure it wisely

P.2 : PR template update - Matthias

github.com/PX4/PX4-Autopilot

Suggestion to make the pull request template more "concise"

PX4:main ← PX4:pull-request-template

opened 04:03PM - 08 Nov 22 UTC

MaEtUgR

+24 -12

## Solved Problem I see lots of newcomers straight ignoring the pull request te…mplate. Many times the whole > Please use [PX4 Discuss](http://discuss.px4.io/) or [Discord](https://discord.gg/dronecode) to align on pull requests if necessary. You can then open draft pull requests to get early feedback. is still in and probably nothing was read. ## Solution I suggest keeping it short, no full text, the top part commented. ## Context ![image](https://user-images.githubusercontent.com/4668506/200614456-3000ea44-6311-4b79-83b5-99bd7aae3ce0.png)

Reduced amount of text
Moved the links / disclaimers into the ‘commented out’ section
We should emphasize the need to upload the Log to Flight Review!

Feel free to chime in & give opinions!

P.3 : Arbitrary Mag Rotation - Junwoo

github.com/PX4/PX4-Autopilot

Enable arbitrary euler angle for Mag rotation

PX4:main ← junwoo091400:pr_mag_arbitruary_rotation

opened 01:22PM - 19 Sep 22 UTC

junwoo091400

+105 -4

## Describe problem solved by this pull request Previously, the rotations for t…he magnetometer was confined to MAVLink defined [MAV_SENSOR_ORIENTATION](https://mavlink.io/en/messages/common.html#MAV_SENSOR_ORIENTATION), which doesn't allow setting non 45-degree multiple sensor orientation. This was a limiting factor for drones with magnetometer that has Magnetometer installed in Euler angles of something like 37 degrees, 58 degrees, etc. ## Describe your solution Enables setting arbitrary euler angle for magnetometer orientation, which would allow users to set angles like 37 degrees in yaw, which is useful for Alta X for example ### Added parameters Parameters that defines the Euler angle for the orientation the Magnetometer is at were added: - CAL_MAG${i}_ROLL - CAL_MAG${i}_PITCH - CAL_MAG${i}_YAW ## Describe possible alternatives Quaternion? ## Test data / coverage TODO ## TODO - [ ] Add QGC UI to dynamically visualize this Euler angle setting for custom rotation ## Discussion Currently, due to bringing in the MAV_SENSOR_ROTATION_CUSTOM enum, which breakes the sequence of numbers, and bumps up the value to 100, the `ROTATION_MAX` can no longer be used to calculate the number of rotations we support in PX4. You can read more about enum members number count issue [here](https://stackoverflow.com/questions/14989274/is-it-possible-to-determine-the-number-of-elements-of-a-c-enum-class). Would there be a good solution for this?

It is a real use case, so we can proceed.
Real vehicles do have some hacky new rotation enums too.
QGC Enums are also offset / wrong - Jay
We could also do better in calibration (auto-detect, etc).

Action Item:

We should get the mag cal data deletion logic in rcS script.
- Shouldn’t even be a param, best case scenario.

P.4 : DO_CHANGE_SPEED improvements

github.com/PX4/PX4-Autopilot

Ability to digest climb speed and descent speed with mav command MAV_CMD_DO_CHANGE_SPEED

PX4:main ← AscendEngineering:vertical_speed

opened 05:12AM - 27 Oct 22 UTC

afwilkin

+150 -30

Pull request for feature request #20366. - [x] test in hold with a do_repos…ition (make sure do_change_speed does not affect the up and down speed in hold mode) - [x] post logs of this working - [x] Be smarter about when to return for _getMaxZSpeed in PositionSmoothing.cpp instead of a conditional. EDIT: don't need to modify PositionSmoothing.cpp - [x] right now doing "do_change_speed" in QGC changes vertical and horizontal speeds. Functionality to separate those out is in the code, just need to pass in the correct parameters to get them. Want to create script or QGC change to test this functionality properly. - [x] Uncomment lines that pull from cruise_speed so they pay attention to the up and down variables we set in the .plan file - [x] Ensure when -2 is sent, speed type that is specified is reverted ![image](https://user-images.githubusercontent.com/16963678/198845656-4665cf01-90b6-4df7-ab1b-901506051305.png) - [x] What happens when you send DO_CHANGE_SPEED in Hold mode during a do_reposition - [x] Test with real world UAV - [x] rebase on main

General Discussions

D.1 : Should we switch to Discord for Meeting?

Pros: It’s centralized (we chat & meet in Discord!)
Cons: Discord sometimes kicks people out, and therefore not everyone has access.

Action Items:

Silencing the booooop sound when people join Discord video call
Migrating the Discord Bot to

D.2 : RTL when landed - Junwoo

github.com/PX4/PX4-Autopilot

Enable RTL even if landed

PX4:main ← junwoo091400:pr_rtl_enable_even_landed

opened 05:40PM - 12 Aug 22 UTC

junwoo091400

+18 -4

## Describe problem solved by this pull request While testing pacakge delivery …mission with RTL as one of the mission items, I noticed the following: 1. RTL doesn't work if the vehicle is landed 2. As soon as the vehicle lands, the land disarm timeout `COM_DISARM_LAND` isn't taken into account and vehicle disarms rightaway ## Describe your solution First, I added a condition where if the RTL destination is not where we are at (with the error margin of `NAV_ACC_RAD` in meters), to keep the original behavior of not doing RTL in case: we are landed at the RTL destination, but allowing RTL if the destination isn't where the vehicle is landed at. This case can easily be imagined with a package delivery mission, where an operator puts LAND, RTL mission items in sequence and expects the vehicle to return automatically. With previous code, it would never allow RTL to happen since vehicle was landed. In this case, operator may lose the vehicle :exploding_head: Second, during the test I found edge case where the vehicle's `nav_state` comes out of the `NAVIGATION_STATE_AUTO_MISSION` while landed, and enters the condition where automatic disarming while landed starts to count (hysteresis). Here, since the flag for the hysteresis was never getting reset to `False`. And the hysteresis object is shared by two different "disarm when laded" conditions (Preflight & generic land after flight cases), the previous `Preflight` case' would already set the internal requested state to `True` (until the moment vehicle took off), and when vehicle landed again, there of course has been more than ~10 seconds (`COM_DISARM_LAND` value) of time in between, so the vehicle disarmed immediately. I solved this by setting the state to False if we don't enter any of the hysteresis conditions. ## Test data / coverage Before the change: ![image](https://user-images.githubusercontent.com/23277211/184413618-eab8b892-565b-40b1-a1fa-bc590fe58c48.png) After the change: ![image](https://user-images.githubusercontent.com/23277211/184413247-129040de-1edc-4f5b-88a4-3fd7afb7f411.png) Vehicle doesn't disarm after landing, and RTLs automatically as part of the mission. ### How to test 1. Build SITL `make px4_sitl jmavsim HEADLESS=1` 2. Upload the Mission via QGC and execute the mission. Here's the mission plan I used: ![image](https://user-images.githubusercontent.com/23277211/184413772-9ba386ba-cf1d-4291-81f1-6a8cdfa33d10.png)

Right now: We can place ‘takeoff’ before RTL, to make the vehicle RTL in the air as a workaround.
PX4 *officially supports one mission storage
But multi-missions are possible by doing some custom stuff

D.3 : Param classifications

Action Item:

Junwoo will post about it (discord message link) and create issue to discuss this thoroughly.

Weekly Overview

Github

Recently updated Issues / PRs in PX4-Autopilot Link

Pull Requests
*
Issues
*

Slack

Last Dev-Call

PX4 Dev Call: November 02, 2022

High priority queue

Discussion based on: High-Priority Queue · GitHub

Release

V6C stuff - v1.13 release

Need to get [1.13] VTOL takeoff problem hotfix by MaEtUgR · Pull Request #20568 · PX4/PX4-Autopilot · GitHub in - Matthias