obsidian/Main
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2025-09-19 14:13:05

Browse Source 
Affected files:
0 Journal/0 Daily/2025-09-19.md
This commit is contained in:
Obsidian-MBPM4
2025-09-19 14:13:05 +02:00
parent 4f09e0a443
commit cc28902a85
1 changed files with 13 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
0 Journal/0 Daily/2025-09-19.md
View File

@@ -70,11 +70,22 @@ ___
___
## Notes
I do think that the parameter system is important, especially once we're flying with the autopilot in the loop.
### Parameter System
The parameters of every subsystem (autopilot, flightcontroller) are independent from each other and they live in the respective components. What this parameter system is is nothing else than parameter protocol, which allows to read and set parameters through chirp. The only coupling there is is that we will be able to do that from our development computer and the autopilot forwards the requests which are meant to be for the flight controller. Like this the parameters of both the flightcontroller and the autopilot can be configured over the network without having to open up the drone and get a usb cable into the teensy every time and change a small setting.
The parameters of every subsystem (autopilot, flightcontroller) are independent from each other and they live in the respective components, meaning they are not coupled. What this parameter system is, is nothing else than parameter protocol, which allows to read and set parameters through chirp. The only coupling there is, is that we will be able to read and change parameters from our development computer and the autopilot forwards the requests which are meant to be for the flight controller and keeps the ones which are for itself. Like this the parameters of both the flightcontroller and the autopilot can be configured over the network without having to open up the drone and get a usb cable into the teensy every time and change a small setting.
What it specifically means for the flightcontroller code:
- currently the parameters are stored in like 10 different files as constants (or sometimes just as magic numbers without any name). this means that every time we want to modify a parameter (e.g. control gains or physics model variables like the mass) we need to open that specific file in the source code, change it and reflash the teensy (this also changes the software version, because you're essentially flashing a different firmware file.)
- Therefore, the plan is to implement a parameter registry (or we could also name it parameter Manager class), where all the changeable parameters of the flightcontroller are stored. The different modules that require the parameter values then ask the registry for the parameter.
- This parameter registry also has API functions which lets the outside (e.g dev computer or cm4) get and set parameters through a small chirp message we send to the flightcontroller.
- the exact architecture of this is not yet determined.
- the exact architecture of this is not yet determined.
### Ugur
I disagree about him only pulling us backwards. Since its a isolated project, which is also easily unit tested, we can be very sure about that it doesn't introduce additional bugs. And I don't want valentin to take care of it since he should focus solely on the control.
In terms of what he should do before firing him (excluding parameter system):
- update confluence articles that reflect the architecture as we have it today
- write a detailed readme for the flightcontroller project as well as the mujoco simulator.
- Share backlog with me
- write unit tests for all libraries
- he should make loom videos of every process