Main/0 Journal/0 Daily/2025-09-19.md

aliases, Tags, day_grade, Dehnen, Sport, Ernährung

aliases	Tags	day_grade	Dehnen	Sport	Ernährung
	daily

2025-09-19

2025-09-18 <--> 2025-09-20

Error generating daily quote

---

Planning

• Organize slack standups for monday
• Review simulator with jerry
• do flight with valentin

Saturday

• Hackathon: MVP for logserver --> publish it and host it. Core functionality: Parse chirp file, add it to the database as timeseries (use time series parsing and chirp parsing). New project with direct dependency on chirp (include as a submodule). Database structure
• Logs
  • id
  • date_added
  • file_path
  • file_size
  • status: ChirpFile::Status
  • chirp_binary_size
  • chirp_log_size
  • chirp_version
  • chirp_file_type: should always be chripCombined
  • chirp_participant_id
  • text_content
  • LogMetrics
    • log_start_date_time
    • log_end_date_time
    • log_duration
    • flightcontroller
• TimeSeries
  • either we have a table per Opcode, meaning we need to update the schema whenever we change the chirp version
  • or we have a table for TimeSeries and one for TimePoint:
    • Series
      • id
      • log_id
      • opcode
      • source_id
      • component_id
      • device_id
      • message_name
      • field_list
      • count
      • t_start_us
      • t_end_us
• Special Cases:
  • SoftwareVersion Message --> parse to metrics
  • Parameter update Message --> own table
  • ConsoleEntry Message --> own Table
  • DebugMessages (create one time series per key --> create DebugTimeSeries?)
  • extract perf_counters and put them into a table
  • we should never have file transfer packets

---

Reflection

---

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, 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.

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