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.