ArduPilot EU Dev Call 2024-12-11

Development Team
1

Attendees (max): 8

UTC0709

Andrew: 4.6.beta2 PR has some release failures.

  • Ubuntu Jammy fails install.
  • RTC needs logging fixup commit to be brought along.
  • Some more open regressions can be found on the related Github ticket.
  • Lots of improvements over beta1

UTC0717

A: Traditionally we didn’t do that because it didn’t seem reasonable.
Alexander @bengterik: I’m not particular about restoring state if the short FS clears. Perhaps leans toward staying in RTL.

  • The main use-case is to get back to LTE-available areas.
  • We can’t use long failsafe for that, as we need it to be Glide.

A: Sounds like Advanced FS is a better fit for this use-case.
Al: I’ll read up on it.

UTC0726

Andy: Testing is going well.

  • What other testing do we need on this?
  • There’s a cost on this issue, probably we want this for H7 with the big NAND flash chips.
  • Costs more flash.

A: Can it replace logging in F4 chips?

An: Chips are usually small and things don’t go well when space gets full.

  • But the flash cost might be a blocker.

A: We should make sure we test a build configuration for F4, mainly for size comparison.

  • How about SITL?

Andy: It is possible, but we’d need to emulate the filesystem.
A: Not a showstopper, but would be a nice to have.
Andy: You need to be careful with when you sync a block to storage.

  • There’s instructions in the LittleFS project.

A: It’s a little ugly that the logger has to calculate the block size itself.

  • Would be nice if it was encapsulated.
  • We could partition the NAND, for logging and scripting.

Andy: That would be bad, both for performance and memory management.

  • If the NAND cache (2KB) is full, the write will block.

A: We can’t enable it by default in bigger chips, without knowing the build size cost.

  • But it’s nice to try.

Michelle: Apparently it saves flash compared to block logging. Suspiciously much.

UTC0756

Andy: Do we need to worry about Copter?
A: Haven’t done any flight tests.
Andy: SITL testing is also fine.

UTC0759

Andy: Now only applies during fast rates

  • I guessed that the buffer length needed to increase, because there now would be more data.
  • How could I test if this is necessary? How full a buffer is?

Sid: We had issues with IMU buffer before.

  • Unfortunately you need to run for a very long time to give a chance for bugs to arise.

A: If we needed to buffer more data, we might actually get a lot more corrupted data.

  • And in the current implementation we indirectly reset the IMU when a buffer grows close to full.
  • Your primary lane will be fine, but upon switching to another, those IMUs might be in a bad state.
  • Let’s make this change an Invensense v3 only change. We’re probably safe there.

Andy: How do I test?
A: You need to look at all IMUs/lanes. Make sure all EKFs are happy.
Sid: I also have concerns over the CPU usage.
A: This is only brought online when fast rate is enabled.
Sid: I generally am not in favour of features that can dynamically increase the CPU usage (and can happen mid-flight).
A: Would be nice to have the Monitoring thread warn that the idle thread hasn’t run in a few cycles.

UTC0824

Andy: Logging logic would be outside of the LOGGER_ENABLED fences.

MergeOnCIPass

UTC0927

A: Looks good, let’s wait for testing.

UTC0828

Andy: Sid persuaded me on this in another discussion.