Search This Blog

Monday, December 22, 2014


I got around to sanding the fins. I started by marking a line for the ~10 degree bevel on both sides and a line down the center of the edges I was going to bevel. The real Phoenix has a bigger bevel on the leading edges, but I decided against that for convenience. I attempted to use a palm sander first, but realized that it would take way too long that way. I then tried to use a hand plane. That mostly worked, but it took a long time and the plywood tended to rip instead of slice off nicely. I finally decided to try the vertical belt sander. I didn't want to use one originally because one slip up and the fin is ruined, but it ended up working out. I finished them with a sanding block. I ended up sanding the LE of the tab of the rear fins because there wasn't a good way to avoid that on the belt sander; I didn't do the finish sanding on the tabs of course.

They didn't come out perfect, but good enough. Total time sanding was probably about 10 hours. I can't wait until I have a shop with a CNC router. That would have made this so much easier.

Since the last post, I also purchased centering rings, bulkhead plates, giant rail buttons, and a nose cone from Wildman. I hope I can get this done by mid-January, but it may not happen. Next semester is going to be insanely busy.

Left to do:
  • Cut motor mount tube
  • Make motor mount
  • Install fins
  • Filleting 
  • Build altimeter bay
  • Minor stuff
  • Final primer coat, sanding, then painting

Saturday, December 13, 2014

Maglev Mark1 CAD upload

The Mark1's CAD is on my public google drive now. Sorry for the odd part names; just start with the full assembly and figure out what I called what. Here's a screenshot of the final configuration:

The corrections discussed in an earlier post to the 3D printed rings/magnet holders are incorporated in those CAD models. I also made the thruster motor mount slightly long so that thrusters sit a few mm more below the plane of the lift rotors.

I also updated the hardware list in the fabrication post to include the screws and nuts you'll need.

I'll probably start work on a Mark1b over the next few weeks.

Friday, December 12, 2014

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

Saturday, December 6, 2014

Maglev Hover Racer: Design and Fabrication

Preliminary Design/Configuration:
The first thing I did was make a spreadsheet to calculate eddy current power dissipation and surface penetration. Inputs were number of magnets, magnetic ring area, RPM, neodymium magnet grade (ex N48), distance from plate, thickness of plate, temperature of plate, etc. Output was power dissipation in the plate. I also added some basic motor/battery sanity calculations. I made one a cleaned up version available here . Here are some useful links: 1 , 2 ...those guys also have pretty good deals on neodymium magnets.

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 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. 

First Rendering

Software Plan:
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.

Fabrication and Assembly:
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). 

Top center: Buckled plastic 
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. 

Using super glue this time
One almost done.
Mounted on aluminum test bracket. Black electrical tape around rotor
for temporary magnet restraint until the new larger tubing came in.
I tested the above setup on a 1/4" aluminum plate/scale. It produced  ~150g of lift, and the thrust was definitely noticeable. Since the force vector should be a 45 degree angle, the thrust should have been about 150g, too. Good, so that plan for producing thrust should work. Now I just need to take it off of the test mount and...crap. The tiny M2 screws stripped because I superglued the nuts (because I did NOT want this rotor coming off the mount during testing). I ended up drilling, milling, and hacking the screws apart until I got the motor off.

Endmill + screw = screw - screw head

cut up screws
I then finished gluing in the magnets to both rotors. Next, the aluminum tube came for the containment rings (as mentioned previously, this is to prevent catastrophic structural failure of the plastic rotors at high RPM). Damn...I didn't make the magnet holes deep enough and the new aluminum tube didn't fit on it. I had to bring it the machine shop and bore out (lathe) about 0.018"off the diameter. I also used the lathe to make nice, even cuts, but a hacksaw could have been used to cut the rings, too. I then hammered/pressed the rings on both thrust cylinders. YAY, I'm done! Or so I thought. A guy in lab has one of those cool magnetic field viewer card things; they allow you to visualize a magnetic field. I held it up to my rotors spun them around, and...damn. I messed up 1 magnet out of the 100+ I set that day. I had to cut off the aluminum ring, chisel out the super glued magnet, flip it over, glue it back in, make a new aluminum ring on the lathe, then press the new aluminum ring on. Phew...

Cut off the aluminum ring super carefully with a dremel.
The culprit is marked by sharpie.
Finally: Finished thrusters
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.

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 Hover Racer

Oh boy, this is going to be a long one....

Let's start with some inspiration. You've probably seen this: Hendo Hoverboard . The first time I saw it, I thought it was total BS. If you have any sort of engineering or electronics background, you know that magnetic levitation is extremely energy intensive: you either need a ton of power to drive the electromagnets or you need them to be superconducting (or maybe both). There is no way that that board has cryogens on board (for superconducting) nor has 10's of kW's. Even though the videos they posted wouldn't be hard to fake, I noticed a lot of reviews saying that it actually works. What gives? So a guy from my lab looks up his patents. Turns out he's using large rare-earth permanent magnet Halbach arrays arranged on a disk and spinning them at many 1000's RPM over non-ferrous conducting surfaces, e.g. copper (like in their videos) or aluminum. The varying magnetic fields in the conducting surface create eddy currents in the conducting surface, which generate magnetic fields to oppose the applied magnetic fields. Thus, you get lift (and drag torque). Arrange four of those "hover engine" pods in a fashion similar to quadcopter to cancel the torques, and presto: hover board.

There are a few catches though. While power isn't being used to generate the applied magnetic field (permanent magnets), a large amount of power must be used to spin the disks and overcome the power being dissipated by the eddy currents. The motors used must also be efficient and light weight. Judging by the use of RC style wires and connectors, I can almost guarantee that each of the pods on their board has a ~1.5kW brushless outrunner hobby motor. The central compartment probably contains the four hobby ESC's and about (judging by the size of the compartment) 300Whrs of high discharge rate hobby LiPo packs. That gives the 3 minutes of runtime reported by some people who've ridden the board. Also, while they don't have sound in the kickstarter videos, this thing is LOUD. Look up some of the other videos of it on youtube. Four large rotors spinning very fast are going to make a lot of noise if they aren't *perfectly* balanced.

They are also selling a developer kit that has four smaller versions of their "hover engines" for $900. I'm betting these are just scaled down from the big ones: hobby motors, controllers, and smaller permanent magnet halbach arrays. That got me thinking....I could make a better one for less.

Turns out I wasn't the first to think of this concept...turns out Hendo wasn't either! A pair of Brits showed off a small quadcopter-style hover-er at a maker-faire about a month before Hendo went public. Here's the link on Hackaday. Check out the videos at the bottom. (I think that shows prior-art, so I'm not sure how the Hendo patents will get approved, but I'm not an expert in patent law...) . Very cool. 3D-printed rotors hold the magnets. A minimal chassis holds the large battery and the ESC's. This is totally do-able.

So what did I do? I started a lab-wide competition. "The First (and probably last) Great FIT Hover Race"! FIT=Florida Institute of Technology by the way...apparently my grad school isn't well known. Currently there are 4 teams, one of which is me all by me-self (because I want to use it as my Mechatronics class final project). The competition consists of a hover race around a 1/4" thick aluminum track, weight lifting, and a tug-of-war. The rules are: 1. All lift force must come from magnetic levitation. 2. No part of the vehicle may touch the ground at any time. 3. Onboard batteries must be used for power. No external power sources. 4. Thrust/steering may be from any source (as long as it is not in violation of rules 1-3). 5. Maximum vehicle dimensions are 12"x12"x12" (because we can't afford giant slabs of aluminum). 6. Must look cool (no boring white boxes like Hendo's).

Sound fun?

I decided to split up this post. Next: My design.

Mechatronics Project 5

The goal of this project was to apply bidirectional position and velocity control to the motor from Project 4. A PID controller was implemented in MATLAB Simulink RealTime and run on a XPC target. A potentiometer was used as the position and velocity control knob.

For details, here is a link to my Project 5 report: public google drive

Test Setup
Here are the results for both position control and velocity control with response to a PRBS input:
Position Control

Velocity Control
As you can tell, the position control was better than the velocity control, but overall, both worked well. When the knob was used as an input, it would fight you if you tired to change the commanded position or velocity, which was cool. The report linked above has a lot more details.

The "real" goal of the project was to use the systemID parameters discovered in project 4 in an LQR/servo controller, while PID was a backup if you couldn't get LQR working. I simply didn't have the time to implement an LQR-type controller, and I don't think anyone in the class managed to this year.

Helpful resources:
Matlab/simulink documentation (for help on tuning PID gains)

Friday, December 5, 2014

HP Split 13 X2 (product 13t-m000 or E1N79AV) Screen Replacement

In this post, I will show you how to replace the screen in an HP Split 13 X2 (product 13t-m000 or E1N79AV) 2-in-1 laptop. This is one of the earliest HP Split's, but this procedure should be relevant to newer versions. This laptop has a base that contains a keyboard, large battery, usb board, and extra hard drive. The screen part is actually a detachable tablet that contains the motherboard, CPU, RAM, main SSD, power supply, another battery, etc.

The touch glass on the screen on the one I'm fixing got cracked from the lower right hand corner up the right side. The LCD was fine, but the cracked glass caused the touchscreen to freak out/ghost touching and not work properly, causing programs to randomly launch (because it thought I had double touched their icons) and the computer to crash. By being careful not to shake the screen (which causes the freak out), I logged on and went to the device manager (right click start icon->device manager). I went into the "Human Interface Devices" and started disabling drivers starting from the top of the list. If that particular driver wasn't the touchscreen, I re-enabled it. Doing that, I eventually found the touchscreen driver. Now the computer is usable, just without a touch capability.

But the whole point of this computer is to be able to use it via touchscreen...Thus, I started looking for replacement touch glass. I ended up calling HP out-of-warranty support. They will give you an instant (well, 5 minute) quote on most repair jobs for their parts and services. The people I talked to were very helpful. Turns out that you can't just buy the glass because it is bonded to the LCD; you actually have to replace the whole screen unit. It would have cost me about $325 (with shipping) to send the computer to them, for them to replace the touchscreen, and then send it back (5-7 business days). That's pretty reasonable, but the 5-7 days without a laptop is the killer. I then asked if I could just get the part: no problem. It was $180 with shipping for the screen assembly, with the stipulation that I return the broken part to them in the prepaid FedEx box within 15 days. It would have been $20 more if I didn't want to return the broken screen, so I decided to return it. I got the screen in a few days.

There was/is another problem with this laptop. HP seemed to be fans of the Ralink RT3290 WLAN (wifi) card around the time I bought this: it's in a lot of their 2013 products, including this one. By scanning internet forums, it seems that a lot of people have trouble with that card, but HP doesn't acknowledge any problems with it. This laptop exhibited the common "it keeps dropping wifi anywhere over 5m from the router" syndrome from the day I bought it. The two main causes seem to be out-dated drivers and a long run of poorly manufactured boards. It seems that if updating drivers doesn't fix the problem, you probably just need a new one (the newer RT3290's seem to be more reliable). Since drivers weren't my problem, I figured I'd ask HP for the cost of the replacement part. They wanted about $20 for a new one, which is way over-priced. You can find this card online for $5 or less and it is super simple to replace. If I end up replacing the one in this laptop, I'll do another post on how to do it. If I don't, you'll see how to do it in the pictures below. However, I think I may have discovered the source of the wifi problem in this particular case: one of the wifi antenna wires had a partially bent plug, which, when the back cover panel was put on the tablet, caused the cable plug to become partially disconnected from the card. UPDATE: The wifi is much better now.

Anyways, back to the screen replacement. There is a service manual for this laptop available from your HP product's page, but it didn't have the instructions for replacing the screen in mine, so I just used it as a reference. Tools required: an array of small Phillips screw drivers and a small flat-head screw driver. Be careful about static electricity. Disclaimer: I am in no way responsible if you wreck your electronics by following this guide. Don't do this unless you know what you are doing.

The first thing you have to do is shutdown the computer and detach the tablet. Next, you need to pull the little rubber stopper things (2) covering two screws out of the bottom edge of the tablet. Next, unscrew those screws. Then carefully pry the back cover off of the tablet. Start at one point and work your way around. This will take time because it really doesn't want to come off. After you have it off, detach the battery cable (red circle in picture below). You will also want to detach the two ribbon cables being pointed to with red arrows. The upper cable socket has a little black piece of plastic that locks the cable in place: you have to flip/rotate the plastic up using your finger nail to unlock it. There's a little ribbon cable that attaches to the right-most circuit board (hidden under the big black cable bundle) that I forgot to mark. Note that the right most circuit board actually comes with your new screen.

Note: You can see the WLAN card in the lower right. All you have to do to remove it is unscrew it, pop off the antenna plugs, and pull it out of its socket.
There are a ton of screws you have to take out next (red circles and arrows below). Luckily, most of the major components are mounted to a frame, so you don't actually have to remove an individual components. The first thing you should take off is the bottom (top in the picture) trim piece: unscrew the screws under the red arrows in the picture below, unscrew any other ones holding it in place, then gently pull the trim strip off. Next, finish taking out the rest of the screws. Note: I may have missed some and I may have marked extra ones. Look at the new screen assembly you got as a guide to where all the screws are. Also, some screws have to be taken out before others, and you sometimes have to lift other components out of the way to get to those screws. Keep track of where they all go; there are 3-4 types of screws.
Don't attempt to pull the frame off of the screen assembly yet. There are some adhesive patches you have to de-stick first (see yellow rectangles in below picture). I did this by careful prying with the small flat-head screw driver.
Now you should be able to lift the frame off of the old screen. Before you do that, remove the backings from the adhesive strips on the new screen. Now, lift the frame off of the old screen, lay it on the new screen, place all the small loose components, and start reassembling! Remember the base trim and also to re-enable your touchscreen driver.

Total time: 2.5 hours.
Total cost: ~$180.

Thursday, November 6, 2014

Mechatronics Project 4

Project 4 moved away from microcontrollers. For this project, we had to do System Identification of a brushed DC motor using Matlab, Simulink, and an XPC target. This was very similar to a project I had to do in Instrumentation and Measurement Systems last semester, but instead of Labview doing the motor control and data collection, simulink and the XPC target were. The basic idea is to feed the motor pseudorandom binary noise (PRBS) and collect voltage, current, position, and velocity data. The voltage is used as an input, and the current, position, and velocity are used as output, to a grey box motor model. The Matlab SystemID toolbox PEM function was used to find the model parameters, which were first estimated from knowledge of brushed motors (ex: rotor inertia, winding resistance, etc). After the model is obtained, it's checked against the data that was used to make it, i.e. the same input that was used to build it was input into the model, and the outputs of the model were checked against the actual data outputs. This was the verification step. A second set of PRBS data, a set of square wave data, and a set of triangle wave data, were then run through the model, and the model outputs were compared to the real data ouputs (in the time domain). This was the validation step. Finally, the frequency response of the model was compared to the frequency response of the validation PRBS data. That was all repeated for a two parameter/output model, where the current was not used.

Here is a link to my project 4 report: public google drive

Below is my simulink model that was built and loaded onto the XPC target. Going from top -> down, the first set of blocks generate various PWM waveforms that feed into the motor driver. The next set of blocks handle analog data acquisition of motor current and voltage. The next set is a digital output for direction control. The last set of blocks reads the motor's encoder channels, converts the rising/falling edges into up counts and down counts via a state model, and outputs angular position and velocity.

Simulink Model

The physical setup is shown in the next picture.

Messy wires
The XPC target had a NI 6070e DAQ card and was connected to my laptop via ethernet. The current sensor and motor driver are on the breadboard. The motor is lower center. The DAQ accessory breakout board is the green thing center. The XPC target is in upper left. An oscilloscope (upper right) was used for debugging.

I made 3 Matlab scripts. One read the XPC host scope data and saved it in .mat files. One post-processed the data. This included filtering, unit conversions, and creating iddata objects. The third script handles the model building, model estimation, and time and frequency domain data comparisons to the model. Again, I can't post my scripts because the class is still on-going.

The following are the resulting comparisons between model 1 (3 parameter model) and the data. Blue is the model, and grey is the data. You'll have to blow all these up to see them well...sorry about that.

PRBS verification

PRBS validation

2Hz Square wave

3Hz Triangle wave
The model and the data matched very well. I believe current sensor noise and velocity noise (and the resulting heavy filtering) caused most of the discrepancies. Cleaning up the wiring and using a better velocity calculation technique (some sort of moving average) would probably have helped. The average correlation was about 85%. Position and velocity did better than current in most cases.

The following is the frequency response comparison for model 1.

Model 1 Frequency Response
The model and data agree well out to about 60 rad/s (~10Hz). The goal was to get a model that was good out to about 5Hz.

Model 2's plots looked very similar except for the absence of current.

Over all, it was a success. Two good, usable models of the motor were obtained. I now know how to use Simulink and XPC targets, and I got a refresher on SystemID. The XPC target was far superior to Labview for this project because it is a realtime system, while Labview is not. When I did this with Labivew, I was unable to sample the encoder fast enough to prevent aliasing above a certain (low-ish) RPM; I was also running into the software loop execution rate limit (~0.001s). Note: I made it sound a lot easier than it was. The Labview project took ~100 hours. This time around it took about 50 hours. SystemID is hard to get right.

Again, I can't post the codes for this project until the class changes this project.

Useful documents/links:
-Matlab/simulink documentation and tutorials are excellent
-motor, motor driver, current sensor data sheets
-NI DAQ card data sheet

Tuesday, October 21, 2014

Mechatronics Project 3

Project 3 was about making a datalogger and voltmeter using the arduino pro-mini. In mode-1, the arduino had to log to an SD card a sampled sine wave from a signal generator and samples from a three-axis compass. A program also had to be written to read the SD card file and plot the data. In mode 2, an analog voltage had to be sampled and displayed on the serial terminal. We got to use arduiono IDE for this one because of the lack of a good SD card library for atmel studio.

Here are pics of my setup:

Compass is lower left. It needed a 3.3V power supply, which is the voltage regulator on the lower breadboard.

The compass was from jaycon and is based on the HMC5883L chip. It communicated over I2C. There's an arduino library for it, but it's buggy. No attempt was made to calibrate or scale it correctly. The SD card board is a basic one from sparkfun that has on-board regulators so you can give it 5V (SD cards need 3.3V). The arduino 10bit ADC was used for both the signal reading and the voltmeter. Data loging timing was done with the arduino's timer 1 operating in CTC interrupt mode. The interrupt would trigger an interrupt service routine that would trigger a flag that would run the data reading and writing loop. Doing any kind of serial communication (writing to terminal, reading I2C compass, writing to SD card over SPI, etc.) inside the ISR would crash the program because serial communication is interrupt driven. It worked because we weren't sampling very fast (40Hz). High sample rates probably would have required some other way of doing it. I wrote a simple MATLAB script for plotting the data from the SD card. I had to add an outlier removal scheme because the compass would randomly have huge outliers.

Again, like with all of these projects, I can't post the code until the professor changes the projects.

Helpful resources:,115338.0.html
compass, arduino datasheets
arduino SD card library documentation

Tuesday, September 23, 2014

Mechatronics Project 2

Mechatronics Project 2:

In this project, we had to program the arduino pro mini to control a servo and a stepper motor from user input. Prompting was done with a 2x16 LCD display and user input was done with a resistive touch screen. The user had to be prompted for which motor, rotation angle in degrees, rotation direction, and hold time. All entered values had to be echoed on the display after input and the motors had to return to initial position after the hold time.

The touchscreen is an analog device that uses the arduino's 10bit ADC. It has four contacts, with a breakout board to four pins. A 5V differential is put across two pins and one of the other pins is read by the ADC, while the last pin is left floating. This gives either the x or y position. Then the process is repeated with the pins switched for the other position reading. It requires high value (10k in this case) pull down resistors. A written number pad was placed behind the screen. The pad was then mapped by finding all of the boundaries of the "keys". A function in the code translates pressing on the pad into the corresponding number. Pressure is very important for resistive touchscreens. You have to measure pressure and set a threshold for it to prevent bad readings. Pressure is measured by applying 5V to both sides of both x pins, then measuring one of the y pins with the ADC. Note: most touchscreens have a sensitive side and a not-sensitive side. You have to find the right side.

The 2x16 LCD display has a backpack that translates USART serial commands into characters on the display. This made it a lot easier than the last project. Once I found the data sheet and found the USART functions (I wrote my own first, which took 3 hours, but then found some that ended up being identical...doh), it was pretty easy to control.

The stepper motor was controlled with a stepper motor driver board. This required step commands and a rotation command from digital pins. The current was limited on the stepper to prevent it from getting hot. I also used the enable/disable pin to turn the FETS on/off to lower power consumption. This was driven with a 12V power source. While the stepper driver was capable of microstepping, I did not implement it.

The servo was controlled with hardware 50Hz "fast" PWM generated by the 16bit Timer 1 on the arduino. Servos typically take pulse widths between 1ms and 2ms at 50Hz (20ms period). For my servo, the 0 and 180 deg points were calibrated by finding the number of counts that resulted in pulse widths that resulted in a full 0-180deg swing. Then user input degrees between 0-180 was linearly interpolated from those two end points. This was done because the 1ms-2ms was only ~120deg. Note that the servo cannot be driven with the 8bit timers in "fast" PWM mode with a 16MHz crystal (like this arduino has) because they can't count enough to get down to 50Hz. In "phase corrected" PWM mode, they can get down to 50Hz, but the resolution is very poor. Luckily, each timer has two independent channels, so two servos can be driven off of Timer 1. If you need to drive more servos than that, I would suggest buying a servo control board.

The same 12V power source than ran the stepper motor was input into a 5V regulator circuit (based on an LM7805) to power all of the other electronics.


5V regulator circuit
The software was organized into libraries and a main code. One custom library contained all of the LCD display functions. One contained the USART serial communication functions. One contained all of the touchscreen functions. The main code handled all of the logic (stepping through the user input lists) and motor driving. As with all of the mechatronics projects, I can't post the code until the professor changes the projects.

In addition to the links from the last project, I found the following links helpful:

If you want specific part numbers and datasheets, most of these parts came from this kit: or their equivalents on sparkfun.