Georacer
July 1, 2026, 8:12am
1
Attnedees (unique) : 7
UTC0704
master ← peterbarker:pr-claude/name-filter-fault-bits
opened 01:31AM - 29 Jun 26 UTC
### Summary
Gives these bits names and uses them within the code and within t… he logger metadata
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [x] Non-functional change
- [x] No-binary change
- [x] 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 * *
Durandal * * * * * * * *
Hitec-Airspeed * *
KakuteH7-bdshot * * * * * * * *
MatekF405 * * * * * * * *
Pixhawk1-1M-bdshot * * * * * * *
SITL_x86_64_linux_gnu 0 0 0 0 0 0 0
YJUAV_A6SE * * * * * * * *
f103-QiotekPeriph * *
f303-MatekGPS * *
f303-Universal * *
iomcu *
revo-mini * * * * * * * *
skyviper-v2450 *
speedybeef4 * * * * * * * *
```
The SITL changes are because there are extra debug symbols associated with the new enumeration. That's possibly something to look at fixing in `size_compare_branches.py`
### Description
Not clear whether we really *should* be exposing these outside the EKFs - perhaps the information should only be reflected in the return values for various getters. Only user is the active-backend determination stuff, and that could probably be achieved by looking at various fields in the estimates structure. We could also perhaps be more nuanced in our backend selection by looking at this information (e.g. "do we need position right now?")
But this is a no-compiler-output change (or near-enough) and (a) removes flat numeric constants from the code (b) ties the EKFs together so they don't diverge on this faults structure and (c) adds to the logger metadata to make log analysis a tiny bit easier.
Merged!
UTC0707
master ← peterbarker:pr-claude2/large-replay-buffer
opened 10:39AM - 24 Jun 26 UTC
### Summary
Pushes the buffer up to ridiculous levels to
### Classificati… on & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [x] 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
### Description
try to avoid Replay failures where we fail to log blocks
Merged!
UTC0710
master ← peterbarker:pr-claude/mavlinktransferspeed
opened 09:19AM - 20 Jun 26 UTC
### Summary
Don't be so picky when looking at mavlink log transfer speeds to … avoid test flakiness
### 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
### Description
wall-clock-vs-simtime issue, don't abandon the test if we don't always see messages from mavlink due to a stall
In the future we may need to make this run closer to real-time.
Merged!
UTC0712
master ← peterbarker:pr/build_boards.py
opened 01:02AM - 13 Jun 26 UTC
### Summary
Creates a new script based on size_compare_branches.py infrastruc… ture to build all boards.
### Classification & Testing (check all that apply and add your own)
- [x] Checked by a human programmer
- [ ] Non-functional change
- [x] No-binary change
- [x] Infrastructure change (e.g. unit tests, helper scripts)
- [ ] Automated test(s) verify changes (e.g. unit test, autotest)
- [x] Tested manually, description below (e.g. SITL)
- [ ] Tested on hardware
- [ ] Logs attached
- [ ] Logs available on request
I've been using a backport of this to test the beta release PR
size_compare_branches.py still fine.
### Description
shares most code with size_compare_branches.py - just configures/builds boards based on board_list
Peter : New tool to refactor the existing test sizes one and build all your boards.
For local build testing, not CI.
UTC0715
master ← peterbarker:pr/camera-instance-SET_CAMERA_FOCUS
opened 03:59AM - 21 May 26 UTC
### Summary
Extends support for focussing cameras so multiple can be targette… d according to the mavlink spec.
### 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
```
Board,antennatracker,blimp,bootloader,copter,heli,plane,rover,sub
CubeOrangePlus,8,16,*,16,8,24,16,16
```
Added tests that not only verify that the new focus commands work when sent by the GCS, but also that taking photos, zooming and focusing specific cameras can all be done with mission items.
### Description
Allows cameras to be individually addressed for focussing
Small bugfix to filter out heartbeats from the autopilot component which is not the flight controller (presumptively)
Randy : We probably need to update Mission Planner to update its .XMLs, to that the mission item columns are properly labelled when selected.
UTC0720
master ← kraln:sdcard-aes256-xts-encryption
opened 06:11PM - 27 Jun 26 UTC
### Summary
Adds support for transparent full-disk encryption of the SD card,… with a software AES core
and a clean interface for platforms with hardware acceleration.
Off by default.
### 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
- [ ] Logs attached
- [ ] Logs available on request
Testing performed:
- Unit tests for the AES implementation against FIPS-197, cross-checked a bunch of
different inputs/outputs against OpenSSL's implementation
- Built ArduCopter for CubeOrange with with `AP_FATFS_CRYPTO_ENABLED 1` and disabled;
the flash cost is ~0 when disabled due to garbage collection at the linker level (so, no impact).
It's about 2.5kb when enabled.
### Description
Firmware updates, waypoints, logs and more land on the SD card (when present and on
platforms that support them). The ChibiOS FatFS layer acts as a translation/lookup tool,
so deleting files (well, "unlinking" them) doesn't guarantee data is actually gone. This
means that a lost or stolen card can reveal unintended and undesired information about
the vehicle operator, even if the vehicle is destroyed (stuck in a tree, etc.)
This PR adds transparent full-disk encryption so every sector, including the metadata which
shows what files are present, is encrypted. The encryption is fully software, with an interface
for extending it with hardware acceleration on microcontrollers that support it. The implementation
uses AES-256-XTS, similar to BitLocker,/LUKS, etc.
The key is a build-time constant, so this only protects against the card being removed. There's a python utility
to decrypt SD card contents from a host computer, given the (known) key.
Notes:
- Enabling encryption (or changing the key) makes an existing plaintext card read as corrupt. The card must be reformatted.
- Log download over MAVLink and in-flight replay are unaffected
- Software AES-256 may throttle very high-rate storage activities
- This depends on the companion ChibiOS PR https://github.com/ArduPilot/ChibiOS/pull/105
Randy : We discussed it, but it falls onto tridge to decide.Peter : It needs a much stronger justification, because it exposes us to a bigger attack surface.
Claiming that the SD card is encrypted is a very strong one, and if we take it on, we’d have to pool significant resources to make sure it’s true and stays true.
There are some SD cards that encrypt themselves with special drivers, so that might be an alternatives solution.
Jeff Katz : The idea was to do an incremental PR, so it’s more succinct. And other features (such as the key transfer) would be filled in later.
UTC0732
master ← peterbarker:pr-claude/MAV_CMD_REQUEST_OPERATOR_CONTROL
opened 10:53AM - 05 Jun 26 UTC
### Summary
Adds support for development.xml messages (still under review) to… pass control of the system from one GCS to another (or several)
### 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
### Description
Much discussion in various places, most notably in the [mavlink PR](https://github.com/ArduPilot/mavlink/pull/503).
There's a [MAVProxy PR adding support](https://github.com/ArduPilot/MAVProxy/pull/1692)
QGC has support in the codebase but (a) it is not enabled by default and (b) the message set that QGC compiles against by default has an older version of this message.
George : I did some testing, where I left unconfigured MAV_GCS_SYSID/_HIGH. Then I used the new MAVLink messages. But even GCSs with sysid out-of-range could send messages.P : That’s not what should have happened.G : Perhaps MAV_OPTIONS had to be set. But we don’t want to be manually setting that parameter.P : No, we don’t.G : During testing with MAVProxy, I also noticed that sometimes the control was getting allocated and then immediately released. Probably a bug with MAVProxy, haven’t met it in QGC so far.
< Discussion on adding more fine-grained feature control from individual GCCs >P : I have an experimental branch, currently workign off of the same message.
But we’re better off shipping the simple version that we have in our hands right now.
G : Could we use the capabilities enum to identify the different facilities?P : I don’t see how they’re similar.G : How about a parallel system to configure which GCS has access to each facility, similar to how we negociate a mission upload?P : Hm! Perhaps.