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
http://en.wikipedia.org/wiki/PID_controller (for help on tuning PID gains)

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.

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
-http://www.ni.com/white-paper/7109/en/
-http://www.edn.com/design/integrated-circuit-design/4363949/Decode-a-quadrature-encoder-in-software
-motor, motor driver, current sensor data sheets
-NI DAQ card data sheet

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:
http://www.instructables.com/id/Arduino-Timer-Interrupts/step2/Structuring-Timer-Interrupts/
http://letsmakerobots.com/content/arduino-101-timers-and-interrupts
http://www.gammon.com.au/forum/?id=11488
http://forum.arduino.cc/index.php/topic,115338.0.html
compass, arduino datasheets
arduino SD card library documentation

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.

Pictures:

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:

https://www.sparkfun.com/tutorials/246

http://hekilledmywire.wordpress.com/2011/01/05/using-the-usartserial-tutorial-part-2/

https://www.sparkfun.com/products/8977 (tutorial)

http://hekilledmywire.wordpress.com/2011/03/16/using-the-adc-tutorial-part-5/

https://www.youtube.com/watch?v=9WeewNNGs5E

http://eliaselectronics.com/atmega-servo-tutorial/

http://www.avrfreaks.net/forum/tut-c-newbies-guide-avr-timers?name=PNphpBB2&file=viewtopic&t=50106

https://sites.google.com/site/qeewiki/books/avr-guide/pwm-on-the-atmega328

http://www.jayconsystems.com/tutorial/basic-power-supply/

If you want specific part numbers and datasheets, most of these parts came from this kit:
http://www.jayconsystems.com/educational-kit-advanced.html or their equivalents on sparkfun.

I mapped out the circuit today. I discovered lots of free online circuit drawers, which was cool. I used the digikey one this time.

Stock Circuit. Note: there are two crossovers that look like 4-ways.
The only 4-ways that are actually 4-ways have dots.

For comparison. I have L1 and L2 flipped on my circuit diagram.

I attempted to lay it out in a similar manner to how the components are on the board (single layer PCB). I also attempted to understand what was going on. I am no EE though, so please correct me if I got it wrong. Starting from the red "+AC" line (left), there is a 150Ohm resistor, followed by a 250V film cap in parallel with a 1MOhm resistor (hidden under cap), followed by a shottky diode (forward) and a zener diode (reversed). These diodes are copied on the -AC line side. I think those components all make up the AC to DC converter, guessing 120VAC to approx. 5VDC. The DC side of the shottky diodes are linked and the DC side of the zener diodes are linked, giving the +5V and 0V references respectively. Following the +5V reference through a 33Ohm resistor (now about 3V), we get to the LED that makes the ball glow (the one labeled L1 on the board and L2 in my diagram). In series with that is a 1Ohm resistor and the projector LED, which then terminates into the 0V reference.

Now for the control part: Photoresistor resistance decreases with light and increases in dark. So if the room is lit up, power flows from the 5v reference node to through the low-resistance photoresistor, into the base of the transistor, which means it is on. I'm guessing the 20KOhm resistor in series to 0V with the photoresistor (with the transistor base tapped off between them) acts as a discharger or voltage divider, but I'm unsure. With the transistor on, the path that branches off between the 33Ohm resistor and the L2 (schematic) diode is now a low resistance path to ground, so all of the power (~0.25W?) goes that way instead of through the LEDs. If it is dark, the photoresistor resistance is high, causing the transistor to be off, preventing power to flow through it, allowing the LEDs to be powered. It's probably a fairly efficient circuit when it is on, but when it is off it is constantly bleeding some power (guessing about 0.25W) through the 33Ohm resistor and the transistor. Probably a good idea to unplug these when not in use. (see next post for update on this).

Modification plans: I want to add an option to power this using a Joule Thief circuit.

The "JT" voltage source represents the Joule Thief circuit. The switch will allow me to switch between AC and DC mode. It should be fairly safe this way. I'll probably put a diode in the JT circuit to prevent power from flowing across it in case I plug it in with the switch on. The good thing about this setup is that the photoresistor should still function normally in DC mode. However, the power drain when the transistor is on is concerning...it may kill the already partially dead AA's I'll be using for the JT circuit in a single day. We'll see. If that ends up being a problem, I could probably cut a trace somewhere and install another switch.

Challenges moving forward:

• I wasn't able to get exact values for many of the components, so I will have to use a scope/nice multimeter to figure out what voltages are where in the circuit. I'm not sure how I'll power it since everything will be exposed...I need some sort of low current 120VAC source.
• Knowing the voltage difference across the LED's will give me the JT design voltage.
• I want to figure out how much power the stock unit draws when plugged in (off and on).
• Designing the JT circuit (lots of internet tutorials).