22 replies to this topic

[Crubier]

Hello there, this is my first post in the open pilot community, thank you all for being involved in this awesome and promising project !

I had been working on theoretical basis for a new kind of multi-rotor UAV configuration, which doesn't enter in any "standard" multi-rotor category.
I'm really glad to realise that the open pilot project will allow me to make my ides come true !

I would enjoy some advice from developers who know about the architecture of the flight control software :

Which is the best way for me to develop the flight control software of this new UAV configuration ?
I know the modular architecture of open pilot will allow me to only code the specific parts of the software, and that is an extremely positive aspect of open pilot, to my point of view.

The specificities of this configuration are the following :
- Need for 4 Motor controller outputs and 4 servos output (I think it won't be difficult to deal with)
- Need of an independence between Attitude control and Velocity control (This may need for major modifications of the software... Because as opposed to a classical quadrotor, the acceleration of the UAV won't depend on its attitude... basically the UAV will have 6 DOF, attitude and speed will be totally decorrelated)

Thank you in advance for your help !

Edited by Crubier, 30 November 2011 - 08:23 PM.

[Kenn Sebesta]

Ca dépend. 99% of the time, it works just by using the custom mixer. Why don't you describe your idea a little more?

[Crubier]

Kenn Sebesta, on 30 November 2011 - 08:12 PM, said:

Ca dépend. 99% of the time, it works just by using the custom mixer. Why don't you describe your idea a little more?

Sorry, I mistakenly posted my post before I could finish writing it. I think my post now answers your question.
And the thing is, after having checked the GCS software, I am now pretty sure that my configuration need more than just a custom mix (i.e. I am in the 1% :-) )
That is the whole point of my post.

Thank you for being that reactive, I really appreciate your help.

Edited by Crubier, 30 November 2011 - 08:28 PM.

[Kenn Sebesta]

Wow, so many questions about canonical quadcopters these days. Basically, your problem boils down to A u = x, where u are the model inputs and x is the second derivative of the absolute orientation and position state vector. If you can find the pseudoinverse of A, A+, then you can write u = A+ x, where for any arbitrary x you can find the necessary u to drive the system. Since you have 6 outputs here, you'll need at least six motors for arbitrary control. Once you find your matrix A, you can try to understand how your motor positions and spin directions can contribute such that the A matrix is at least of rank 6.

No, coptercontrol does not support this right now. Interested in adding it?

EDIT: Sorry not 6 motors, six "actuators". Got a little carried away.

Edited by Kenn Sebesta, 30 November 2011 - 09:00 PM.

[peabody124]

I'm gonna take a leap and guess what you're doing which is 4 motors for attitude plus servos for thrust vectoring.  So you now have your 6 dof coming in: throttle, roll, pitch, yaw, forward, sideways.

I've talked to two people recently working on things like this and it's a pretty simple extension: allow accessory0,1 to come into the mixer as separate columns and you're basically done - just grab them from the transmitter. If your mapping from inputs to outputs becomes non-linear you'll need a bit of glue logic and I'd need to see what the equations look like to make better suggestions.

[Crubier]

You're both right !
Let me explain more in depth the project :
After having the idea of such a Multicopter in late 2006, I've been making a student project about this configuration in 2007.
The project was about making a MatLab, SimuLink, SimMechanics simulation of the following configuration  :
3 Rotor UAV with a thrust vectoring capability (Basically arm tilt capability for each of the 3 arms)

We proved that this configuration allows for 6DOF dynamics, and we characterized the aspect of the flight domain, depending on Thrust/Mass ratio and arms tilt amplitude.
Basically, the problem is non linear, but with a few transformations, we get a rank 6 transfer Matrix (A).
Our modelisation took into account problems such as Gyroscopic effects, Propeller torque and so on.
So, basically, I already have the stabilization algorithm.

Since 2007, I've been thinking a lot about this project, but didn't have time to actually make it real, and the available autopilots and IMU didn't really allow to easily test the idea.
After thinking about it some more, I somehow figured that for a first test, a quadrotor configuration with thrust vectoring would be better.
This adds 2 DOF for the input vector, so the transfer matrix isn't trivial anymore, but there's a single optimal solution for each input, minimizing the energy needed to perform the intended movements. The 4 Rotor configuration adds symmetry to the equations and is more fail-safe.

After discovering the open pilot project, I realized that it makes this idea Highly feasible, we just need some code.

I am interested in realizing it. I just need a kickstart to get into the project and be able to code the flight control software.

Edited by Crubier, 30 November 2011 - 09:23 PM.

[Crubier]

Kenn Sebesta, on 30 November 2011 - 08:54 PM, said:

Wow, so many questions about canonical quadcopters these days

Kenn,

I don't know precisely what you mean by canonical quadcopter.
Obviously it's about controlling and stabilizing quadcopters in a smarter way.
Is it about controlling in closed loop not only pitch yaw roll and thrust, but also other parameters such as air velocity ?

Kenn Sebesta, on 30 November 2011 - 08:54 PM, said:

No, coptercontrol does not support this right now. Interested in adding it?

I am indeed really interested in developing this kind of thing. I got an eye on the code today, it doesn't seem infeasible to me.
It will need work of course, but I think I'm going to give it a try.

What I need to know is how to get started.
- Should I start making a more general flight control Module ?
- Should I try defining other UAVObject s representing the data I need to use ?
- I should probably begin by doing something else ... you tell me.

Anyway, in a long term, my project make me think that it would be a good thing to :
- Allow more general aircraft configurations by making a more general flight control module, not only based on attitude, but also on other variables.
- Modify slightly the GCS airframe configuration section, as said peabody, to allow a more general parameter tuning for exotic configurations.

Thank you all for your help.

Edited by Crubier, 30 November 2011 - 10:09 PM.

[Kenn Sebesta]

Crubier, on 30 November 2011 - 10:02 PM, said:

I don't know precisely what you mean by canonical quadcopter.
Obviously it's about controlling and stabilizing quadcopters in a smarter way.
Is it about controlling in closed loop not only pitch yaw roll and thrust, but also other parameters such as air velocity ?

No, nothing so crazy. It's just the idea that if you want a multirotor to fly, you have to be able to find a degenerate quadcopter within the existing configuration of motors. If you can't do that, then you can't fly with all axes decoupled.

Crubier, on 30 November 2011 - 10:02 PM, said:

What I need to know is how to get started.
- Should I start making a more general flight control Module ?
- Should I try defining other UAVObject s representing the data I need to use ?
- I should probably begin by doing something else ... you tell me.

peabody124 will certainly chime in, but one of the big stumbling blocks to trying new controllers is that the firmware is programmed in such a way that there is no easy way to swap out different controllers. For instance, what would be really nice is

if (controller==PID){
   outputs=cntrl_PID(state, setpoint, gains);
}
else if (controller == LQR){
   outputs=cntrl_LQR(state, setpoint, Q, R);
}
else if (controller == GEOMETRIC_CONTROL){
   outputs=cntrl_GEOM(state, trajectory, gains);
}

and then you could just add in an additional `else if` for your new controller. If you can master this, then you open the door to changing your controller mid-flight, in order to compare and contrast different approaches.

The reason this is difficult today is because the hardware commands are not uniformly abstracted out from the software.

Crubier, on 30 November 2011 - 10:02 PM, said:

Anyway, in a long term, my project make me think that it would be a good thing to :
- Allow more general aircraft configurations by making a more general flight control module, not only based on attitude, but also on other variables.
- Modify slightly the GCS airframe configuration section, as said peabody, to allow a more general parameter tuning for exotic configurations.

The first of these two goals is certainly fulfilled by abstracting out the control from the hardware. In order for the second to see widespread use, it will have to be through loadable plugins. There is a great emphasis on keeping the GCS simple so that it's not a bewildering array of buttons (a click-o-rama, as my former PhD director called it), so exotic airframes might be best seen as plugins put on a webpage for download into GCS.

[Aerhead]

Crubier, on 30 November 2011 - 10:02 PM, said:

Kenn,

I don't know precisely what you mean by canonical quadcopter.
Obviously it's about controlling and stabilizing quadcopters in a smarter way.
Is it about controlling in closed loop not only pitch yaw roll and thrust, but also other parameters such as air velocity ?



I am indeed really interested in developing this kind of thing. I got an eye on the code today, it doesn't seem infeasible to me.
It will need work of course, but I think I'm going to give it a try.

What I need to know is how to get started.
- Should I start making a more general flight control Module ?
- Should I try defining other UAVObject s representing the data I need to use ?
- I should probably begin by doing something else ... you tell me.

Anyway, in a long term, my project make me think that it would be a good thing to :
- Allow more general aircraft configurations by making a more general flight control module, not only based on attitude, but also on other variables.
- Modify slightly the GCS airframe configuration section, as said peabody, to allow a more general parameter tuning for exotic configurations.

Thank you all for your help.

This was my way of getting something similar flying.



larry

[Crubier]

Aerhead, on 01 December 2011 - 08:47 PM, said:

This was my way of getting something similar flying.

larry

Excellent ! Your UAV is really interesting !

You are right, your configuration has many common points with the one I would like to try.
The most obvious common point is the fact that it can get some roll without any acceleration, and get acceleration without any roll.

Since I'm really interested, I have some questions for you :
- What was your input device ? You have 6 DOF, how did you map them to a controller ? Or did you lock 2 DOF like roll and pitch ?
- How did you setup the flight control software ? I think that the linearity of your configuration allowed you to only use a custom mix, am I right ?
- What was the conclusion of your tests ? Did this configuration have advantages over more classical configurations ?

Thank you

[Aerhead]

Crubier, on 01 December 2011 - 09:31 PM, said:

Excellent ! Your UAV is really interesting !

You are right, your configuration has many common points with the one I would like to try.
The most obvious common point is the fact that it can get some roll without any acceleration, and get acceleration without any roll.

Since I'm really interested, I have some questions for you :
- What was your input device ? You have 6 DOF, how did you map them to a controller ? Or did you lock 2 DOF like roll and pitch ?
- How did you setup the flight control software ? I think that the linearity of your configuration allowed you to only use a custom mix, am I right ?
- What was the conclusion of your tests ? Did this configuration have advantages over more classical configurations ?

Thank you

I'm a farmer who likes to build things and I thought this would be fun.  It took two days to build it and it flew flat the first time I tried it.  It has standard CC firmware and the same setting I used for a quad.  The magic is the Tx mix.  

It took a lot of time to think of a simple way to get this effect.  When this octo flies flat the watts it takes are around 20% more than if all the motors are vertical.  The motors are tilted 40 degrees and this thing  gets moving so quickly you have to be careful because without tilting you don't get a sense of how fast it's accelerating.

I use the two pots to adjust the attitude and the joy stick to move.  The motors are turnigy 3630s with 1400kv.  They will take up to 32 amps to turn the 10x4.5 EPP props.  I'm using some four year old 2p4s A123 batteries, they only last 6 minutes.  I need more AH battery.

I think the reason it's so stable is that most of the thrust air blows out from under the craft and doesn't build a pressure bubble under a craft.  It's fun to fly and needs better batteries.

Edited by Aerhead, 02 December 2011 - 05:39 AM.

[RoyLB]

Here is my unsolicited $0.02:

If we confine ourselves to rigid body control (seems appropriate for OpenPilot), then all actuators should produce forces (magnitude and/or direction) and/or torques. This implies that the generic "mixer" module should accept body axis force and moment vectors as inputs and produce servo commands as outputs (for maximum flexibility, it could have custom auxillary inputs for flaps, thrust vectoring, etc.).

The compensation module would then take as inputs the commanded and sensed state variables (airspeed, roll angle, etc) and output the force / torque vector for use in the mixer. Many typical flying vehicles will just have one force axis populated (the body X force in the fixed wing, and body Z force for VTOL). Of course, you could subdivide this module further into an inner loop (controlling for example body axis orientations and/or angular rates) and an outer one (e.g. inertially referenced variables such as position and groundspeed).

The main thing is that it wouldn't matter what control scheme you used - PID, LQR, sliding modes, etc - they could all work in this abstraction layer. In fact, you should be able to just drop your MATLAB code into this format pretty easily. The rest of the system should not care what you do here (other than allowing you to change the gains manually from the groundstation). For pure experimentation, it doesn't matter how you switch between control schemes, as long as the operator is careful. For any production mode transitions, you'd have to take care to avoid discontinuities in the states.

If you wanted to get really crazy, you could use a properly modular architecture to build (that is, link pre-compiled modules) a custom OP firmware via the groundstation that only contains code necessary for your vehicle. This may be too "click-o-rama", however

Does the current architecture still resemble this:
http://wiki.openpilo...tecture-Modules

- Roy

[peabody124]

Basically that could be done quite easily now.  Create a new directory in Stabilization (since that is where the controller runs), call it
Stabilization/lrq/stabilization.c
then basically make it read in whatever inputs you want to inform the outputs, run some math, and spit out actuatorDesired.

[Crubier]

Thank you for your answers, I think i can see more clearly what i have to do now.

I though it would be a good idea to know the architecture of the flight control (In terms of interconnexion of Modules through UAVObjects) before trying to develop anything.
However, I could not find any model (in any form, UML, Image) of the architecture in the repositories.
I think it is because the architecture hasn't been modeled formally, it is in the brain of developpers and in source code.

The thing which is the closest to what I'm thinking about is the architecture diagram Roy talked about :

Quote

Does the current architecture still resemble this:
http://wiki.openpilo...tecture-Modules

That's why I am now in the process of modelling this architecture, by reverse engineering from the source code.
This will allow a faster understanding of the system for newcomers, and a better maintainability of the code, since the model is some sort of documentation.
Furthermore, it will allow me to know exactly what I have to do in order to fullfill my goal.

I will get you up to date when I will have results with this, and here is my first question :
- Where should I put my results in order to share them ? On the wiki ? On a git repository ?

My second question is a bit more technical, but should be easy to answer for those who know :
- As far as I know (Git "Main" Branch source code) It seems to me that accelerometer data is not used at all. Am I Right ?
- Does someone use this data, or at least has a Module which extracts it and make it available via an UAVObject ?
EDIT : Ok I found that the Accelerations in the UAVObject attituderaw ... Quite a misleading name for something that contains all the INS data isn't it...

To conclude, I'd like to say that it is important that Modules have comments explaining their Input and Output UAVObjects.
Attitude Module is a good example, thanks to these lines in the head comments in Attitude.c :

//Input objects: None, takes sensor data via pios
//Output objects: @ref AttitudeRaw @ref AttitudeActual

Thank you very much for your help everybody !

Edited by Crubier, 07 December 2011 - 02:42 PM.

[Crubier]

Hey, I have another little question related to the architecture :
- The Actuator Module outputs UAVObjects called actuatorcommand. Does any module use it yet, or is it here just in case someone need them ?

[Crubier]

peabody124, on 07 December 2011 - 01:01 AM, said:

Basically that could be done quite easily now.  Create a new directory in Stabilization (since that is where the controller runs), call it
Stabilization/lrq/stabilization.c
then basically make it read in whatever inputs you want to inform the outputs, run some math, and spit out actuatorDesired.

Ok, as you say, I think it should be quite easy for me to implement that now. I think i will give it a try as you said.
Since my UAV will have 8 actuators (4 motors + 4 servos) only for flight control, I think that I will also need to modify the Actuator Module.
Or at least use some accessories/ camera stabilization outputs to control some servos.

Furthermore, I would like to be able to pilot the UAV in a streamlined manner.
I know I can make the UAV work only by modifying a few parts of the code.
But, without touching the architecture, I'll have to use "improper" ways to control the UAV (Using camera control to control the UAV speed or attitude etc...)

That's why I think that I should try to modify the flight architecture so that it would be more flexible and expandable.

Here is an overview I just made to compare the current architecture and the architecture I would like to implement.

Current Architecture :




The more general architecture that I would like to use (New modules in pink, modified modules in blue)



I would like some feedback about this architecture, which problems could I have when trying to implement it and run it ?

Thank you, everybody, and tell me if you're interested in this development

[peabody124]

No that new layout is a much more accurate representation of what happens on revo and also on the beta pro.  That new module in pink is essentially attitude/AHRSComms.

However, ManualControl is not well represented and this is where it gets a bit complicated because of the flight switch mode.  It outputs (currently) StabilizationDesired which carries some meta data about what it's information means.  Stabilization Desired is consumed by EITHER Stabilization or Actuator depending on flight mode = manual versus stabilization.  In addition in other flight modes it writes to different objects - such a position desired or velocity desired for velocity hold mode.  I think some of that later code got dropped in a reorg for CC.

As for controlling 4+4 - whether you need to extend actuator depends on whether those 8 outputs can be represented as a linear transformation of four inputs (more strictly speaking a linear transformation of 5 inputs, 3 of which you feed in directly and two which are throttle through a piecewise linear non-linearity)

[Crubier]

peabody124, on 07 December 2011 - 05:05 PM, said:

No that new layout is a much more accurate representation of what happens on revo and also on the beta pro.  That new module in pink is essentially attitude/AHRSComms.

However, ManualControl is not well represented and this is where it gets a bit complicated because of the flight switch mode.  It outputs (currently) StabilizationDesired which carries some meta data about what it's information means.  Stabilization Desired is consumed by EITHER Stabilization or Actuator depending on flight mode = manual versus stabilization.  In addition in other flight modes it writes to different objects - such a position desired or velocity desired for velocity hold mode.  I think some of that later code got dropped in a reorg for CC.

Ok, I think I should try to develop my stuff starting from the Revo or Beta Pro, which seems more adapted to my needs.
That's why I would like to know where are the sources of the Revo an Beta Pro version ? Is it the "Next" branch ? There's also a branch called "James/revo" ?
If I have the sources of revo or beta pro, I'll try to model it the same way I just did, In order to find what I need to do.

By the way, if anybody is willing to use my quick "models", in order to share his knowledge about Revo architecture, I made the SVG of my images available here :
http://progress.open...rchitecture.svg
http://progress.open...rchitecture.svg
They are modifiable with inkscape or any other vector image edition program. Please share if you have a model of the Revo architecture

peabody124, on 07 December 2011 - 05:05 PM, said:

As for controlling 4+4 - whether you need to extend actuator depends on whether those 8 outputs can be represented as a linear transformation of four inputs (more strictly speaking a linear transformation of 5 inputs, 3 of which you feed in directly and two which are throttle through a piecewise linear non-linearity)

Those 8 outputs can not be represented as a linear transformation of four inputs, that's why I believe I have to modify the Actuator module.
To be more precise, I have 8 outputs, and each output is the non-linear result of a calculation involving 6 inputs.
The transformation is not that complex, but it is in no way linear (at least in the flight domain I would like to "explore").

Thank you for your help :-), for now I just need to access the Revo or Beta Pro sources.

[peabody124]

Crubier, on 07 December 2011 - 07:28 PM, said:

There's also a branch called "James/revo" ?

That's the one.

Quote

Those 8 outputs can not be represented as a linear transformation of four inputs, that's why I believe I have to modify the Actuator module.
To be more precise, I have 8 outputs, and each output is the non-linear result of a calculation involving 6 inputs.
The transformation is not that complex, but it is in no way linear (at least in the flight domain I would like to "explore").

Gotcha - then you will definitely need a separate actuator.

Edit: I forgot to commend on your question of ActuatorCommand - that is not consumed by any modules but is used for monitoring at the GCS side.

[Dado]

edit

Edited by Dadorcp, 14 December 2011 - 09:33 AM.