Attendees (unique) : 7
UTC0702
opened 11:17AM - 23 Jun 26 UTC
## Bug Report
During AP4.7.0 beta testing [this discussion](https://discuss.ard… upilot.org/t/copter-4-7-0-beta7-is-available-for-beta-testing/144197/24) includes a report of InternalError:switch_full_sector_recursion occuring (aka "0x200000") if an autopilot is left powered on for a long time.
The internal error probably comes from [here in AP_FlashStorage](https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_FlashStorage/AP_FlashStorage.cpp#L145).
**Version**
4.7.0
**Platform**
[ ] All
[ ] AntennaTracker
[x] Copter
[ ] Plane
[ ] Rover
[ ] Submarine
**Airframe type**
Copter
Peter : An error where you’re trying to switch to a full sector.Andrew : Yes, there’s only one place it could be called from.
It means while it’s trying to change into a new sector, it’s trying to call it again.
That’s a new one.
P : It seems to be expected, since after we fill up a page, we can’t switch away and erase it.A : Why? When we do that, we repack the parameters in the new page and erase the old sector.P : We don’t do the erasing without triggering a watchdog.A : No, we certainly can erase a single sector. But yes, not when armed.
It should be easy to reproduce this in SITL, by changing a lot of parameters.
But with an H7 it would take a VERY long time.
P : I seem to have a flash.dat in an old PR that would reproduce this error.A : I suspect it’s related to the size of a write when the storage is almost full.
AI says it could happen if you remove power after a sector is declared full but the new one is not switched to yet.
If that’s true, then it would be possible to reproduce in SITL.
UTC0715
master ← peterbarker:pr-claude/skyviper-v2450-no-header
opened 10:39PM - 23 Jun 26 UTC
### Summary
Allows for the removal of heater support on fmuv3 boards that do … not have a heater
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [ ] No-binary change
- [ ] Infrastructure change (e.g. unit tests, helper scripts)
- [x] Automated test(s) verify changes (e.g. unit test, autotest)
- [x] Tested manually, description below (e.g. SITL)
- [x] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
Pixhawk1-1M boots just fine after this
Changes across all boards and builds:
```
Board antennatracker blimp bootloader copter heli plane rover sub
Pixhawk1 -1032 -1024 * -1008 -912 -888 -960 -1152
Pixhawk1-1M -1032 -1136 * -1032 -1024 -984 -1000 -1136
Pixhawk1-1M-bdshot -1032 -1064 -1024 -1024 -1056 -984 -1072
Pixhawk1-bdshot -1040 -992 -1016 -856 -1168 -1112 -1192
fmuv2 -1008 -1016 -848 -912 -912 -1040 -1040
mRoX21 -1040 -1024 * -400 -840 -1152 -1032 -896
skyviper-v2450 -976
```
### Description
Splits fmuv3 boards into a .inc file (for specific boards to include) and hwdef.dat (for generic fmuv3 things that we can't remove without breaking people's fmuv3-flashed boards)
Initial patch is a pure move.
Also makes fmuv3-bdshot include fmuv3-non-bdshot rather than being basically an entire sideways copy.
I think in a future PR I will make all fmuv3-like boards inherit from fmuv3.inc
P : Updated boards which don’t have code to run a heater anyways. They don’t have a heater AFAIK.A : I’m slightly concerned there’s a board that actually has a heater and we cook the board by removing the pin definition.
For example, the Pixhawk1 didn’t have a heater, but I don’t know about the various clones.
But you’re probably right with this change. The only board that I have doubts about is the MRoX2.1.
P : I’ll ping MRo then.
UTC0725
master ← peterbarker:pr/set-origin-iteration-then-notify-then-collection
opened 02:20AM - 23 Jun 26 UTC
### Summary
Iterates over the array of backends to call the update / get-resu… lts / maybe-set-origin code
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [ ] No-binary change
- [ ] Infrastructure change (e.g. unit tests, helper scripts)
- [x] Automated test(s) verify changes (e.g. unit test, autotest)
- [ ] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
### Description
The backend update calls are currently intrinsically intertwined with the calls to set_origin. We must check to see if we can set a common origin immediately after calling the update based off the returned values from the backend and (currently) the `get_origin()` call on the backend. You can't `update()` all backends and then try to set a common origin in a second loop as multiple backends could have decided on an origin. Consider this PR a step towards re-jigging how we work public origins in the AHRS.
Also fixes a bug where ExternalAHRS wasn't getting the common vehicle navigation origin as there was an override missing (that's been in there since the common-origin stuff was last reworked a few years back). Tests added for that, one of which fails before and passes afterwards.
We update the configured backend first. This is a behaviour change as we *did* update DCM (and SIM) before updating the configured backend. This only affects scheduling order, there's no data dependence at this point.
.... also zeroes the estimates before get_results so all backends are now uniform there.
A : Do we get a race condition if both EKF2 and EKF3 set an origin?P : No, because we set the origins sequentially. If we did this in threads, then yes, we risk a race condition.
Resetting the EKF across a thread would also be problematic. It would need a mutex.
Incidentally, this PR will make it so the configured AHRS backend will update first and consume CPU first, potentially starving the active backend (when they are different).
A : Does the external AHRS query the origin?P : Apparently we set it and then we query it in get_relative_position_NED.A : Approved! But would be nice to do some hardware/flight testing.
UTC0743
master ← peterbarker:pr-claude2/replay-retry-block
opened 06:30AM - 22 Jun 26 UTC
### Summary
SITL-only change avoids CI flake where the IO thread doesn't work… fast enough to get data from the buffer to disk
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [ ] No-binary change
- [ ] Infrastructure change (e.g. unit tests, helper scripts)
- [ ] Automated test(s) verify changes (e.g. unit test, autotest)
- [ ] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
No compiler output on CubeOrange Copter
Test branches show the fix:
- replay-torture (reproducer, expect ❌ 0 / 10): https://github.com/peterbarker/ardupilot/actions/runs/28077382449
- replay-torture-fix (torture + fix, expect ✅ 10 / 10): https://github.com/peterbarker/ardupilot/actions/runs/28077384456
### Description
retry each backend until it gets it right!
Integer-wrap-protection was just crap, removed it. Arithmetic elsewhere checked.
A : In SITL, does get_hw_rtc() scale with speedup? It shouldn’t.P : No, it’s wallclock.A : You’re right.
Strange that we don’t use this call anywhere else.
So io_thread() is blocked from advancing because of the simulated time.
P : The delay in io_thread() also prevents us from pushing a lot of data out.A : How about setting a VERY large buffer size on replay SITL so that it can hold the whole log?
It could probably fit about 32MB.
It would be a smaller change.
A : Approved!
UTC0804
master ← Georacer:feature/custom_plane_controller
opened 03:02PM - 29 May 26 UTC
### Summary
This PR adds support for custom Plane controllers, as `AC_CustomC… ontrol` [does for Copter](https://ardupilot.org/dev/docs/copter-adding-custom-controller.html).
### Description
A new library `AP_CustomControl` has been created, which roughly operates the same as the existing Copter counterpart.
Things that are the same:
- The overall flag is `AP_CUSTOMCONTROL_ENABLED`. The library is not part of the features list. It is meant to be explicitly, locally compiled in. SITL will compile it by default.
- Multiple custom controllers can be compiled-in and selected via `CC_TYPE`.
- An AUX switch enables or disables the controller (109).
- A basic PID example is given, which can fly a plane successfully.
Things that are different:
- The Copter custom controller is designed to return a strict control API, in the form of `Vector3f` for roll/pitch/yaw pre-mixer inputs. However this is not very useful for Plane. See below for the new API.
- Copter uses `CC_AXIS` to quickly enable/disable custom roll/pitch/yaw controllers. Since AP_CustomController now recommends unconstrained access to output functions and servos alike, The parameter has been replaced by `CC_MASK`. This is meant to be used by the developer to fence whatever function within the custom controller he pleases.
#### Recommended API
The developer has complete freedom to shape the custom controller code to his liking.
However, the following methods of `AP_CustomControl` are the recommended way to interact with the outputs:
```c++
// Write a scaled value to all channels with a function.
void set_output_scaled(SRV_Channel::Function function, float value);
// Write a pwm value to all channels with a function. Not min/max constrained. servos.cpp may overwrite it.
void set_output_pwm(SRV_Channel::Function function, uint16_t value);
// Write pwm values on a channel. Not min/max constrained. servos.cpp may overwrite it.
void set_output_pwm_chan(uint8_t chan, uint16_t value);
// Override pwm values on a channel for one loop. servos.cpp will not overwrite it.
void set_output_pwm_chan_override(uint8_t chan, uint16_t value);
```
These will reach into `SRV_Channels` and write the passed values.
This also means that **any** servo channel can be written to, even unconfigured ones. This is very useful for experimental control allocation schemes.
Typical input channels are also given quick-access and updated on every loop:
```c++
void AP_CustomControl_Backend::update_rcin_channels() {
channel_roll = &rc().get_roll_channel();
channel_pitch = &rc().get_pitch_channel();
channel_throttle = &rc().get_throttle_channel();
channel_rudder = &rc().get_yaw_channel();
channel_flap = rc().find_channel_for_option(RC_Channel::AUX_FUNC::FLAP);
channel_airbrake = rc().find_channel_for_option(RC_Channel::AUX_FUNC::AIRBRAKE);
}
```
The euler angle targets are exposed to
```c++
float get_roll_target_deg() { return _frontend.roll_target_deg; }
float get_nav_pitch_target_deg() { return _frontend.pitch_target_deg; }
float get_pitch_target_deg() { return _frontend.pitch_target_deg + _frontend.pitch_trim_deg; }
```
which are filled with
```c++
custom_control.roll_target_deg = nav_roll_cd * 0.01f;
custom_control.pitch_target_deg = nav_pitch_cd * 0.01f;
custom_control.pitch_trim_deg = g.pitch_trim;
```
#### Servo overrides
The custom controller task will run after the `stabilize` task and before the `set_servos` task.
This means that by default the safety checks mixing which happens in `servos.cpp` will still apply and may override the custom controller.
However, a method `set_output_pwm_chan_override(uint8_t chan, uint16_t value)` is given, in order to block `set_servos` from modifying this channel. This can be useful for implementing experimental/custom mixers.
#### Known drawbacks
- The parameter namespace is also `CC`. I think this might cause conflicts in the wiki?
- Due to the implementation details, output functions of GPIO (-1 enum value) cannot be addressed. Not sure how to fix that.
- AFAIK, the Plane codebase doesn't do rate controller and/or control surface bumpless transfer upon mode switches (e.g. FBWA->MANUAL). That means that there will be a step in servo output upon switching out of the custom controller and into a rate-controlling mode. The integrators are being actively reset, but this is a perfect solution. Perhaps the upcoming #32743 will fix this.
- Upon exiting the custom controller, all the main controllers are reset. Since these controllers are individually, constantly reset while the custom controller is running, there might be no reason to reset them all anew, including controllers which might not have been overriden.
#### Known unknowns
- I suspect the current RC inputs API doesn't allow accessing channels >8. I have to verify this.
- If the custom controller writes onto unused output channels, their PWM value will go from 0 whatever is requested. However, when the custom controller is suspended, the servo value will not return to 0. I do not yet know how to restore this state.
<img width="1368" height="919" alt="image" src="https://github.com/user-attachments/assets/ae199adb-25e8-4e05-9302-a11d03f59833" />
### Classification & Testing (check all that apply and add your own)
- [X] Checked by a human programmer
- [ ] Non-functional change
- [ ] No-binary change
- [ ] Infrastructure change (e.g. unit tests, helper scripts)
- [X] Automated test(s) verify changes (e.g. unit test, autotest)
- [X] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [X] Logs attached
- [X] Logs available on request
Testing has been carried out in autotests as well as RealFlight.
The new autotest attempts to explore as much of the new functionality as possible. You need to read the PID example controller that is used in order to fully understand the test.
In RF, the test have been done with the FT3DXL aircraft. It is very clear when the controller banks are switched, the Custom Controller isn't tuned for this aircraft and it produces angle overshoots. Other than that, no bugs or side-effects have been observed.
Parameters and logs: [Dropbox](https://www.dropbox.com/scl/fo/i9wncuajxgpdtiocgg9p1/ACuCPd5g3Vrdy4cHC1xioi4?rlkey=ay0d4q8ha7o4haa9r8xxsjclt&st=5onxxaek&dl=0)
P : We didn’t get to fly this.G : Let’s wait for Pete Hall to approve it.P : Left a few nonblocking comments.
UTC0813
master ← peterbarker:pr-claude2/serial-protocol-check
opened 03:39AM - 20 Jun 26 UTC
### Summary
Fails builds if a hwdef specifies a default serial protocol which… does not exist.
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [ ] No-binary change
- [x] Infrastructure change (e.g. unit tests, helper scripts)
- [x] Automated test(s) verify changes (e.g. unit test, autotest)
- [ ] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
I have run this through all boards (except ModalAI and esp32) to ensure they compile.
### Description
Created in response to a PR for a new board which was setting slcan on otg2 without actually having SLCAN built in.
Adds a sanity check - run in CI only for now - which ensures that if you nominate a default for a serial protocol that that default actually exists.
It forces non-numeric values in these defines now.
We don't enable this by default primarily because of the custom build server. We would need some mechanism to disable this there!
Chief problem here is maintenance - any addition of a serial protocol has to have an entry in this file, it's something that could get stale. There's no sensible way to check if a value in the hwdef is valid *without* this compile-time check, however.
A : Approved once the missing protocols are addressed.
UTC0817
master ← peterbarker:pr/AP_AHRS-mag-backend-data
opened 03:18AM - 02 Jun 26 UTC
### Summary
Removes another switch on the active EKF type, instead getting th… ings directly from the active estimates.
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [ ] No-binary change
- [ ] Infrastructure change (e.g. unit tests, helper scripts)
- [ ] Automated test(s) verify changes (e.g. unit test, autotest)
- [ ] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
```
Board AP_Periph antennatracker blimp bootloader copter heli iofirmware plane rover sub
CubeOrange-periph-heavy * *
CubeSolo * 24
Durandal * * * * * * * *
Hitec-Airspeed * *
KakuteH7-bdshot * * * * * * * *
MatekF405 * * * * * * * *
MatekH7A3 * * * * * * * *
Pixhawk1-1M-bdshot * * * * * * *
SITL_x86_64_linux_gnu 240 240 0 0 0 0 0
YJUAV_A6SE 0 0 * 0 0 0 0 0
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
mindpx-v2 * * * * * * * *
revo-mini * * * * * * * *
skyviper-v2450 *
speedybeef4 * * * * * * * *
```
### Description
Removes more switch statements for the estimators.
New defines needed to keep this a no-compiler-output change for most platforms
A : Usually we gate by AP_Compass, not AHRS. What happened here?P : Back then Johnathan Challenger wanted to use the AHRS values apparently.A : Approved!