Thruster Control System, Picking a Solution out of a Set of Possible Solutions

[BlackFang]

I am trying to write a thruster control system that manages an array of custom thruster structs. Each thruster has a location, orientation, maximum thrust, throttle and a range of gimbal for its Y Axis and Z Axis, etc. Given a supplied vector representing the desired direction of acceleration, the control system should adjust the gimbals and throttle within their possible ranges, in an attempt to match the desired direction.

Example, a pair of thrusters opposingly angled at 45 degrees from center would gimbal towards each other and cancel their remaining side to side components of their thrust vector to give a forward acceleration. (However, I cannot really on thrusters to be arranged in opposing pairs. It is very important that this system works with any number of thrusters in any arrangement/)

Essentially, the nomralized sum of the thrust from the individual thrusters needs to equal the desired direction of acceleration. However, this is complicated by the fact that the system needs to work with any number of thrusters. There are also many possible combinations that could satisfy the requirement of thrust being in the correct direction (or none, in which case I want the closest). Secondary criteria would be maximum total thrust, and least torque generated.

I know the physics for calculating thrust, acceleration, torque, etc. So that isn't a problem. However, I don't have much experience setting up this type of algorithm.

Representing the two axis of gimbal, and the throttle, as possible ranges of continous values means there is a nearly infinite number of solutions to check.

An idea I have is to limit the gimbal and throttle of a thruster to ten or twenty discrete increments, rather than the continous range. I would check combinations at random, and assign each a desirableness score, adopting any new combination with a higher score. (I really don't like doing things randomly if it can be avoided.)

The solution also needs to be fast enough to run each frame of a simulation.

Is there a smarter way to do this?

This is a bit outside of the types of problems I normally tackle, so I haven't made much headway with research. If you know terms I should be searching for, or anything at all that can help, please share.

Thank you very much.

[OReubens]

if you need a system that can handle any number of thrusters in any configuration (and gimballing the thrusters makes this a lot harder) that isn't necessarily a problem. the idea is that you figure out the center of mass and calculate the relative lengh and angle of each thruster around that center.


If a thruster can be removed at any point in time, again, not really a problem set thrust to 0 and recalculate so the others take over. This may no longer be possible if the center of mass now falls outside of the bounds of all thrusters, or if it's so close to the bounds that the thrusters near the center of mass runnign at max power and the others at whatever to keep the unit level no longer has enough lift.

Adding thrusters, again, no problem if you assumed they were there in the first place and now fire it up from 0 thrust to X. even doing this dynamic isn't a problem.

however if you want to dynamically alter the configuration that'll alter the center of mass, that becomes a lot more difficult. or rather, more difficult to do in any reasonable amount of time that you can actually keep the thing flying.


multicopters don't bother with all that. they have accelerometers and gyro's. and simply continuously add/reduce thrust to compensate the measured changes, and have feedbackloops to increase/decrease the compensation over time. The software does need to know about the rough configuration though. THe flightsoftware of a tricoptor doesn't work for a quadcopter, and a quad needs something different than a a 6 (or more) multicopter. multicopters typically all end up using the same kind of software.
note that that software does make some rough assumptions such as that the left and right thrusters are the same distance from the center. and a similar assumption for front and back (except for tricopters that have a pivoting rear thruster).


thrustvectoring shouldn't really be all that much of a problem that's just a matter of deconstructing the forces.
recalculating the center of mass is a much more prohibitive problem. but that goes beyond just the thrusters, you need to know about how much mass was added somewhere to give it an extra thruster somewhere.