Design discussion: linear algebra, actuators

[mlyle]

Will close this issue in a couple days after any discussion.

I want to make actuators do fancier things. There's basically 3 considerations:

1. Right now the limited mixer matrices don't cover all control axes (e.g. accessorydesired) and it would be nice to be able to do more.
2. There's things we know about actuators that it'd be nice to react to before the delay of the delay loop. We know if we've clipped on output; we know likely delays and time constants. A simple smith predictor down in actuator makes a lot of sense. There's a simple version of this I'll discuss below and likely the desire of vehicle-type specific code (e.g. tricopter).
3. Some actuators even give explicit feedback and it would be nice to use this.

My general design is this:

• Move the mixer matrix to be a real nxm matrix and handle forward mixing by multiplying the axis command vector by the mixer matrix.
• Handle special cases (clipping, power-add limiting). Send this stuff to the motors.
• Simulate each of the actuators based on what we sent it. [Or read the actual attained effort back and combine it with simulation]
• From the simulated actuator effort, calculate the actual effort on each of the axes. This is handled with a multiply by an inverse mixer matrix (and possible vehicle-specific fixup before/after, e.g. tricopter corrections).
• Apply a fixed linear correction to the "next command" based on any control effort error (P control)

This second-to-last step is where I get stuck. Our mixer matrices are not square and even if they were are very likely to be over-or-underdetermined-- especially if we include things like accessory commands (also cases like hexcopters, etc). There is a well-defined pseudoinverse operation that can handle this (Moore-Penrose). However, calculating it requires running big numerical algebra codes (SVD or QR factorization) which are generally A) not easy to build for microcontrollers, B) built to work on huge problems rather than relatively small matrices. and C) expensive.

There's basically 3 approaches I can think of:

1. Grit our teeth and bring a linear algebra system into the codebase.
2. Calculate the inverse mixer matrix in the ground system. This will create future issues with using this kind of infrastructure with tiltrotors, etc.
3. Come up with some clever way of trimming matrices or iteratively solving this problem to a "good enough" state.

Does anyone have any feedback or suggestions?

[mlyle]

@jihlein , @peabody124 , @tracernz --- suggestions and advice wanted.

Option 4 is "write our own smaller linear algebra code" --- which is arguably the best option but I don't really want to do it.

[mlyle]

One last comment.. the "real" system parameter is the effect that actuators have on the system. (e.g. how much motor a moves the left side up vs. motor b etc). In effect, we currently ask the user to configure the inverse of that. Now this will use the inverse operator to get back to the real physical parameter.

[mlyle]

On the linalg thing, I've found an interative approximation algorithm that works well, and can live with arm-math plus a few small linalg routines written.

@jihlein-- the question remains-- can you foresee moving towards much of triflight being glued in at this kind of layer? (working a little differently than before). It provides a clean interface for it...

[jihlein]

@mlyle, I think the triflight concept could work with this. What would be good is a high level system block diagram. It would not only help the current developers with understanding the concept, it would be a roadmap for new developers. I do like the idea of one large mix matrix that can handle all inputs and all outputs.

I used the DSP lib for some simple matrix math in a different project. It was a little funky to setup as I recall, but it worked well in the end.

One other thing to think about besides triflight algorithms. Can the capability to run two instances of the flight control system, along with a transitional mixer between them, be added? That would make implementing a vtol aircraft very easy, and would be a great addition to dRonin in my opinion. As mentioned previously, I've hacked ( and that's a very appropriate description ) the OpenAeroVtol mixer functions into dRonin, and it's pretty neat way to implement vtol control for both phases of flight, and transition between them. My hack works for the simple flight modes, but it can't take advantage of all the neat features of dRonin, altitude hold, vel/pos hold, etc. I think your vision here is to make these sort additions easier.

My only concern is that as we move to more sophisticated control concepts, the developer base that can effectively work on it may shrink even further than it already is. Case in point, years ago we did a project with a dynamic inversion controller. At the time, there was only one person who fully understood it and could effectively apply changes. I go back today and look at that project, and it might as well be Greek....

Just something else to consider when weighing the costs/benefits of implementations like this.

[mlyle]

One other thing to think about besides triflight algorithms. Can the capability to run two instances of the flight control system, along with a transitional mixer between them, be added?

Things like this make me nervous because the two systems can "fight". Especially for things like matrix pseudoinverse, it's not necessarily a continuous operation-- especially as axes are added.

What I think I'd prefer is to have separate mechanisms for A) control reprojection and B) changing/blending the mixer matrix at runtime. That way, for a tiltrotor, you could pick between A) hovering with rotors pointing up, B) hovering with rotors pointing forward (pitched up) via control reprojection, C) attitude control in forward flight.. for instance. B&C using the same mixer and A&B using the same control projection.

[mlyle]

You're right, block diagrams would be helpful I think.

This is what we have now, give or take:

This is what I'd like:

[mlyle]

Initial actuator model for multirotor would be a 3 control-cycle delay (filter delays are on this order) + a lowpass filter with a time constant of like, 4ms or so. All in all, better to be optimistic and under-correct down here than to over-correct.

[mlyle]

A couple more thoughts:

For tricopters, F(S) and a portion of the inverse multiply will be replaced with a tricopter specific model.

Thought experiment to see one of the benefits: assume F(s) is unity. If an actuator clips-- say on a hexcopter, we have 3 motors that can go "right", and the leftmost one clips causing an error in yaw and roll commands. Next cycle we will request more yaw and roll, allowing the other motors to pitch in and help. Since it is just "P" control of errors it will only possible to reduce and not eliminate the error, but we will at least do something before getting feedback on gyros.

[mlyle]

@jihlein -- does the block diagram help? Does this seem sane/simple enough? I'm hoping to go to implementation soon.

[jihlein]

@mlyle,

Yes, it seems sane.

What do you have in mind for the actuator feedback?

The inverse mixer matrix, calculated on the fly, or once during setup? It could be calculated in the GCS and uploaded as a UAVO during setup to save the effort of calculating it on the target board.

[mlyle]

@jihlein-- thx

What do you have in mind for the actuator feedback?

Initially just a model for motors and a model for servos. It will serve to delay-compensate (well, undercompensate) the rate PID loop and snatch a little bit more bandwidth/gain out.

Tricopters can "switch in" real feedback to combine with the model instead of the model alone.

The inverse mixer matrix, calculated on the fly, or once during setup? It could be calculated in the GCS and uploaded as a UAVO during setup to save the effort of calculating it on the target board.

Inbetween-- at startup we'll do enough steps of the iterative-inversion process to converge. Later, if the mixer changes, we'll run a couple steps of the iteration process per actuator update, from the last solution, until converged. (And turn down the feedback gain if we're far from converged).

I want to calculate it on the target so that we can deal with mixers that change at runtime.

[mlyle]

Work underway / design discussion done