ArduPilot EU Dev Call 2024-09-18

Georacer · September 18, 2024, 9:52am

Attendees (max): 10

UTC0700
Discussion on the latest crashdump on a Durandal, provided by Leonard.
Andrew: Looks like it was raised from AP_GPS.

Perhaps it was doing a broadcast message, such as a printf

Sid: But this was running on AP_Periph, it wouldn’t print on the main FC.
A: We would need to find the program line that corresponds to this program counter.
Leonard: CAN was plugged in, I was communicating to the FCU via CAN.
Sid: Yes, it is very likely that it’s a deadlock related to CAN.

UTC0739
MergeOnCIPass

UTC0743
S: This will allow testing GPIO and smarter pin configuration.
A: Only as long as the pin is marked as GPIO in hwdef.

Docs have become more nitpicky, they need a bit more care.

Approved.
MergeOnCIPass

UTC0751
Closed, replaced by #28137

UTC0752
A: The conversation with Pete needs to be wrapped up.

github.com/ArduPilot/ardupilot

Plane: Takeoff improvements

ArduPilot:master ← Georacer:pr/tecs_improvements

opened 03:45PM - 05 Aug 24 UTC

Georacer

+370 -263

This PR fixes TECS oscillations that would occur once mode TAKEOFF would reach `…TKOFF_ALT`. Additionally, it harmonizes the takeoff behaviour between modes AUTO and TAKEOFF. Finally, it fixes a few bugs. Many thanks to @Hwurzburg for sharing code for fixing the pitch setpoint. ## Notable behaviour changes 1. Mode TAKEOFF and AUTO now behave identically during a takeoff. 2. `TKOFF_LVL_ALT` now also affects AUTO mode. 3. TAKEOFF mode now respects the level-off angles, as it approaches altitude. There should now be significantly less overshoot. 4. The behaviour of TKOFF_ROTATION_SPD now works as advertized. It was inactive before. ## Notable code changes 1. Mode TAKEOFF now spends all of the climb in FlightStage::TAKEOFF, just like AUTO mode did. 2. `TECS::set_pitch_max_limit()` is now split into `TECS::set_pitch_max()` and `TECS::set_pitch_min()`. Its usage in `quadplane.cpp` has been modified accordingly. 3. TECS pitch limits are now applied at the end of the calculation. Before, vertical acceleration limitations were applied last. 5. TECS: `_post_TO_hgt_offset` will now never pull height demand above the target altitude. 6. `mode_takeoff.cpp` is now prevented from switching behaviours from past `TKOFF_ALT`-2m back to climb behaviour. This would cause behaviour switching if the plane would drop slightly lower than 2m from `TKOFF_ALT`. 7. There are many occasions were TECS is overridden both in pitch and throttle. When that happens, TECS is now effectively inactive and will reset itself. 8. Changed behaviour of `TECS_PITCH_MIN` to match description. 9. `servos.cpp` now doesn't try to enforce all of the takeoff throttle logic combinations. Only `TKOFF_THR_MAX` and `TKOFF_THR_MIN`. ## Tests The following were tested in autotests: 1. Altitude and pitch no longer oscillation upon reaching the takeoff altitude. ✅ 2. TAKEOFF and AUTO takeoffs now behave exactly the same in all combinations of `ARSPD_USE` and `TKOFF_OPTIONS`. ✅ 3. The level-off of minimum pitch demand now works in TAKEOFF. ✅ 4. When `TKOFF_ROTATE_SPD` is nonzero, pitch demand will be 5deg before the rotation speed and will climb up to the minimum takeoff pitch for groundspeed equal to cruise airspeed. ✅ The following were tested in manual SITL: 1. Altitude and pitch no longer oscillation upon reaching the takeoff altitude. ✅ 2. The level-off of minimum pitch demand now works in TAKEOFF. ✅ 3. When `TKOFF_ROTATE_SPD` is nonzero, pitch demand will be 5deg before the rotation speed and will climb up to the minimum takeoff pitch for groundspeed equal to cruise airspeed. ✅ ## Known issues 1. Ground speed is used in some airspeed comparisons. 5. If AUTO is engaged while in flight and has a NAV_TAKEOFF point, it will force the pitch to positive while it gets processed. This lasts for a few cycles. 6. The SITL plane doesn't regulate pitch well when it's flying at full throttle and fast. Nothing to do with this PR, just an observation. ## Future work 1. I noticed that if you load a mission before you get a GNSS fix, the NAV_TAKEOFF waypoint (i.e. next_WP_loc) will be set at coordinates at the home coordinates and altitude. This can break some takeoff logic in AUTO mode. 2. Render `TKOFF_LVL_ALT` a higher-level parameter, as it is now used also by AUTO mode, not just TAKEOFF.

UTC0758
A: We can have Peter launch TAKEOFF without compass, non-North.

We would need to make sure that state_takeoff.min/max throttle doesn’t get updated and servos.cpp keeps enforcing it. Make it more robust through mode changes. Or use a timestamp to use them only in the last 100ms or so.
Does FlightStage::ABORT_LANDING also use takeoff_calc_throttle() in the same way? Does it work as expected? Can it be in ABORT_LANDING in a mode other than MODE_LAND?
If min/max are set in every loop, it’s safe to zero them out in every loop, to guarantee that they won’t persist accidentally.
Henry is welcome to do some more SITL tests.

UTC0837

UTC0844
Approved.

UTC0845
A: Approved.

Would be interesting to try out GCC 13 at some point. See which one does a smaller build.

github.com/ArduPilot/ardupilot

Reduce overhead when doing SPI transactions

ArduPilot:master ← bugobliterator:pr-spi-perf

opened 06:48AM - 13 Sep 24 UTC

bugobliterator

+74 -27

* Tested on CubeOrangePlus and CubeRedPrimary with Invensensev3 driver * I us…ed debug trace to analyse timeline for read_fifo to check if we have any substantial overhead while doing SPI transactions. It turned out that calling spiStart and spiStop which in turn call dmaStreamAlloc and and dealloc to take substantial amount of CPU call almost 3-4us. Also we were calling Shared DMA mutex lock and unlock when the DMA is not shared between peripherals. * Following changes made SPI transactions much less CPU intensive: - * Do not reset SPI peripheral using spistop and spistart calls if SPI config hasn't changed. - * Also make changes to SPI frequencies for CubeOrangePlus and CubeRedPrimary to match on the bus where possible (minor CPU gain through this, just first part was enough as most transactions are IMU anyways). - * Do not call mutex lock unlock for unshared DMAs. Results: CubeRedPrimary: Before: SPI1 PRI=181 sp=0x20001AA8 STACK= 792/1464 LOAD=13.4% SPI4 PRI=181 sp=0x200021C0 STACK= 872/1464 LOAD=13.4% SPI2 PRI=181 sp=0x20005380 STACK= 896/1464 LOAD=13.3% After: SPI1 PRI=181 sp=0x20001B08 STACK= 792/1464 LOAD= 9.7% SPI4 PRI=181 sp=0x20002220 STACK= 792/1464 LOAD=11.2% SPI2 PRI=181 sp=0x200053E0 STACK= 840/1464 LOAD= 8.3% CubeOrangePlus: Before: SPI4 PRI=181 sp=0x3002AF58 STACK= 668/1464 LOAD=25.5% SPI1 PRI=181 sp=0x3002B668 STACK= 668/1464 LOAD=14.5% After: SPI4 PRI=181 sp=0x3002AF78 STACK= 668/1464 LOAD=19.2% SPI1 PRI=181 sp=0x3002B688 STACK= 668/1464 LOAD= 9.5% >10% total CPU time recovered for both CubeOrangePlus and CubeRedPrimary

UTC0855
(Sid was inaudible, couldn’t discern)
A: Remove the AP_Inertial changes and then it looks good.

We’ll have to come to an understanding on what Andy means by increased latency.