飞行：磁悬浮四轴飞行器的设计和制作分享（Maglev Hover Racer: Design and Fabrication）

Unfortunately, there is not easy way to calculate forces in this situation. After searching online for hours, I’m pretty convinced that the only way to get forces from a permanent magnet array rotating over a conducting surface is by a full transient FEM (finite element magnetics) simulation with COMSOL, maybe Maxwell, or a custom code…the free FEMM software (which I used so much in earlier brushless motor designs) doesn’t do transient. Anyways, I figured that wasn’t worth the effort, so I used my calculations, these guys‘ results, and some of my own test’s results to guide the design.

After I found some motors, ESC’s, and batteries I thought might work, I started thinking about how I was going to control it. A few hours of drawing force/moment diagrams convinced me that typical quadcopter control would not work in this case. Quadcopter’s can move forward/backward by pitching (throttling up two motors) and increasing throttle, which causes the force vectors (which are perpendicular to the plane of the propellers) to tilt, creating a component of force in the direction of motion while maintaining lift. Left/right movement is accomplished in a similar fashion by rolling and increasing throttle. Yaw is accomplished by throttling-up a diagonal pair of motors and throttling-down the other pair, which creates a torque imbalance and thus, rotation. In this case, the pitching/roll won’t work. This is because the force is not being generated by the magnet rotor, but by the magnetic fields in the conducting surface. By pitching or rolling, the magnet rotors are no long parallel to the conducting surface. This causes two problems: 1. Two rotors are now far from the plate, which means they aren’t generating lift, which is an impossible situation. 2. Two rotors now have an edge very close to the plate, which causes high drag/contact at those points (imagine what happens when a rotating disk contacts a surface…it acts like a wheel). Number 2 brought up an interesting idea…what if all four pods were gimbaled? You could pitch individual pods a small amount to make the disk edge closer to the surface at one point and the magnetic drag would create a force. But I thought that that would make control very complicated, and I’m a big fan of simpler engineering solutions are usually better, so I abandoned that idea.

While pitch and roll may not work, yaw will work the same way (drag torque imbalance) as a quadcopter. So I can steer my hover racer with yaw. But how do I move forward/backwards? One obvious way is with a ducted fan or two; that’s what the other FIT teams are using for thrust. But I came up with a cooler way. Why not take the same principle (rotating halbach array) that generates lift and make it generate thrust? By wrapping a Halbach array in a cylindrical fashion (with the magnetic field oriented out) instead of a disk fashion, lift AND thrust can be generated (instead of lift and drag as with the disk). In fact, the force vector is now 45 degrees from the conducting plane, leaning in the direction of rotation. While I won’t need the lift because I have four lift rotors, the thrust will be useful for propulsion. I decided to go with two thrust cylinders, one on either side of the CG to prevent the quadcopter from pitching due to thrust changes.

Since the thrust cylinders generate lift too, that brought up the idea that I could just use four of the thrust cylinders, one on each side of square, and ditch the lift rotors. The problem with that configuration is that lift will be coupled with thrust, which becomes a control nightmare. If motors were infinitely responsive, I might have attempted this, but I ultimately abandoned that idea. If you get this configuration working, let me know. I’d love to see a video of it.

Anyways, now I have a configuration that I believe will be controllable. 4 quadcopter-style maglev rotors for lift, and 2 cylinders for thrust. A typical 90 degree turn maneuver would go something like this: Throttle up thrust motors until approaching turn, then reverse thrust motors to brake. Yaw 90 degrees away from the turn, keeping the thrust motors in reverse to accelerate backwards. Now travel in reverse until the next turn, after which it will be moving forward again. The reason I don’t turn towards the turn is because that would require the thrust motors to change direction again (from reverse braking to forward thrusting), which takes time. Instead, it’s faster to keep the thrust motor moving the same direction.

After I had my configuration, I spent more time researching which motors, ESC’s, and batteries would be best, pulling from my many many many experiences with hobby electric motor systems. I ended up buying almost everything from Hobby King because cheap. Then I picked out a quadcopter frame, quadcopter flight controller, receiver, transmitter (because before this I had been too cheap to buy a nice one), etc. A full list of the hardware I used is below:

• SLICK 220mm Quadcopter Frame Kit (fiberglass)
• 4x NTM Prop-drive 28-26A, 1200kV short shaft brushless outrunner motors – lift
• Q Brain 4x 25A Quad ESC
• 2x C2230 brushless outrunner motors, 1780kV – for thrust
• 2x 10A Brushless Car ESCs (hobbyking brand)
• 3x Zippy flightmax 2200mAh , 2S1P LiPo packs
• Turnigy 9XR Pro transmitter
• OrangeRx 2.4GHz transmitter module
• OrangeRx 2.4GHz 6 channel receiver
• NanoWii flight controller
• Spare motors, spare batteries, charger, wires, plugs, etc. (hobbyking)
• screws, nuts, tubing, etc from McMaster
  • M3 screws and locknuts for the chassis (frame kit comes with these), thruster mount to chassis, and lift motors to chassis
  • M2.5 flat head screws for securing lift rotors to lift motors
  • M2 screws for securing thrust rotor to thrust motor
  • M2 screws and nuts for securing thrust motor to mount
  • 8978K26 tube for lift hoop rings
  • 8978K24 for thrust hoop rings
  • low carbon steel 0.06″ thick for thrust motor mounts
• 64 1/4″ cube N50 magnets from Amazon
• 48 1/2″x1/8″x1/8″ magnets from K&J Magnetics

The lift motors will be operated at 4S (~14.8V) and the thrust motors at 2S (~7.4V). By my calculations, all this should give plenty of lift, thrust and about 5 minutes of run time per charge.

The next task was to CAD (Solidworks FTW) everything. Below is a rendering of the first design. The blue boxes are the batteries, the orange box is the receiver, the little board on top is the NanoWii, the four motors/rotors on the arms are the lift motors, and the two motors/rotors mounted inboard off the main chassis are the thrusters. Both the lift and thrust rotors have a thin aluminum ring around them to prevent the 3D printed plastic rotors from exploding when rotating at ~10k RPM. The quad-ESC for the lift motors is barely visible mounted to the bottom of the chassis in the back. The thruster motor mounts are made of 1018 low-carbon sheet steel. Low-carbon steels have a high magnetic saturation point making them excellent for shielding high strength variable magnetic fields (like those coming off of the thrust rotors). This was necessary to protect the flight controller (which has to be mounted near the CG) and the ESC’s. The lift motors don’t need shielding because the vast majority of the magnetic field they emit is in the conducting surface. The only things that have changed since then are: slight geometry changes to the lift and thrust rotors, battery positioning, and replacing the slots in the thrust motor mounts with simple holes.

Typical multi-rotor flight controllers take inputs from the radio receiver (commands) and inputs from an IMU, run these through a PID controller for pitch, roll, and yaw, then send the output commands to the motors. There is a ton of info about these systems online, and hundreds of flight controllers to choose from. I chose the NanoWii from HobbyKing, which is based on the famous Arduino MultiWii code. The NanoWii, and many MultiWii flight controllers, are based on the 6axis IMU chip from the Nintendo Wii remote.

I’m not going to go into the details of how to setup a MultiWii flight controller. There’s a lot of documentation online (multiwii website, forums, other blogs, etc). At this point in the design process I was 95% sure I wouldn’t be able to use generic quadcopter control for this project (and as of this writing, I’m 100% sure because I tested it), so I needed to come up with a plan on how I would modify the MultiWii Arduino code to allow me to control the hover racer.

The initial plan was to 1. remove roll and pitch commands, leaving the PID control loops in place. 2. Keep yaw control and command the same. 3. Add in two channels for the thrusters without a control loop. 4. Adjust all PID gains and trims. As will be discussed later, this will need to modified.

Time for my favorite part: actually building it. FIT has this magical place called the Electronic Support Lab (ESL) where you can get stuff 3D printed for free (if you’re a student of course). The first thing I did was print a test lift rotor, assemble it, and mount it on an arm. The aluminum ring was cut from a tube with a hacksaw and sanded (the final versions were cut on a lathe).

I didn’t leave enough tolerance on the magnet holes or for the brushless motor can, so it required a few hours of sanding and cutting plastic to get everything to fit. I then plugged this motor into an ESC, plugged two of the 2S batteries in in series (4S total), plugged the ESC throttle cable into a receiver, put a 1/4″ aluminum plate on a scale, held the arm firmly over the plate, and throttled it up. I got to about 75% throttle before “BAM-ping-ping”. Oh shit, I just chucked a magnet at  about 100kph. The scale read about 550g right before the drag was high enough to pull out the magnet. I found it stuck to the bottom of a drill press and stupidly put it back in and tried again. Same result, except this time it punched a whole in a cardboard box and disappeared (I found it a week later stuck under a desk). Oops. Gonna need to glue the magnets in the real ones.

So, now I know each rotor can generate at least 500g of lift at full throttle. Since my final estimated mass was about 1500g, I felt confident at this point that my hover racer would actually hover.

Unfortunately, I don’t have an optical tacometer in lab, so I couldn’t measure RPM. I would really like to do a full study on these. If I could, I would use an optical tac to measure RPM, a load cell to measure lift, a torque sensor for torque, a volt and ammeter for power, and then vary distance to the conducting surface. I’d be able to calculate some useful force and torque coefficients from that data. However, I just don’t have the time at the moment…maybe one day.

After those tests, I modified the CAD file of the lift rotors and requested four to be 3D printed. While that was happening, I test-assembled a prototype thrust cylinder. Unfortunately, the walls were just too thin and the magnet forces collapsed it (3 hours wasted…ugh).

I modified the design to be larger, added 4 more magnets to the array (24 total now), ordered large tube from McMaster, and tried again. This time I almost left enough tolerance on the width of the magnet holes: I had to mill out a couple of them by chucking an endmill in the drill press and running it though the slots by hand.

The lift rotors were built next. Again, I didn’t leave enough tolerance on the motor can diameter, so I had to hand-mill (my term for drillpress endmill hand holding the part) a few mills of plastic off the diameter. I got the magnet holes about right this time, though. I also had to use a razor blade to clean up some of the plastic…3D printers aren’t exactly the most accurate machines. I then went magnet by magnet, (somewhat carefully) hammering them in. AFTER I checked to make sure all of their orientations were correct, I super glued them in.

Rings on. These rings were cut on a lathe.

Various tabs/notches/holes for interfacing with motor can. The outer set of holes are for pushing out magnets that I set wrong.

Placing magnets

I then had to make the thrust motor mounts. As mentioned earlier, these are made out of low carbon steel sheet. I designed them using Solidwork’s sheet metal tools, which allowed me to “unfold” them and print out a template. I taped the template to the metal sheet, punched all the hole locations, drilled all of the holes, deburred all of the holes, and then band-sawed them apart. I then used a vice, a plastic mallet, and a protractor to bend them.

The little ones mount underneath the chassis as lower magnetic flux guards.

I turned the lift rotor rings that day, too.

They came out surprisingly accurate. I didn’t have to do any hole corrections. I then followed a similar process for putting holes in the chassis.

As you can see in the bottom pic, it didn’t turn out as well. I had to hand-mill some of the holes into slots. Oh well, it works.

Next, I assembled the quadcopter frame, zip tied/screwed/taped things to it, and (drumroll please)…

I coiled the long ESC wires instead of cutting them because I want to use this ESC for a real quadcopter build one day.

NanoWii partially connected.

Receiver-ESC connections (no flight controller).

I first tried it with the flight controller setup in quadcopter mode. I calibrated everything, had all the right settings, blah blah blah… Like I guessed, it didn’t work at all. The dynamics are completely different from a quadcopter. So I took the flight controller out and plugged the ESC’s directly into the receiver. No thrust motors at this point, I simply wanted to get it hovering.

It worked!! It has probably 1kg of extra lift at full throttle. It hovers about 5mm from the surface. Due to slight differences in the motors/rotors, there is a small net torque in the clockwise direction that causes it to want to spin, but I should have no problem trimming that out when I bring the flight controller in the loop. Also, the plate in the video is a lot thicker than necessary (but it’s what we had in lab). Assuming my skin depth calculations are correct, I should see negligible change in lift on a 1/4″ plate.

 Maglev Hover Racer – YouTube

I managed to make the rotors similar enough to not need trim for pitch or roll. In fact, the thing is so stable that I don’t think I’ll even need a control loop for pitch and roll. Yaw will need to be trimmed, but it may not need a control loop either. In fact, I’m not even sure a real controller is necessary. You could probably get away with a fancy transmitter and/or channel mixer. I’m going to stick with the flight controller for now, though.

To-do List:

• Software modifications
  • Take out pitch and roll command and control
  • Add in thruster command (could drive directly from Rx with a signal splitter)
  • Put lift throttle on a transmitter knob
  • Put thrust throttle on pitch stick
• Obtain a large sheet of aluminum
• Lots of testing
• Finish everything by Dec. 16th
• upload CAD files, code, etc. to my public google drive

Yeah…I’m not sure I’ll make that deadline. I have finals next week that I need to study for. We’ll see!

---

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:

(684) Maglev Control Test Session 1 – YouTube

(684) Maglev Hover Racer with control: Test1 – YouTube

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

---

Maglev Mark1 CAD upload

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:

(681) Maglev Hover Racer with control: Test1 – YouTube

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