UDB VTOL Update

[Coby]

Just wanted to pass on some video of our VTOL test flights.

First one is Gemini, which is essentially a flying wing with rudder and keel (or VFO on steroids).  It's running HiMax contra's that are a bit over-propped.  Lands much better than what it shows in the video as my shakes kicked in at about 20' on that flight. 

http://youtu.be/NVvWdUJYrik

Second one is Mercury, which is essentially an aerodyne treated like a hovering airplane for UDB firmware purposes.  It's running two OS 30's.  It looks like a flying bucket right now.  Next version will probably use contras so we can make it a bit slimmer.  Still much to work out for control authority - we need more so going to start adding control vanes for more surface area etc.

http://youtu.be/qX6aUwFeo68

Overall, some good progress.  I am pretty much maxed out in my coding skills getting it this far, so working with Bill to get it back in the main trunk so more people can work on it etc.

There are some fairly crazy mixes going on with our Spektrum DX8 to make the four servos respond as required.  Otherwise it's just a flying wing with dual rudders.

Happy to help anyone who wants to build one with our lessons learned.  Hope to get the designs and details on something other than parchment paper so we can share more easily.

Enjoy!

Coby

[Riccardo Kuebler]

Hi Coby,

your progresses turns me on :)

About the transition from hovering into dynamic flying I have those proposals.
You probably have to stay with high gains for hovering, to have the plane well stabilized.
So going from hovering to dynamic flying is hard to achieve (it happens with my Acromaster that it fails, so I have to insist), while going from dynamic into hovering is more soft.

Finally the proposals :

1) mix in your RC tx (do you still have a free mixer ?) elevator with mode channel, so when you reach e.g. the 80% of stick position either part, mode switches to manual. This let you have a safe margin, because when stick are near center you regain stabilization mode. Even more elegant could be the use of a dual rate switch so in low position (intended for dynamic flying) you don't risk to enter manual mode (e.g. to enter hovering from dynamic flying).
I think I'm going to try something similar with my Acromaster, to have full authority when doing hard aerobatics.

2) have this option programmed in MatrixPilot instead of RC tx, settable in options.h as an aerobatics mode on / off. I mean when the sticks are at e.g. 80% / -80%, stabilization goes off.

3) the more elegant one : have in MatrixPilot gains proportional to stick position (always selectable and tunable in options.h as above). Would it be possible ? A big work ?
In the case it would be possible this option could be implemented proportional to plane airspeed too. This last one was discussed several times already.

Congratulations for the flights !

Best regards,

Ric

2012/5/24 Coby <cgl...@gmail.com>

[Peter Hollands]

Hi Coby,

Like Ric, I get quite a buzz out of seeing what you guys are up to. Thanks for sharing.

Best wishes, Pete

[crashmatt]

Some more proposals:

I have been flying a different linear mode mix which is good.  At stick centre the autopilot has 100% authority.  At 50% stick, both autopilot and pilot have 50% authority. At 100% stick, the autopilot has 0% authority and the pilot has full authority.  This is easy to implement and it avoids nasty maths value overflows resulting in control direction reversal.  This was copied from another mixer scheme so I can't take credit.

Doing this linear mode mix also removes the "boost" feature so that more fly-by-wire features can be implemented.

If I understand this, you want to change the control throws depending on mode.  You might say that throws are not so much related to mode as airspeed.  At high airspeed you want less control movement, commonly known as control fadeout.  This is a feature I need to prevent stalling when flying very slowly in turbulent air but still have stability when flying fast.  Airspeed control fadeout is on a long list of things to do after I get the next round of airspeed control changes committed.

Regards Matt

[Peter Hollands]

Matt,

Is the autopilot-manual mixer in the code repository ? If so could you link to it ?

Best wishes Pete

[Peter Hollands]

Matt,

I believe that the code you are talking about is in the flexifunctions branch.

e.g.  settings making use of a LINEAR_MUX in the example file for the Cularis in the flexifunctions branch.

and a linux_mux_function  here.

Best wishes, Pete

[crashmatt]

Pete,

That's correct.  

The flexifunction mixer is great for UDB4 but too memory intensive (both ram and rom) for UDB3.

Doing the linear mux as an option in the standard mixer is no problem.  I will not support this modificaiton since I am only using the flexifunciton mixer and have enough to do already.

Slightly related to this, I have the new inputCntrl.c module which standardises the RC pwm inputs to fixed scale (RMAX) and direction.  I would like to get this in trunk so that udb_pwin conditioning does not need doing all over the code. It uses a few bytes of memory so I need to isolate it for UDB3 before I publish it.  Once this is done, the linear mux will be very easy to implement.

Regards Matt

[Coby]

Thanks Gents.  First, I think the next step on my side is to move to the UDB 4.  Also, need to get the code back in trunk as the branch I used was based on 3.2.1 I believe, so it's a bit old.  

@Ric I do have a Mix remaining so will investigate your idea.  Might work.

Matt's idea for linear mode mix might work very well for the Gemini.  Not sure it works for Mercury as it needs all the stabilization it can get.  

Our thought for Gemini was to change the code so the flight modes were a bit different:

1) Stabilized Hover Mode

2) Stabilized Airplane Mode

3) Waypoint Mode

That way the UDB is not fighting pilot inputs in/out of transitions.

But I am open to whatever works best and not sure what that might be right now.

Perhaps Mercury needs to be running from the quad copter branch?  It would help if the anti-torque were handled by differential motor RPM.  We believe that control authority is negatively impacted when the control surfaces are trying to overcome torque/yaw.  From what we have seen it's very difficult to get it all out with contra motors.  It helps, but does not eliminate yaw.

R,

C

[William Premerlani]

Hi Coby,

Your VTOL test flights are very impressive, I feel guilty that I have not given you much help lately.

By copy of this to the UDB developers, I am asking for a volunteer to help Coby fold recent improvements in MatrixPilot into his code. Any volunteers?

The present version of Coby's VTOL code is based on MatrixPilot 3.2.1, with basically only two sorts of modifications:

1. Addition of an option for initialization of the UDB in a vertical attitude. (That option is now in MP trunk, as far as I know.)

2. Coby's modifications for VTOL control.

I think the main two new features in MP trunk that would be useful for VTOL are the magnetometer improvements, and the new method for accounting for acceleration. (That one especially should be useful for VTOL.)

Anyway, if there are any volunteers to help Coby, I would also be available to answer questions.

Best regards,

Bill Premerlani

[Coby]

Bill,

No worries here. I am going to be swamped the next month anyway.  It's open source and all volunteer so it gets done as the community gets to it.

Appreciate the help!

R,

C

[Coby]

Forgot to mention.  Here's the link to the github repo:

https://github.com/cglusky/MatrixPilot-VTOL/branches

Both branches are the same with exception of options.h

R,

C