ArduPilot EU Dev Call 2025-01-29

Attendees (max): 11

[Discussion on clang’s --scan --build arguments]

UTC0706

Andrew: I prefer for the callback to inform the caller about these status flags.
Sid: Even though this will consume more flash space? Ok.


UTC0722

A: Henry proposes that CTUN should have this information. It’s plane-specific. And meant to help with tuning.
G: Okay, agreed. But separate to that, what do we want ATT.DesPitch to show?
A: By the same logic, Q_TRIM_PTCH should also be applied. But still, it’s best to edit the CTUN instead.

  • The ANG message was not updated.
  • But in general ATT should be showing what AHRS is showing, whereas CTUN should be relative to trimmed pitch angle. In a correctly tuned aircraft flying level, both CTUN.Pitch and CTUN.DesPitch should show 0.

G: How to find the trim pitch deg?
A: ATT.

  • CTUN would be nice to reflect the currently active controller, FW or VTOL.
  • I’m not sure if ANG reflects the AHRS view rotation either.

UTC0745

P: George you had some comments?
G: Yes, IMO it’s not an NFC, while it wants to be.

  • I glanced over Pete Hall’s script and I think it doesn’t take into account the interaction between Attitude.cpp and TECS.cpp
  • I won’t be able to review this immediately, though.

UTC0746

A: This looks much better now.
P: x

Merged!


UTC0748

A: It seems we’re not clearning the temporary maximum.

  • Indeed it is a regression.

UTC0752

Randy: Approved.

Merged!


UTC0753

P: It’s a new way to replace the OwnPtr structure.

  • Eventually replace all OwnPtr calls.
  • It could save up to approx. 3k in flash.
  • In Durandal it saves 968 bytes! We’d better find out if that’s honest.

A: Let’s also test on Linux.


UTC0805

Merged!


UTC0806

Randy: I don’t understand why the place where the boolean changes (at the start or at the end) makes a difference.
Andy: It clearly helps, though.
Randy: Perhaps ap.motor_test is part of a byte/bitmasked?
P: No, we changed that, it’s no longer part of a bitmask.
Andy: motors.cpp is also using ap.motor_test. That’s likely where the interaction takes place.
P: Is this a problem on master?
Andy: Yes.
Randy: There might be some interaction. But just moving ap.motor_test = false a few lines down can’t be the reason for the fix.
P: Those lines can’t even be the reason for the fix: They are situated after the test is finished.
A: I really don’t want to put a semaphore just for the motor test. It would bog down the fast rate thread.


UTC0819

Merged!


P: Can’t merge it tonight.

  • Why don’t we drop a flow-control error and see if we hit it in the next few years?

UTC0827

Pull-up resistor has been suggested again.


UTC0830

P: I think this is OK but it would be nice to have Tridge here.

  • A partner is getting 40 errors in 4hrs. I couldn’t get any errors in 24hrs.

Andy: You could try running with D-Shot, it makes timing more sensitive.
Michelle: It was a normal place, with the pusher on DroneCAN.
P: This PR makes it so that we can turn a blind eye to vast amounts of data resulting in errorer transaction.

  • It would be better if there was still some checking for excessive errors.
  • We should also try to understand what causes those board IO errors in only some users.
  • Michelle has sent them a debug firmware, they’re willing to test.

UTC0844

Andy: I couldn’t carry out all of the testing that was asked.
P: You could use the option that logs all incoming traffic from the GPS, whose name I don’t remember right now.


Ryan: Are we sure the GNSS undulation is added in with the correct sign?
P: No, we’re not sure.

  • You could also compare with PX4.

Ryan: Peter, could you send me a (replay) .bin log and a .tlog from CMAC, that would be helpful.