Search This Blog

Showing posts with label Mechatronics. Show all posts
Showing posts with label Mechatronics. Show all posts

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

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

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


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

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.

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:


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.

Friday, September 12, 2014

Mechatronics Project 1

I decided to take a mechatronics class at FIT because it would be different and very useful. The class is split into two portions: learning to program an Arduino pro-mini using C and Atmel AVR-Studio, and then learning Matlab/Simulink XPC. We have to use C because "the arduino IDE is too easy".

Project 1 was to make a stopwatch using a 4 digit 7-segment display and the arduino pro mini 328 5V/16MHz. It must count up in increments of 0.01s using interrupts/timing, and have a button for start/stop and reset. I used the FTDI/USB device to program the arduino (with bootloader) through AVR-Studio.

The breadboard circuit shown below was wired. The display has pins for each segment and a common cathode for each digit. There are 330Ohm resistors in series between the arduino and each anode. There is a NPN transistor for each cathode that act as a switch. When an arduino pin drives the base of the transistor high (through a current limiting 10kOhm resistor), they turn on, grounding the cathode, allowing individual digit control. The digits are cycled through rapidly to take advantage of persistence of vision. The button is hooked up to pin 13 on the arduino, which is the one with the onboard LED. This made using it as an input somewhat difficult because the onboard pullup resistor is 20kOhms, which results in a pin voltage of around 1.7V instead of 5V because the onboard LED is drawing current. So I had to drive the voltage on the pin high as the trigger instead of grounding the pin as I would have normally done.



As for code, there is a main loop that contains the button polling routines. There is also an interrupt service routine (ISR) that handles the digit counting and timing via a bunch of volatile variables and if trees. There is a "on" routine that takes care of turning on and off the correct segments for each number 0-9. I can't make the code available since the class is still running. Apparently the more common way to do it is to have the ISR act as a 0.01s timer that calls a separate function that handles the digit counting, which would probably avoid the use of volatile variables.

In addition to the component datasheets, the resources I used are below: