Search This Blog

Loading...

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.

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.

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 because the class is still on-going.

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:

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 because the class is still ongoing.

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.

Saturday, September 13, 2014

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

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).
The goal of this project is to modify a "Projectables" brand plug-in projection night light with a Joule thief so that partially dead AA batteries can be used to light it up, while maintaining plug-in functionality. Basically, I wanted an excuse to make a Joule thief and to use up a bunch of partially-dead AA's. You can buy these from Amazon, Home Depot, directly from the manufacturer, and other places. I have the solar system one that I picked up from Home Depot for $10.




You can see the light sensor (photoresistor) here
They work by shining an LED through a image and a lens, all of which is located in the globe, which can be rotated 360 degrees thanks to springy-metal contacts. The following pictures detail the take-apart process.

It's held together with three TA20 (triangle) right-hand threaded screws. These puzzled me for a bit because I figured they'd be standard threaded, but nope...they have reverse threads.

Lots of patents
Insides:

The LED under the globe is for making the globe glow.


Spring contacts allow for 360 degree rotation. Clever
 To disassemble it more, you have to take needle nose pliers and pull out the little gray piece of plastic holding the wall plug contacts in. Then you can push the wall plug contacts out.

Bottom: gray piece that holds in plug contacts. The clear piece is the photoresistor protector.


I'll map out the circuit later. It seems pretty simple. I want to be able to tie the Joule thief circuit into the two LED's. I'm hoping to be able to add a simple switch somewhere to allow me to switch between wall mode and battery mode.

Circuit
Popping open the globe (snaps together like one of those plastic Easter eggs) reveals the projector. It was a bit more complicated than I thought it would be and splits into a few pieces. Starting from right and moving left: lens, tube, solar system picture (the tabs keep the picture in place), lens, tube, LED.
The projector







Friday, September 12, 2014

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:


Sunday, September 7, 2014

L3 Rocket

Purpose: document the build and flight of my Tripoli Level 3 certification rocket

I've always liked the Phoenix AIM-54A missile. I had an Estes kit of it when I was little that I put a 24mm motor mount in it. I flew it probably close to 50 times before it died. I've seen a few larger scale Phoenix missiles, but I've never seen a 1/2 scale kit, so I decided to custom build one.

I got the specs from here. Using stock 7.5" ID, 7.75" OD phenolic tubing results in a 0.517 scale, which is close enough. Given that, the body tube length should be about 63", and the nose cone should be slightly less than 3 to 1. Though it's not ogive in real life, 3:1 7.5" ogive nosecones are commercially available, so I decided to use one and make the body tube slightly less than 63" to compensate for the slightly too long nose cone. I decided on a 3ft long, 98mm motor mount and 1/4" thick 12ply wood fins. I'm building it super tough, so it should be able to go supersonic (large M or small N motors).

The rocket was designed in OpenRocket and Solidworks.
Solidworks model of stretch 1/2 scale Phoenix

OpenRocket model of Phoenix

OpenRocket model of Stretched Phoenix
OpenRocket is predicting ~7000ft for the stretched (dual deploy) Phoenix on a medium M. It predicts ~2000ft on a medium K for the non-stretched Phoenix. Both configurations will use about 4lbs of nose weight. This is due to the stubby and spread-out nature of the fin area, causing the CP to be further forward than usual for a rocket this size.

My dad gave me two 48" long, 7.5" phenolic tubes, two 12" couplers, and 48" of 98mm phenolic motor mount tube. He also has (had) tons of fiberglass, so he let me use it. This wasn't my first time making composite rocket tubes, but I didn't have all the supplies I was used to (MIT Rocket Team, DBF had vacuum bagging supplies we used to make tubes with...I was spoiled) at dad's house, so I had to do a basic wet wrap. I measured and cut two wraps of ~10oz 0-90 E-glass and two wraps of ~4oz 0-90 S-glass for each tube. I used medium cure time West Systems epoxy and wet out the FG as I was laying/stretching it around the tubes.

Setup for layup. Katie's L3 kit is in the background



Lots of fiberglass

Finished layup

Heated cure
Each tube went from 3lb pre-glass to ~5lb 12oz post-glass. Final OD was ~7.75". The surface finish was terrible (no peel ply or release, no vac bag, etc. ), so I had to do a ton of sanding and filling (two coats of automotive spray primer and filler). You can see the result in some of the pics below. Total time spent on the tubes was probably 20-30 hours. 

If I had left the couplers stock, I ran the risk of coupler failure (breaking in half), which is common in these large rockets during high accelerations. So I fiberglassed the insides with 2-3 layers of 10oz glass. Balloons were used to hold the glass against the insides, then popped after curing.


 
I wanted to do 1/8" G10 fins, but I do not have access to a CNC router or large enough laser cutter here. Custom fins would have been ~$400, which is crazy, so I bought a $50 sheet of 12ply plywood from aircraftspruce. I penciled the lines using a cardboard stencil and checked them all with a ruler. 

I then cut them out with an oscillating saw. I tried to sand them with a palm sander and sanding block, but quickly realized it really needs to be done with a belt sander, particularly the beveling. I'll finish them later. I'm going to build a jig for the FIT shops's belt sander and do the beveling there.

I slotted the tube next using a Dremel and reinforced cut-off wheel. I made two slits lengthwise per slot, then broke the material in the slot out using needle nose pliers. Fiberglass is brittle, and the thin/small amount on the ends of each slot made breaking it out easy. I then finished the ends of the slots with a 1/4" sanding drum attachment.




All tubes done
All tube ends were sanded smooth, treated with thin CA, then sanded smooth again to prevent phenolic wear.

Left to do:

  • Buy plywood centering rings, bulk head, nose cone, altimeters
  • Cut motor mount tube
  • Finish sanding fins
  • Make motor mount
  • Install fins
  • Filleting 
  • Build altimeter bay
  • Minor stuff
  • Final primer coat, sanding, then painting

The fins will have internal and external fillets. The rear two centering rings will not be installed until the set of fins they contact are completely done so that the volume they enclose can be filled with expanding foam. The shock-cord mount will be a pair of U-bolts in the forward centering ring. Altimeter bay will be classic rods + sled construction. I haven't picked the altimeters yet. The goal is to be finished by December.

Next time I build a big rocket, I will probably order pre-glassed tubes unless I can figure out a way to get a much nicer surface finish. I'll get them pre-slotted, too, unless I build a nice router tube slotting machine/jig. I want a CNC router and laser cutter in my home shop eventually, so that will make fins significantly easier.