Dev Call Mar 25,2024

AP_NavEKF3: define Yaw alignment min GPS speed per vehicle

ArduPilot:master ← rmackay9:ekf3-gsf-fix

opened 11:58AM - 03 Jul 23 UTC

rmackay9

+7 -3

This improves GSF performance for Copter and Rover 4.4 by reducing the minimum s…peed the vehicle must be travelling at for a GSF reset to occur. The minimum speed requirement issue (see https://github.com/ArduPilot/ardupilot/issues/24183) was introduced with PR https://github.com/ArduPilot/ardupilot/pull/23515 but the minimum (5m/s) was likely designed with Planes in mind.This PR reduces the limit to 1m/s for all other vehicles (Copter, Helis, Boats, Rover, etc). While slightly arbitrary I have tested these and I could not make GSF produce an incorrect yaw even if I set the speed limit to zero. Related discussion [is here](https://discuss.ardupilot.org/t/yaw-not-aligning-to-gsf-anymore-after-updating-from-4-2-3-to-4-4-0-beta1/101844/13) Alternatively we could add a parameter although i wonder if anyone would ever set it. This has been tested in SITL and on real vehicles for Copter, Rover and Boat and GSF always calculated the correct Yaw even when the limit was reduced to zero The user who reported the problem (and discovered the fix) has successfully tested 0.5m/s for Rover. Below is a screen shot of a couple of tests on Copter and Rover. Some debug was added to show the exact GPS speed at the moment GSF was calculated. In these particular tests I was specifically trying to trigger GSF at low speeds to see if it would calculate the wrong heading (it didn't). ![image](https://github.com/ArduPilot/ardupilot/assets/1498098/de2d89f4-9608-4fbf-95f0-fa466e6dbe65) ![image](https://github.com/ArduPilot/ardupilot/assets/1498098/ebdaf286-5bd7-437d-a75d-77f3149924ea)

AP_OSD: Add CRSF link stats display fields

ArduPilot:master ← rmaia3d:ap_osd_crsf_lnk_stats

opened 12:16AM - 29 Dec 23 UTC

rmaia3d

+2247 -1842

As described [here](https://www.expresslrs.org/info/signal-health/), knowing bot…h RSSI and LQ is important to know the health of your radio signal. Knowing the current RSSI in dbm allows comparing to receiver sensitivity limit and knowing when getting there, or close. The CRSF protocol (used by both Crossfire and ELRS radio systems) provides a link stats frame with detailed statistics that include this info and a few other items, but there currently is no way to put them on the OSD display of Ardupilot based systems. This PR adds those fields. I have used as a base the work already done by @shellixyz in implementing these fields for [Arducustom](https://github.com/ArduCustom/ardupilot) and made some changes and improvements. Main improvement is detecting when BTFL fonts are being used and automatically replace the non-existent icons in the DJI fontset with direct letter representations (in the LQ and Tx power (uplink) fields). It uses more character space, but since the HD grid is larger, it shouldn't be too much of a problem. Here's how it looks in BTFL fonts mode: ![Ardu_CRSF_LNK_STATS_BTFL_OSD_anno](https://github.com/ArduPilot/ardupilot/assets/9812730/e1bf8dd9-c378-4a70-86be-d85ea5fe1096) And in analog mode: ![Ardu_CRSF_LNK_STATS_Analog_OSD_anno2](https://github.com/ArduPilot/ardupilot/assets/9812730/a8259d0c-36e4-41db-ae1b-70cb94763c59) The added fields (RSSI in dBm, Tx uplink power, LQ in % of packets received, uplink SNR in dB and active rx antenna) are highlighted by the red ellipses in the images above. The fields are individually configurable (no need to use all 5 at once, the user can choose which one they want to use) and also I have added configurable blinking alert levels for the RSSI, SNR and LQ fields.

Add DroneCAN filesystem server and client

ArduPilot:master ← IamPete1:DroneCAN_FS

opened 03:54AM - 13 Mar 24 UTC

+1226 -3

This adds a DroneCAN file system. This allows accessing files on remote nodes. T…his could be used for logging or updating firmware on nodes. ~~So far only `stat` and `readdir` are implemented~~ (full set of available DroneCAN messages now implemented). But you can do things like this: ![image](https://github.com/ArduPilot/ardupilot/assets/33176108/4bea0ead-6d3c-4e76-a8b1-278af67106ac) The virtual `@DRONECAN` has a sub folders for drivers (0 and 1 in the example) and a further sub folder for nodes. The example shows accessing the file system of another flight controller with node ID 10 on the first (0) driver. Clients side blocks until it gets a response, so is not safe for the main thread. It can also only do one request at a time, so no pipelineing. I would like to end up with this efficient enough to use for in flight logging.....

MAVLink: log Tx and Rx data rates, SITL: add `@SYS/uarts.txt` and improve rate limiting

ArduPilot:master ← IamPete1:uart_stats_tracking

opened 02:40AM - 16 Mar 24 UTC

+255 -55

This includes a number of improvements around monitoring and testing of uart dat…a rates. - New `StatsTracker` class is added to make calculating the bytes since last call easy. This means that the uart driver can just keep a cumulative total which means we can use that total in different places over different time periods. - HAL getters added for the cumulative bytes. - byte tracking added to SITL along with `uart_info` resulting in `@SYS/uarts.txt`: ``` UARTV1 SERIAL0 TX= 142379 RX= 2155 TXBD= 4856 RXBD= 73 connected (tcp:0:wait) SERIAL1 TX= 0 RX= 0 TXBD= 0 RXBD= 0 not connected (tcp:2) SERIAL2 TX= 0 RX= 0 TXBD= 0 RXBD= 0 not connected (tcp:3) SERIAL3 TX= 1929 RX= 62622 TXBD= 65 RXBD= 2135 connected (GPS1) SERIAL4 TX= 0 RX= 0 TXBD= 0 RXBD= 0 connected (GPS2) SERIAL5 TX= 0 RX= 0 TXBD= 0 RXBD= 0 not connected (tcp:5) SERIAL6 TX= 0 RX= 0 TXBD= 0 RXBD= 0 not connected (tcp:6) SERIAL7 TX= 0 RX= 0 TXBD= 0 RXBD= 0 not connected (tcp:7) SERIAL8 TX= 0 RX= 0 TXBD= 0 RXBD= 0 not connected (tcp:8) ``` - New logging unit added for bytes per second using `B` - MAVLink connections report transmit and received data rate in the `MAV` log message. - SITL baud rate limits made more accurate. MAV example log from SITL with improved baud limits set to 57600 baud. This results in the expected rate of 5760 bytes per second. ![image](https://github.com/ArduPilot/ardupilot/assets/33176108/7df1a43f-7b1b-48df-9959-02570855e5cb)

Mount: improve yaw lock reporting to GCS

ArduPilot:master ← rmackay9:mount-yaw-lock-option

opened 01:25AM - 20 Mar 24 UTC

rmackay9

+86 -5

This makes a few enhancements to our AP_Mount library to improve the GCS's abili…ty to set and retrieve the current yaw-lock state. This is required for the QGC custom gimbal control screen (see https://github.com/mavlink/qgroundcontrol/pull/11264) To clear up terminology: - yaw **lock** means the yaw (target or actual) is in earth-frame - yaw **follow** means the yaw is in body-frame Detailed changes are: 1. MNT1_OPTIONS parameter added with a single option bit called, "RC lock state from previous mode" allows users to specify that they want the yaw lock state carried over from the previous mode when they switch to RC_TARGETING (e.g. the pilot controls the sticks). Previously the yaw-lock state was only set-able using an RC auxiliary switch. If the user is actively controlling the gimbal with both the RC and GCS though it can be convenient to carry over the state. 2. GCS can use the [DO_GIMBAL_MANAGER_PITCHYAW](https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/common.xml#L1700) command and [GIMBAL_MANAGER_SET_PITCHYAW](https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/common.xml#L6189) message can be used to set the yaw lock state in RC_TARGETING mode by setting target pitch and yaw angles and rates to NaN 3. Comments added to clarify that AP_Mount's set_lock() method only affects RC_TARGETTING mode (e.g. when the pilot is controlling the gimbal with the sticks) 4. [GIMBAL_DEVICE_ATTITUDE_STATUS](https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/common.xml#L6142) reports the target yaw lock state. This message's flags are confusing but what we do here seems correct ([see here](https://github.com/mavlink/mavlink-devguide/pull/531)) This work was based on @Davidsastresas's earlier PR https://github.com/ArduPilot/ardupilot/pull/26474 This has been lightly tested in SITL.

AP_GPS: remove blended GPS from small boards

ArduPilot:master ← peterbarker:pr/blended-not-on-small-boards

opened 04:22AM - 21 Mar 24 UTC

peterbarker

+70 -36

those boards which are not including all backends will lose blended after this …``` Board AP_Periph blimp bootloader copter heli iofirmware plane rover sub CubeOrange-periph-heavy * Durandal * * * * * * * Hitec-Airspeed * KakuteH7-bdshot * * * * * * * MatekF405 -2688 * -2656 -2680 -2792 -2680 -2688 Pixhawk1-1M-bdshot -2624 -2664 -2656 -2624 -2672 -2624 f103-QiotekPeriph * f303-Universal * iomcu * revo-mini -2648 * -2752 -2680 -2552 -2680 -2664 skyviper-v2450 * ```

AP_ExternalAHRS: Use filter data to populate EKF status report

ArduPilot:master ← Ryanf55:microstrain7-fix-ekf-status-reporting

opened 09:43PM - 23 Mar 24 UTC

+39 -7

## Purpose The MicroStrain5 and MicroStrain7 were reporting the EKF status u…ncertainties using GPS uncertainty. The position uncertainty was too high, so the EKF status was yellow in MavProxy (position uncertainty was greater than 0.5. I switched to use Vector3f's to represent some of the values as it makes the data structure simpler to work with, such as using the `.xy()` operator for horizontal vector and `.length` for L2 norm. With this patch, we still sometimes see bad gyro health warnings on hardware, but those can be addressed in another PR. The original MicroStrain5 driver introduced this problem and still has it, but I'm no longer maintaining that driver. ## Before ``` >>> status EKF* >>> MANUAL> 8126: EKF_STATUS_REPORT {flags : 831, velocity_variance : 0.08249999582767487, pos_horiz_variance : 0.5034999847412109, pos_vert_variance : 0.6890000104904175, compass_variance : 0.0, terrain_alt_variance : 0.0, airspeed_variance : 0.0} ``` ## After ``` >>> status EKF* >>> MANUAL> 60: EKF_STATUS_REPORT {flags : 831, velocity_variance : 0.007317372132092714, pos_horiz_variance : 0.31877070665359497, pos_vert_variance : 0.4544658064842224, compass_variance : 0.0, terrain_alt_variance : 0.0, airspeed_variance : 0.0} ``` ## Wiki https://github.com/ArduPilot/ardupilot_wiki/pull/5835

AP_ExternalAHRS: Provide warning for init failure

ArduPilot:master ← Ryanf55:microstrain7-initialize-failure-warning

opened 10:58PM - 23 Mar 24 UTC

+82 -36

# Purpose * If the device hasn't initialized in 5 seconds, give a warning tha…t it failed. Without this, you just fail pre-arm checks. Before, if the device was disconnected, this would say it initialized, when in reality only the driver was constructed. * A failure of the AHRS system to read any data was reported as a failure to get the origin, even if the backend knew that it was something more fundamental, such as no data received. After this PR, the backend gets to report pre-arm failures before origin failures. # No cable connected ![image](https://github.com/ArduPilot/ardupilot/assets/25047695/d3b8154f-9c6f-4952-8554-52365ff0ca75) # Cable connected and data streaming configured ![image](https://github.com/ArduPilot/ardupilot/assets/25047695/9bf044c9-46fa-4ee2-91b2-edd05d0a182a) # Other thoughts perhaps we should keep track of the initialization state, and give a success when it changes to true (event-based)? I did this in a follow up commit. If the devs like it, I'll squash it together. Pete suggested reordering the pre-arm checks to check the backend before verifying the origin. I liked it, so that's incorporated.

AP_ExternalAHRS: Only use GPS data when populating GPS fields in MicroStrain7

ArduPilot:master ← Ryanf55:microstrain-use-only-gps-data

opened 01:19AM - 24 Mar 24 UTC

+7 -7

# Purpose Only populate GPS data from the GPS. If the filter diverges, then t…he reported GPS velocity can go haywire, while the GPS may still be stable. This should be considered a bug. The original MicroStrain5 driver introduced this problem and still has it, but I'm no longer maintaining that driver.

AP_OSD: use `set_and_default` when ensuring first screen is enabled

ArduPilot:master ← IamPete1:osd_defualt_enable

opened 03:50PM - 24 Mar 24 UTC

+2 -2

The set here makes it look like a user change. I have also updated the comment t…o reflect what the code does, forcing to enabled. Alternatively we could just call `set_default` to only change the default but not set the value if the user has configured which is what the comment seems to suggest it should do.

AP_OSD: use `set_and_default` when ensuring first screen is enabled

ArduPilot:master ← IamPete1:osd_defualt_enable

opened 03:50PM - 24 Mar 24 UTC

+2 -2

The set here makes it look like a user change. I have also updated the comment t…o reflect what the code does, forcing to enabled. Alternatively we could just call `set_default` to only change the default but not set the value if the user has configured which is what the comment seems to suggest it should do.

AP_ExternalAHRS: Add pre-arm for misconfigured EAHRS_SENSORS and GPS_TYPE

ArduPilot:master ← Ryanf55:eahrs-prearm-for-gps-configuration

opened 02:47AM - 25 Mar 24 UTC

+107 -7

# Purpose * This catches when there's a mismatch of GPSx_TYPE and EAHRS_SENSO…RS when GPS is enabled * Before this pre-arm, failure to set GPS_TYPE2 to 21 (ExternalAHRS) resulted in silent rejection of the data in AP_GPS because the default is off * The wiki did not say to set GPS_TYPE on anything but the VN300 * For now, until we support 3+ GPS instances, this only checks if you have at least on GPSx_TYPE set to EAHRS. Drive by fix - logging problem in Microstrain7 with format strings. # Tests Tested in SITL with MicroStrain7 hardware. And, a new CI test: ```bash ./Tools/autotest/autotest.py build.Plane test.Plane.GpsSensorPreArmEAHRS ``` # Why? The default behavior is to disable the 2nd GPS, so MicroStrain7 was dropping the data on the floor in the call to `AP::gps().handle_external(gps, instance);` # Futher improvements The same behavior is possible with other external sensors?

Plane

Plane 4.5.x issue tracking

opened 03:03AM - 13 Feb 24 UTC

tridge

Plane DevCallTopic ReleaseAdmin

Pending: - [ ] centre throttle options not working: https://discuss.ardupilot.…org/t/plane-4-5-0-beta-release/112518/14 - fix in mission planner https://github.com/ArduPilot/MissionPlanner/pull/3291 - [ ] ramping of motors on tilt quadplanes not working on back transition - fix https://github.com/ArduPilot/ardupilot/pull/26249 - [ ] POSITION_TARGET_GLOBAL_INT alt is wrong for terrain following - [ ] ALT_ASSIST not working while completing fwd transition? - [ ] terrain following not working from long distances in QRTL - [ ] re-test flightgear and JSBSim recent versions https://discuss.ardupilot.org/t/aircraft-appears-underground-on-ardupilot-flightgear - [ ] should auto-set HAL_USE_ADC=False if no ADC lines in hwdef.dat - [ ] ftp fence upload not working - [ ] exfat with 64G sandisk can't create APM/scripts directory - [x] lua/log corruption on 6x: fix: https://github.com/ArduPilot/ardupilot/pull/26538 - [ ] unplugging CAN battery mon leaves voltage unchanged - should it go to zero? - [ ] should a dead rangefinder report zero distance? - [ ] pitch stick mixing on landing needs to handle changed height - [ ] add AP_STATISTICS_ENABLE for dma.txt and --enable-status in custom build - [ ] is terrain offset handling correct? see angel log7 Resolved - [x] https://github.com/ArduPilot/ardupilot/pull/26133 Longer term - [ ] https://github.com/ArduPilot/ardupilot/pull/25442 - [ ] rebuild newlib and remove all possible abort() calls

Copter & Rover