ArduPilot EU Dev Call 2025-01-22

Attendees (max): 8

UTC0705

Andrew: Typically, we’ve done kind of work this with AUX_FUNCTIONS up until now, instead of MAVLink commands. Why not do the same?

  • Or even a specific COMMAND_INT.

UTC0710

A: I’ll need to think about this a bit more. This could be done in another backend.


UTC0713

Andy: At first it worked, then it broke. Now it should work again…
A: Best to be looked at by Randy, as it’s Copter-only.


UTC0717

Merged!

Andrew: We still need to document it.


UTC0724

A: Approved.
Andy: We still need to test this with Michelle.


UTC0727

A: Why do we use the primary accel at all in AP_AHRS.cpp?
Andy: We have always done it at this point in the code. The feature in general doesn’t mess with it.
A: I don’t see that running in master.
Andy: AHRS used to call get_primary_accel(), to ask INS what it thinks the primary accel was.
A: It’s not clear to me if there’s a change in behaviour compared to master.

  • As it seems, this there is now an extra call, which isn’t useful.
  • In practice accel and gyro indices are shadowed by the primary IMU index. They’re not actually individually addressed. Let’s not entangle accel and gyro indices further in the codebase.
    A: In IS_v3 there is now a behaviour change in the adjust_periodic_callback(). It might be for the best.
  • Why do we need to update at 5Hz?
    Andy: Making sure that the primary is always set to the right index, in case the initialization comes in too early in the boot and gets overwritten.
    A: I don’t love it, but without the accel/gyro indices changes, it can be merged.

UTC0750

Matt: I’m using the same timer as the attitude and position controller. Peter thinks this isn’t right.
A: The feature is a FAST_TASK, hence this is the right timer to use. If it was a scheduled task, it might not get called sometimes and the delta could be very wrong sometimes.


UTC0754

A: We use custom-lenght 2’s complement in the codebase. Might be worth embedding it in AP_Math.

  • Also add a comment to credit Betaflight for their code.
  • Let’s make sure to test it. Either they test it for us, or they send us a board. Or at the least we buy one for ourselves.

UTC0759

A: Looks harmless.

  • Let’s add some documentation.

Merged!


UTC0800

Andy: Andrew what do you think about this one?
A: Seems reasonable, but Sid has the most reason to review.

1 Like

Sorry to interrupt, maybe this is not the best way of doing it…

I suggest strongly that you revisit (programatically) the arduplane behaviour when it is stalling.

I have tested it out on a foamy plane and did not like at all how it behaves.

Before I was using a lot Pitlab AP, and I never were able to put any of my planes into a spin in any stabilized modes or above (stab, fbw, auto, etc).

With a very gentle foamy, I was able to do it all the times. The worst part of ardupilot, that once in a spin, it just aggravates it, keeping elevator and ailerons in position a beginner pilot would do (up elevator, ailerons against the rotation).

I am not sure what algorythm Pitlab is using to prevent stalls and spins, but it is very effective and works extremely well even without airspeed sensors.

So. I feel it is very urgent to see how arduplane could prevent stalls.

And possibly to implement a spin detection (quite easy, you have to check VZ and rotation) and do classical spin recovery procedure (no up elevator, no aileron, counterrudder until rotation zero, then up elevator).

You may have all the bells and whistles, but if basic flying is not good, then there is really no point of working on these bells and whistles.

Hello,

Naturally, you understand that this project has 10+ years worth of inertia, so it’s quite hard to just change controllers overnight.

However, the project does evolve, albeit gradually.

If you would like to discuss issues, feel free to open a ticket on Github.
If you have proposals, Github, here in Discuss or over at our Discord, are the places to do it.

Thank you for your feedback!