ArduPilot EU Dev Call 2025-04-30

Attendees (unique): 14

UTC0702

EKF3 wind estimation dead reackoning test without airspeed is flapping.
EKF typically estimates winds wrongly.


UTC0707

Additional CI tests to check that the commit messages are correct.


UTC0712

Andrew: What’s the difference between the two MISSION_REQUEST message?
Peter: They’re equivalent, but their handling is different.
A: The XML says it should be handled the same. That MISSION_REQUEST should reply with a MISSION_ITEM_INT.
The timeline is OK to go ahead.


UTC0724

P: For the moment we’ll keep it. But we’ll eventually phase out the RANGEFINDER MAVLink message.
Currently having a werid CI build error.


UTC0728

Approved and MergeOnCIPass!


UTC0733

P: There’s a danger of leaking a device if you probe for it but don’t find it.
A: It’s nice that we save space, but the readability suffers a lot.
A: We could be doing sort of a manual reference count on the device allocations.
Lupus the Canine: Shared references or pointers fit the bill for this use case.
A: Do these work without compiling in exceptions?
S: They are available, if you mark them as noexcept.
A: They still use a lot of flash.
Perhaps indeed it would be more legible to have probe return void and have a separate “check space” method.
Could we look at the compass as well and anticipate any common changes?
Ah, the compass registrations care about ordering as well. That’s important because of the corresponding calibration parameters.
I’d prefer not to order barometers, it incurs more parameters; it’s going to be confusing.
L: What is the issue with using those C++ features?
A: We don’t compile with exceptions, which sometimes brings in bugs. E.g. the compiler always assumes that new will never return a null pointer.


UTC0822

MergeOnCIPass!


UTC0829

S: This moves the MAVLink portion out of the CAN manager.
Same as the NAT.
This allows to run it in AP_Periph.
Use-case: You have a third board connected via Serial to a CubeNode. It speaks MAVLink. It should be accessible over ethernet by the flight controller or other test devices.
This addresses converting ethernet CAN to serial CAN. Trying to build test platforms, where we need to convert ethernet to serial.
To put it differently: one device is DroneCAN GUI tool, connected over multicast to an FC. The FC is connected via Serial to a 3rd device. You want to see the CAN bus of the 3rd device.
A: Why not connect the 3rd device to a CAN bus?
S: Because the bus might be too congested. Whereas the serial port could be running at 12Mbps and could support it.
A: We’d definitely need a new feature for this, to be custom-enable. Also the new parameters should be in a different file, for clarity.


UTC0902

Merged!


UTC0903

A: This could be moved to an ARMING_OPTIONS bit.