Maglev: Control System 1

I screwed the thrusters to the hover racer. They were a bit too high to produce thrust, so I had to bend their mounts down until they stuck a few mm below the plane of the lift rotors (and thus 1-2mm above the aluminum when hovering).

Final assembly system weight: 1337g.

Next, I attempted to make a control system work. First thing I did was put the lift motors on one of the knob (pot) channels on my Tx (by messing with Tx mixing). This was to prevent accidental lift changes during yawing (rudder stick movement). 

The first system I tried was just yaw control (no thrusters yet). I did this by having a custom mixing .h file and adding in rcCommand[YAW] into the lift rotor's mix. I didn't want to mess with PID yet, so the flight controller was just acting like a mixing board. Yaw control works like this, but it is very sensitive. Yaw trim didn't work very well, though. I can trim out the yaw, but then two of the motors (diagonal) start spinning quite slow and the quad drifts to the rear left. In my previous maglev posts, I claim that propulsion shouldn't be possible with this configuration, so why was it translating? That got me thinking that maybe I could propel it with small pitch and roll commands. I tried adding rcommand for roll and pitch. When I tested it, I could hear the motors changing speed, but no direction changes or propulsion. Unfortunately, the pitching caused one of the rotors to contact the aluminum, which smoked it (stalling for a couple seconds = death). For some reason, the ESC didn’t register a prop strike. I'm not overpowering the motors because the other motors didn’t even get warm. Oh well... I put in the spare motor I used for single rotor testing and kept going. Lesson learned: I should add a small bead to the center of the rotors to allow them to spin relatively friction-less if they contact the surface. That would prevent motor burn outs. 

I then took the pitch and roll out, but left the yaw control. The different motor didn't change the yaw untrim or rate, so I'm guessing the yaw untrim is coming from the rotors not being completely level (because the frame is pretty flexible. ~2-5mm deflection just from weight) and the rotors not being exactly the same (they are all unequal ellipses from 3D print warping). There may not be much I can do about that. An extra motor/rotor (like the lift rotors, but smaller) could be mounted in the center under the chassis to provide trim and yaw or just trim. That would leave the lift motors completely out of the control system, which would probably be good.

Next, I tried adding in the thrusters connected through the flight controller. These proved very difficult because of the reverse functionality of the ESC's. They need to initialize to 1500us, but when you arm single direction motors (like the lift motors), you want them armed to ~900-1000 with minimum throttle around 1000. There is no “min throttle” for bidirectional because ~1000 corresponds to full reverse and ~2000 corresponds to full forward. I figured out I could modify the loops in output.cpp that set minthrottle and mincommand by limiting them to the first 4 motors, but that’s a pain. It’s much easier to just take the thrusters off the flight controller and mix the two using the Tx and the elevator and aileron channels on the Rx, so I did that. 

Link to public google drive with the final MultiWii config.h file, mixing table .h file, and pin assignments.

Now I needed a larger sheet of aluminum to test on. The FIT machine shop happened to have a 2'x4' 1/4" thick aluminum sheet! Videos below:

A few notes from the tests:

• Yaw trim is still a problem (discussed above).
• Yaw is a bit screwy. While it will obey yaw commands and turn the direction I want it to, when I bring the stick back to neutral, it will turn back some. I guess that kind of makes sense from a torque perspective, and a PID loop on yaw would help with that. If it starts spinning too fast, I lose yaw authority completely (first video). There is something weird going on that might be related to the trim problem.
• You can see the ESC registered a prop strike near the end of the first video (1 motor stopped).
• The thrusters aren’t particularly useful for changing direction. They have to stop rotating before the ESC will reverse its direction. Due to the high inertia of the rotors, this takes awhile, which allows the hover racer to drift a long ways before reverse thrusting. This makes it hard to control. Making them closer to the surface would help them brake faster, but there will still be a delay. I don't think a ducted fan on a servo would be much better because of the time it takes to rotate the servo. Anyone have any better (non-contact) propulsion ideas?
• Judging by final charge of batteries, it probably has about 4-5 minutes of flight time per charge
• Definitely need a kill switch and to add braking to the lift motors.
• The magnets got pretty scraped up: a very thin sheet of protective acrylic/polycarbonate would probably be a good idea.
• The motor bearings are starting to sound bad. They really aren't meant for spinning large unbalanced masses. Machining the rotors (plastic or aluminum) would probably have been better than 3D printing: it would have removed the warping and they would probably come out better balanced. 

Please leave your control system ideas/tips in the comments. I need suggestions on how to trim the extreme yaw imbalance and get more thrust authority. 

To do:
-Make a better control system
-Add a kill switch and braking to lift motors
-Add a bead/round head screw to centers of lift motors (see above)
-Upload (fixed) CAD to google drive