ArduPilot EU Dev Call 2024-12-14

Georacer · December 4, 2024, 7:25am

Attendees (max): 6

github.com/ArduPilot/ardupilot

Plane: Fix inability to climb the last few meters of takeoff

ArduPilot:master ← Georacer:pr/takeoff_level_off_bugfix_2

opened 06:58PM - 01 Dec 24 UTC

Georacer

+84 -4

## Summary This PR addresses #28685 and supersedes #28707. ## Details T…his affects takeoffs without an airspeed sensor. ### Cause Some airframes will not climb at 0 pitch, regardless of throttle setting. Thus, the current takeoff level-off strategy of asymptotically forcing pitch to 0, results in the aircraft to never climb the final few meters. ### Reproduction The behaviour was reproduced in SITL, by setting: - `PTCH_TRIM_DEG`: -10.0 - `TKOFF_THR_MAX`: 75.0 ### Solution After the expected time to complete the takeoff has elapsed, drive the desired pitch gradually back to takeoff pitch, over the next 5 seconds. ### Testing **Before**: The plane starts level off but manages to climb only up to 45m and hovers there, stuck in takeoff stage. ![Screenshot from 2024-12-01 19-49-33](https://github.com/user-attachments/assets/c345660c-9d36-41ce-8167-dc6ad9dfe56f) **After**: The takeoff times out after 2s (`TKOFF_PLIM_SEC`) of being in the level-off maneuver. ![Screenshot from 2024-12-01 19-50-37](https://github.com/user-attachments/assets/e774b05f-85d1-4833-a25d-ead5130e0cab) ### Alternatives The proposed solution of widening the TECS pitch limits and letting TECS take over and regulate the last few meters of the climb was not feasible: During an airspeedless takeoff, TECS uses throttle to correct for altitude errors. It would use pitch (if it was allowed) to correct for airspeed errors). Thus letting TECS command the pitch angle would not help. The previous PR #28707 was deemed too complicated and too heavy-handed. This present PR prefers to hand over altitude control to TECS.

UTC0700

Andrew: It would be nice to have a better TKOFF_PLIM_SEC description.

github.com/ArduPilot/ardupilot

autotest: Enabled old test and added new test on home alt reset

ArduPilot:master ← Georacer:pr/home_change_height_test

opened 11:32AM - 27 Nov 24 UTC

Georacer

+26 -5

# Summary Regarding Plane tests on Home Alt change during flight: - Enabled …old disabled test that was already passing, but was malformed. - Created new test variant, where the altitude change occurs during stable level flight. # Details ## Old test The existing test should be passing since https://github.com/ArduPilot/ardupilot/pull/24487, but it was malformed. It should be checking for the absolute altitude to be constant. The relative one is supposed to change. Additionally, before it would perform an FBWA takeoff and would switch to FBWB/CRUISE/LOITER at an altitude that might not be exactly takeoff alt. Since these modes reset the altitude setpoint upon entry, it would be hard to test for a specific altitude. Now the takeoff happens upon TAKEOFF mode, waits for the altitude to settle and then switches the mode. @peterbarker let me know if you had intended for this autotest to test something different. ## New test The new test tries to make the check a bit more explicit, by doing the Home alt change during a stable, level flight, instead of the end of the takeoff climb. # Testing ## Before The new test was passing even before https://github.com/ArduPilot/ardupilot/pull/28675, as expected. The cursor is at the moment of Home Alt change. The TECS altitude was correctly changed: ![Screenshot from 2024-11-27 12-19-15](https://github.com/user-attachments/assets/38bf3bee-aaa9-497f-a67a-99df3e117bed) TECS was getting reset, as expected: ![Screenshot from 2024-11-27 12-19-23](https://github.com/user-attachments/assets/b20c52a6-8002-4588-bee6-9447a2d30796) The absolute altitude was roughly stable, but the TECS reset caused a dampened oscillation: ![Screenshot from 2024-11-27 12-19-19](https://github.com/user-attachments/assets/791565a5-f8ca-4c5b-bbd8-9e8404b1de1f) ## After After https://github.com/ArduPilot/ardupilot/pull/28675 TECS is shifting again: ![Screenshot from 2024-11-27 12-20-48](https://github.com/user-attachments/assets/18ee121f-f87e-4500-80f4-104bb324536d) but TECS does not reset: ![Screenshot from 2024-11-27 12-20-55](https://github.com/user-attachments/assets/d9d3526c-57c6-487c-ac70-97279b86f902) and the altitude does not have a transient anymore: ![Screenshot from 2024-11-27 12-20-51](https://github.com/user-attachments/assets/cf922f6f-daa0-4b11-bb36-d1dfc90ed7de)

UTC0709

github.com/ArduPilot/ardupilot

Scripting promote video-stream-information to an applet

ArduPilot:master ← rmackay9:scripting-video-stream-information-easy

opened 04:53AM - 30 Nov 24 UTC

rmackay9

+318 -34

This enhances the set_VIDEO_STREAM_INFORMATION.lua to make it usable without any… code changes by at least some users. The script is also promoted to an applet The purpose of this script is to give the AP_Camera library the information it needs so that it can send [VIDEO_STREAM_INFORMATION](https://mavlink.io/en/messages/common.html#VIDEO_STREAM_INFORMATION) mavlink messages to the ground station so that it can display the live video stream to the user 15 new parameters have been added prefixed with VID1_ that allow the user to set nearly all fields of the VIDEO_STREAM_INFORMATION but for most users all they will only need to set these six: - VID1_CAMMODEL: Video stream camera model (1:Siyi A8, 2:Siyi ZR10, 3:Siyi ZR30, 4:Siyi ZT30 Zoom, 5:Siyi ZT30 Wide, 6:Siyi ZT30 IR, 7:Siyi ZT6 RGB, 8:Siyi ZT6 IR) - VID1_IPADDR0: Video stream IP Address first octet - VID1_IPADDR1: Video stream IP Address second octet - VID1_IPADDR2: Video stream IP Address third octet - VID1_IPADDR3: Video stream IP Address fourth octet - VID1_IPPORT: Video Stream IP Address Port This has been successfully tested with the Siyi A8, ZR10 and ZT6 cameras and [Mission Planner's new gimbal interface](https://github.com/ArduPilot/MissionPlanner/pull/3386) Enhancements coming in future PRs: - default the IP address and Port to the camera defaults - add support for ViewPro, Topotek and any other Ethernet enabled camera gimbal

UTC0710

Randy: PR makes it easier to setup the URI.
A: Please fix the markup in the .md file.

github.com/ArduPilot/pymavlink

Mavgen C: Use strncpy instead of memcpy to pack char[n] fields

ArduPilot:master ← shancock884:iss725-string-serializarion

opened 01:52PM - 14 Feb 24 UTC

shancock884

+100 -10

The aim of this PR is to fix #725 and fix mavlink/mavlink#1946 ### Current si…tuation: At present when a user calls the `mavlink_msg_<message>_pack` function on a message containing char[n] fields, these fields will be copied into the destination buffer using memcpy. This can go wrong in a couple of ways, if end users are not careful, for example.... 1. If specifying an argument as a string literal, the read will go beyond the input variable's scope, which could have some bad consequences: ```C mavlink_msg_param_request_read_pack(mysys, mycomp, &msg, tgtsys, tgtcomp, "PARAM", -1); ``` 2. Even if using a large enough buffer, it is possible that the bits of memory beyond the null may contain leftover or random values, which would end up in the message. In this example, bytes after null could be anything when requesting PARAM, and will include the last bit of LONGER_PARAM when reading SHORT: ```C const char* list_of_params = {"PARAM", "LONGER_PARAM", "SHORT"}; char param[17]; // enough for null for (int i=0; i<3;i++) { strcpy(param,list_of_params_i_want[i]); mavlink_msg_param_request_read_pack(mysys, mycomp, &msg, tgtsys, tgtcomp, param, -1); } ``` These extra bytes will stop the Mavlink 2 message-truncation from being as efficient as it can be, and may confuse some receivers. ### Proposal: This PR proposes to use the strncpy function when packing char arrays, as I believe that this aligns with the way in which Mavlink char array fields are specified and used: * destination array will be filled up to a maximum of n chars, and therefore may not be null-terminated. * if null is found within the n characters, reading stops, and the remainder of the destination up to n is filled with zeros. This should both protect against reading bad memory, and also ensure bytes beyond the length of short strings are zero, allowing the Mavlink 2 message truncation to work properly. For little-endian and struct-aligned cases: This is done by replacing the calls to `mav_array_memcpy` in mavgen_c.py with type-specific array assignment macros `mavlink_array_assign_[type]`. For char arrays, this uses `strncpy` (after check that input is not null pointer). For other arrays, this is a thin-macro which calls `mav_array_memcpy`, as per current behaviour. Big big-endian or non-struct-aligned cases: This is done by an update to the existing `_mav_put_char_array` function to use `strncpy` (after check that input is not null pointer). ### Testing I've tested this update (in particular using the PARAM_REQUEST_READ and PLAY_TUNE messages) on my system. I also checked compilation with MAVLINK_ALIGNED_FIELDS=0.

UTC0716

A: Simon [Hancock], I think you’re right on this one.

One thing: We’re not usually strict in the XML to diff. between the array of char and the array of byte.

Simon: I looked a bit and I didn’t see any obvious conflicts.

The original message I stumbled upon was PLAY_TUNE.

A: I’ll defer to Peter for this one, sorry.