How to control motors manually in MultiWii? (for hovercraft)


I have a lot of AlienWii Classic FCs sitting dormant because I mainly fly Whoop frames these days.
But… I expect a box of Whoov foam kits in the next few weeks, so I want to build a bunch of hovercrafts with these FCs.
I need direct control over the 4 motor outputs. No gyro, no accelerometer, no mixing, just straight forward control on all 4 channels.
Eventually, I want to use one knob to control the two horizontal props, and then a mix on the Tx to control the two vertical props with one gimbal.

I have experimented with #define FLYING_WING and #define AIRPLANE, but I only could get direct control over 1-2 channels.

Anyone of you guys firm enough in MultiWii to help me getting this working?
For significant contribution to a solution, Im offering Classic Aliens as bounty!


Why no gyro @Benedikt? I forked silverware to create “whooverware” and did extensive testing trying different axis of stabilization. I settled on gyro/pid control of yaw mixed with throttle on push motors and a seperate throttle for lift motors. It works great. I connected the seperate lift motor throttle to the pitch stick so that it can be actively adjusted while cruising and that makes a HUGE difference in control. Killing lift is like brakes, but reducing just a little lift will cause it to maintain a more forward line (exit a drift). Increasing lift will extend the drift into a wider turn if you initiated a turn that’s too tight.

Anyway, I’d be happy to look at the code for you but unfortunately will not be able to test the edits since I don’t have any multiwii stuff. But I’m not sure I understand what you’re going for with no stabilization at all. It’s very much needed on yaw to whoov. If it’s something you still want to persue - let me know and I’ll buy a board and build a whoov for it.


Hey Travis, thanks a lot for joining in!

Im not convinced at this stage that I dont need yaw stabilization.
I want to start from a clean slate and then add stabilization.
A big part of the fun for me is to start from scratch.

I have some pieces of MultiWii code that allow dynamic control of PIDs, and it my experience with wheel-based drifting, there is not one yaw gain that allows godo control in all maneuvers.
If you want to go straight or maintain a drift angle, high gain is good. But if you want to crank it through a hairpin or do donuts, a high yaw gain will hinder that.
Not sure how this applies to hovercrafts, but we will see.

I can also imagine that some stabilization on the lift motor can make sense to keep the craft level.

So getting rid of everything else is just the beginning :wink:

If you want to spend some time on this, happy to send you a board!


Cool, start me off with a link to where I find the code if you don’t mind or have one handy. I never looked into multiwii before. I cut my teeth on Baseflight and open pilot. Lol. After reviewing the code … I should know if I can pull it off. I don’t see why I wouldn’t be able to, but it seems responsible to at least take a look first before we proceed. I’m excited! New life for old stuff - I love that idea!!!


Great, please download the code here!
You will need Arduino IDE to compile.


Hey @NotFastEnuf,
I got a box of Whoov kits yesterday…

Need to get on with this :wink:
I tried plugging or sorts of values into the output.cpp, but its doing all sorts of weird stuff that I dont understand.
It seems like I should just be able to map the RCCommands to the motor[x] outputs, but it certainly does not what it should. There is some more stuff going on.
If you look at the defines for fixed_wing and airplane, they do some servo[x] allocation, and there is also PASSTHRU_MODE. When I enable FIXED_WING and PASS_THRU, I get somewhat direct access over the two wing servos in the GUI, but this doesnt trigger the motors.

Are you keen on spending some time here?
Happy to send you an FC from our US Warehouse, and for further motivation a Whoov kit from AU :slight_smile:


I saw your video. Very nice. I have plenty of whoov material here … no need to buy me off. :wink:
I must have missed where you posted the link for the code before. Sorry about that. I’ll get right on it and have a look! @Benedikt thanks for the reminder!


@Benedikt are you running OS X High Sierra with multiwii gui working? I’ve updated my Sierra to High Sierra and can’t get a fix for the gui not opening. I get an open window with no content or menu options. I’d have a look at getting what you were after if I could solve this problem.
I run a Betaflight hovercraft fork in my Whoov so can look at what’s changed to get lift and thrust separated.


I stayed on El Capitan for my coding/typing machine :open_mouth:
But I have updated a few other machines to High Sierra, and just tried it on one.
Yes, same result: window opens but its grey/empty.
I assume its some security issue with the legacy Java SDK… You probably need to press a button way down in MacOS somewhere to allow it to run, but I havent spent time yet to find out.


If you hear of a solution let me know :stuck_out_tongue_winking_eye:
If I find one, I’ll share. It will be security related but where? Haha, the fun of updates.


Not wanting to bribe you, just providing the tools if needed :wink:
Do you have a MultiWii FC?

I have done the “reboot, Command-R, csrutil disable”, but that didnt help…


OK, I’ve had a look at the code and found the “sweet spot” where I can shove in some new instructions. I am a bit confused on what exactly you are imagining though. Probably because I wrote my own custom code for silverware to whoov - so help me get past my own preconceptions of what works best by answering a few questions:

Essentially I need to tell each of the motors what to listen to individually.
You mentioned that you want one knob to control the speed of the lift motors. So thats gonna be motor numbers 2 and 3. I can tell those two motors to listen to the pitch channel. I assume you could then map your pitch channel output to a knob from within your TX if that’s what you’d like. (I actually very actively control and adjust my lift motor speed on the go with the pitch stick and use everything from full lift speed to extend out a drift to no lift to slam on the brakes. I treat it like a clutch in a car. Its quite fun that way - and it really helps generate precise control - but enough about me :wink: … you can set it on a knob too.)

Now … net that leaves motors 0 and 1 … the back motors. You want those motors to be linked to throttle and yaw stick … but no yaw pid correct?

Last question… since I am not familiar with multiwii … do we need some sort of arm switch so that the lift motors don’t come on right away?

Also is this the fc you are planning to use with this code?


My initial plan is to have all 4 motors react directly to one channel.
If a simple knob or maybe even a single fixed value is enough for the lift motors - I dont know yet.
That can all be handled later in Tx mixing, I can think about that when its working.

Two vertical motors - I can imagine that some yaw stabilization can help controlling drift angles.
It could also be a fun challenge (or provide more radical control) when they are controlled directly, just like in an old-school differential-thrust flying wing.
So for simplicity reasons, I thought we just map them directly first. And then when its (somewhat) working, decide if yaw stabilization is necessary, and either add that permanently or make it a selectable “flight” mode.

Im open to ideas :wink:

P.S. yes MultiWii usually does stick or switch arming, just like BF. Wouldnt hurt to have that on the Whoov too.
And yes that exactly the FC. I have a lot of them left :wink:


Do you mean each motor to one individual channel … or all 4 linked to throttle equally for example with the addition of yaw to just the back two?

I’m glad to hear it! As am I. I think you will find it near impossible to whoov without yaw pid stabalization. A plane with differential thrust at least has a rudder which serves the same purpose of stabalizing the yaw axis - whoovers don’t have a rudder and will definitely require the pid to keep it out of a Tasmanian devil spin.

My silverware version “whooverware” has lift motors mapped to the pitch stick as a lift throttle… and push motors mapped to throttle and yaw pid. I tested everything just as you want to before I decided on this simple but effective configuration - so I definitely support and understand your desire to test as well. I could probably create this setup much faster in code just to get you up and whooving and then we could continue to work on the full test bed for your exploration. That would also get my feet wet so to speak. Either way I am in till we get it where you want it … or till someone who knows multiwii better than I do steps in. LOL

As for the FC… OK I will let you send me one of those. I didn’t expect that price tag. Hehe. That is unfortunately not in my hobby budget currently. I have plenty of hot wire cut empty whoovs of my own design and a whoov kit already on the way thanks to the generosity of another one of our forum members. Plenty of motors laying around too. How do we arrange that?


Individually would be just fine. Happy to do the mixing on the Tx.

But I get what you are saying. It might be a lot easier to have the yaw stabilised.
I will let you do it how you think it works best and complain later :wink:

More than happy to send you an FC. It needs a LemonRx DSM satellite receiver.
You got one of those floating around? If not Ill throw one in too.


Yes I have plenty. Thank you for the kind offer … just the fc will be enough.

Which channels should we use then? Just regular old 1 through 4… throttle, roll, pitch and yaw… each one going to one motor?


Alright, will get one underway to you.

Channel order really doenst matter. Whatever falls out of the keyboard :wink:


Benedict (165.3 KB)

Well I made quite a few assumptions without taking the time to verify how the code ACTUALLY works … but they were pretty safe assumptions in the world of flight controller code. Take a crack at this for starters…
There is a new multirotor type called BENEDICT in config.h. It compiles OK so it just might work. Throttle stick is mapped to one of the rear motors, yaw to the other, roll to one lift motor, and pitch to the other lift motor. There is no pid stabalization at all to start with as you requested. I selected the channels this way so that roll and pitch at center stick on your TX will be mid throttle and should whoover up nicely. As for your rear motors… start with throttle down and yaw all the way to one side (Not sure which). Both motors should be off. Then raise each one and see if you get response. If it works … I think that is the starting point you asked for.
You can see what the BENEDICT type does in the output.cpp tab. The assumption that I made was that normally rx inputs go from negative 1 to positive 1 on roll/pitch/yaw. Throttle usually goes from 0 to 1. I took (rccommand[yaw] + 1)/2 for example to remap yaw to go from 0 to 1 like throttle does - same for roll and pitch. This was an educated guess but I’d be surprised if it doesn’t work out to be the way the code is structured.

Fingers crossed… :sweat_smile:


Thanks for the quick work!
Downloaded, compiled, flashed.

Just like in my attempts, upon arming and raising the throttle, all motors spool up to 1050, and then the Rear_R reacts to further throttle input.
All three other motors stay at 1050, and all three other input channels do nothing.
Somethings missing here…


Hmm, well 1050 is probably mapped as a minimum throttle so its actually a good sign that the other motors are at the 1050 mark too. Did you try raising the throttle to somewhere in the middle and then moving the other sticks?

And after poking a bit … I was off anyway in assuming rcCommand was -1 to 1. It seems its more like -.5 to .5. So I’ll adjust that. I just wonder if there isn’t some sort of safety in place that requires throttle to be raised before it will allow the other sticks to become active. That’s not uncommon. Digging further. Progress will go faster with the board in hand. Thank you for sending it.

Ahhh…OK… I think I have it now. My previous formula for converting roll/pitch/yaw to throttle type values was wrong. I assumed we were dealing with -1 to 1 (old silverware habit) but in actuality throttle is mapped from 1000 to 2000. R/P/Y raw values were being mapped from -500 to 500 … so previous formula was returning at max stick (500 + 1)/2 which was still below min throttle even at full deflection and thus returning only min throttle I’ve changed it to simply add 1500 to the roll/pitch/yaw rcCommand now. The sticks should all be returning 1000 to 2000 just like throttle does. I also lowered min throttle setting to 1000 just on a hunch. I’d like to see the motors stop with sticks deflected all the way towards the 1000 value.

Benedikt (165.3 KB)

Try that @Benedikt and then I promise I will not bug you anymore till the board arrives and I have something I have confirmed to work. I have also corrected the typo in spelling your name wrong for the multirotor type LOL…this time it was me! HEHEHEHE