2016/03/06 WE WONNNNNN!!!!!!!!!!!!!!! :) :) Checklist Drivetrain

­ Check that all stepper motor pins are plugged into breadboard ­ Turn on just pololu’s and check that there is holding torque

Sensors

­ Check that signal pins on all sensors are still plugged in ­ Visually inspect IR and tape sensors (no debris on sensors)

Chutes

­ Visually inspect rubber bands for wear ­ Check that servo cables are plugged in

General

­ Check tightness of nuts on allthread ­ Batteries charged and plugged in ­ Switches all correct

IR Search Turn direction: Control direction that bot will turn based on how it is oriented in the corner (have the bot turn in the direction that will allow it to find the IR fastest. Arduino light next to Digital pin label is lit ON: Bot will turn right during IR scan (CW) Arduino light next to Digital pin label is OFF: Bot will turn left during IR scan (CCW) Switch order before match: Turn far left switch on top of chip mechanism forward (supplies power to 5 V) Set IR direction switch on bottom of chip mechanism to turn bot the direction you want it to during IR scan. Turn mid switch on top forward (supplies power to Arduino). Wait for at least 5 seconds before next switch. Turn far right switch on top forward (supplies power to motor). 2016­3­05: James: BATTERIES NEED A RECHARGE. I didn’t have time to do it tonight.

There are now three switches on the top of the bot for starting the competition code. The first switch (far left if looking from front of bot) switches power to the 5 V rail. The second switch sends power to the Arduino, and the Arduino start the turning code, without sending power to the motor drivers. The third switch sends power to the motor drivers, so the bot should immediately start turning, searching for the IR beacon. There is a small switch on the mini board on the bottom of Eric’s chip mechanism that controls whether the bot will turn right or left during the IR search. Make sure to set it to the direction you want before switching on power to the Arduino (not after)! The arduino determines that state right when it turns on, and never looks at it again. 2016­03­04 Printing correctly matched chip assist to see if that makes chip loading significantly easier. Painted and installed chip assist. 2016­03­03 After toying with speeds for many hours, bot is now reliably getting to the scoring position and chutes are all working fine. In 2 minutes, we can get more than 10 reloads and scores. Practiced reloading chutes, and chips are getting stuck in the flared distal input chute since 2 chips can fit side­by­side I reprinted the distal input chute without so much flare so it’s impossible for chips to get stuck that way. There was a rule clarification that we cannot touch chips until the match begins, so we will need all hands on deck loading chip assists as soon as the match starts. 2016­03­02 James: Where is the velcro and the 2A fuses? I got both motor drivers to 1.66 A (max rated of motors is 1.68 A) and it drives. I soldered a delicately attached heat sink to this so be careful with it! 2016­03­02 Eric: Installed new left side chutes. Works better with some marginal improvements i made in the CAD (namely, opening up some tolerances to reduce chance of chip stuckage). Still need to paint it black.

Rotary speed dampers came from McMaster today. I’ll play with them tomorrow to see if we can slow down the deployment speed. James: The 3A fuses are actually not ideal fuses between the batteries and the Pololu motor drivers. I put them there because the ME 210 storeroom only has 1 A and 3 A fuses, and I wanted to deliver more than 1 A of current to each motor. The Pololu motor drivers can take up to 2.2 A of current and the motors can take up to 1.7 A of current. So there should ideally be 2 A fuses instead of 3 A fuses in those holders. So probably when the 3 A fuse fried, the Polulu motor driver was exposed to 3 A and fried. Ben is looking into the ME 218 storeroom to see if they have 2 A fuses. If they don’t, we should make a run to Jameco probably to get fuses that fit into our fuse holders. Fry’s may also have fuses. What size are our fuse holders? 5mm x 20mm. Yeah I could have wired the 4 motor wires into the Pololu motor drivers incorrectly yesterday. Ben: Line alignment code works, along with loop for robot to go back and forth to reload. Timing for the reload will need to be empirically checked once the robot can move faster. Still need to implement the 2 minute timer. Test6_6 is the checkoff code, Test6_7 is the latest working code, Test6_8 is untested. Ben and Eric: Installed broken tape sensor mount. Robot wasn’t working when we arrived (Arduino wouldn’t program, Right motor had no holding torque). Swapped out Arduino and it’s now programming. Morgan thinks we might need to reflash the bootloader on the old Arduino (since it doesn’t respond to resets either) Fuse on the Right Pololu was blown. Replaced with another 3A. Found that the motor outputs on the right pololu protoboard were shifted by 1 pin. This may have screwed things up. Right Pololu was fried too­ Swapped with other pololu on the bot to confirm. Ben is troubleshooting new code now with a low current Pololu until the new Pololu’s come in. New rule: If you change anything on the bot, you must confirm it is working before you leave using Test6_6 or newer code. Also new rule: When putting the bot away in the cubby, orient it Front Out so we can keep an eye on the sensors. 2016­03­01

James: I hooked up the first switch on the top of the chip mechanism in series with the input from the batteries. So if you want to turn the power on to everything excluding the Arduino, flip the switch on the left on top of the chip mechanism away from you. I also permanently fixed the breadboards in front of the Arduino down. I am waiting to fix the line following breadboards down after the batteries are velcro’d to the motors. I will let Maddy choose where exactly she wants to permanently fix down her IR breadboard. I cleaned up my circuits some more, and am pretty close to wanting to hot glue down my powertrain circuit and my line following circuit (except for the Polulu chips, which we will swap out frequently). I await the 100 mA fuse and fuse holder before hooking up the switch between the Arduino and Vin to the chip mechanism. Coding Compiled code that uses a faster pulse speed for the motors. Also incorporates some better line finding techniques and reloading cycle. Will do testing tomorrow around 8­9am when track (hopefully) isn’t too busy. Chip Assist Rule: Can’t touch bot with chip assist device, but I believe you can touch the bot with chips that are still in the chip assist device (same as holding a chip with fingers and touching the bot with it while still in fingers).

This prototype works! Align with your left hand on the front, pull string with your right. Move the blocking strip back into place before reloading. It is not perfect. Requires an experienced hand

to see the chip­chute alignment. Works best if you get the chips about to come out and then align them with the chute holes (ie bridge the gap with protruding chips) Pros: Can load 12 at once, easy to make from modified chutes (we can make 3 currently if we want). Cons: Takes a bit of alignment by eye, sometimes chips fall. Ideas: Modify the loading chute on the bot to be wider (heat gun + bend the PLA?) This would be an issue if chips get jammed in the chute and block it though Ongoing To Do List

These are out to date now:

Task Person Status

Chips are still occasionally getting stuck in the left chute­ I think I just need to adjust the tune in the heights of the allthread mounts better, but we’ll see.

Eric

I want to also play with tilting

The side chutes should be slightly (about and inch?) shorter to actually place chips directly in the center of the force balances.

Eric

1 time, the release string got stuck on a feature on an arm. I’ll smooth out this feature in CAD and reprint

Eric

Track down smaller and better quality rubber bands so we can have redundant rubber bands on each joint

Eric Found cheap assortment pack at Ace, which comes with about 10 in the size we want. If these work out, itll probably just be cheaper to buy a bunch of these packs than to buy the packs of thousands online.

Keep working on dampening the chute deployment so the robot doesn’t shift during deployment rubber dampers dampening out entire top plate.

Eric

Figure out quick chip loading device Maddy See update above

Figure out line following Ben/James

Molexization Maddy

Set up the website Maddy Set up but with my own Weebly account...need to figure out if you guys can log in//change the password so you guys can get in….domain is totoro210.weebly.com (currently unpublished)

Track down 100mA fuses/fuse holders ??? Will arrive today

Order backup Pololus Ben

Velcro down batteries Eric Velcro will arrive today

Figure out the skirt to prevent chips from getting ???

stuck under robot

More permanent IR mount Maddy Hot glued it this morning :)

Win TBD

2016­02­29 Eric: Spray painted and mounted the inlet chute with a torsion spring. Works great. Swapped out rubber bands for the ones I got at Ace. The bot no longer shifts when it deploys the chutes! Tried beating the brick a few times, but the drive isn’t lining up like it used to for some reason. It’s turning too far right when it hits the center line. Also, after the straight drive towards the center line, it turns right when the mid­left tape sensor hits the line. I think it would be better if it turns right when the mid­RIGHT tape sensor hits the line, because it will be more centered on the center line that way. 2016­02­28 Ben: Last Pololu order placed for stepper drivers. I got bulk this time so it’s slightly cheaper. Eric: Based on the video footage from checkoff, it does indeed look like our motors are skipping steps during chute deployment. I found some small rotary speed limiters on Mcmaster. I’ll try setting those up with a pulley to limit the deployment speed, but still have the spring force we want to ensure that the arms stay fully deployed. Making 3D curved chutes will make it near impossible for my printer to print. I’m going to try gently heating up an old chute in the oven and twisting it by hand. 2016­02­27

WE CHECKED OFF!!! See video in Drive Code for checkoff is Test6_6. Eric: I tracked down some retractable badge holders from my buddy that works at TI, but he says they arent super reliable and wouldn’t recommend it for something that has to work every time. 2016­02­26 James: After a significant amount of debugging, we now have all 4 line sensors pretty much good to go. The Arduino registers when the line sensors are on the black, and registers when the line sensors go off the black, and so on. As far as drivetrain and line sensing goes, we have all the hardware we need to pass checkoff. If Ben can get the line following code done, and we debug that as well as the IR detection code, I think we could even aim to pass checkoff tomorrow (Saturday) if we want to be one of the first teams to check­off. We reconfigured the Arduino pins, because it turns at that using pin 0 and 1 means BAD NEWS BEARS for the Arduino when uploading and otherwise acting in a reasonable manner. So we are NOT using digital pins 1 and 0, and everything is good. We are configuring two of the Arduino analog pins as digital output pins for setting the motor direction. New pin layout:

0 Not Used 1 Not Used 2 Front Middle Tape Sensor 3 Front Left Tape Sensor 4 Central Right Tape Sensor 5 Central Left Tape Sensor 6 Pololu Right Motor Step (speed) 7 Pololu Left Motor Step (speed) 8 Not Used 9 Not Used 10 Not Used 11 IR Sensor 12 Chute Gate Servo 13 Chute Deploy Servo A0 Pololu Right Motor Direction A1 Pololu Left Motor Direction

James: Eric and I just finished mounting the 4 tape sensors and hooking them up to my tape sensor circuits. We will then debug the circuits then test out Ben’s line following code when it is ready.

Ben: New code for IR testing is online! Titled “Test6_4”. It should turn left, stop, check IR, and keep turning or respond to IR. Responding to IR consists of a LARGE turn to the right and driving forward. If it gets this far you will have to turn it off before it runs into a wall. 2016­02­25 It’s alive! quote of the day “it responds to sensors! Not how we want it to...but it responds to sensors!”

Eric: Put together the new rev3 chute deployment assembly (powered by rubber bands). Works well! Much less sketchy, but still deploys just as fast. Also wired up 8 LED’s on the top platform for use for whatever, and 3 switches. Ben: Discovered that the back EMF from the motors was screwing up the IR readings. I’ve since changed the code so that it turns, stops, checks IR, and then responds to IR or keep turning. Decided on a pinout for the Arduino Digital Pins:

0 Tape Sensor 1 Tape Sensor 2 Tape Sensor

3 Tape Sensor 4 Not Used 5 Pololu 6 Pololu 7 Pololu 8 Pololu 9 Not Used 10 Not Used 11 IR Sensor 12 Chute Gate Servo 13 Chute Deploy Servo

Shopping list:

5 more 8825 motor drivers heat sink for motor drivers (we could possible make this in the prl by cutting and

bending some pieces of thin sheet metal?) 100mA fuses/fuse holder 4 pin ribbon cable? An extra two small protoboards (I have used 6 and will probably need another if

we want a fifth tape sensor) James: I have wired up another two line sensor circuits. I have wired the circuits up to plug a molex connector into the breadboard with the same wiring order as comes out of the line sensor: red­green­blue­white. Whoever makes the molex connectors for the line sensors hopefully you can follow this convention! I also think we should take pins 1­5 on the arduino for line sensors (or 1­6 or whatever) to get out of the 10­13 Pololu driver pins area. Eric: Experimented with different rubber band deployment configurations. They seem to work as predicted, putting much less stress on the plastic parts while making for a gentler deployment. I’ll pick up some nice real rubber bands so they shouldn’t deteriorate as fast as our proof­of­concept blue ones, and I’ll set up their attachment points so we can swap them out. I’m thinking I’ll still use springs for the vertically deploying arms, since I can set the equilibrium point of those springs slightly acute of fully deployed, so the deployment is dampened out. 2016­02­24 James: Jameco order: 5 100 ma fuses: http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_103887_­1 2 fuse holders:

http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_2221448_­1 Pololu order: 5 more 8825 motor drivers: https://www.pololu.com/product/2133 …Heat sink for the motor drivers, but Pololu doesn’t sell them! wtf.. 100mA fuses and fuse holder I wired up a second line following comparator circuit. The schematic Here is a schematic of my Schmitt trigger (comparator with hysteresis) circuit for lined detection.

The trip points with this circuit are 2 V and 3 V. Ben: Uploaded test code for the IR sensors/tape sensors/drivetrain (conveniently called “StepperMotorControlTest6_autoTurn2.ino”). After turning on, the robot will turn left until it senses the IR beacon. Then it will turn right by 400 steps (adjustable by changing the #define of RTURN). Then it will drive straight until it encounters a tape sensor on TAPE_PIN1, at which point it will stop.

Working on the line following code. Eric: Making mounts for the tape sensors:

**Note that the nominal distance of the tape sensor to the ground is 0.15 in, which happens to pretty much be exactly the thickness of a chip!

Designed 3D printable mount to hold tape sensors and adjust height using 4­40 screws and encapsulated nuts. Uploaded an updated chute assembly to the CAD folder. Alexandre checked us off for review 3! Eric: Installed the center output chute. I’m playing around with ideas to make the deployment of chutes less violent and less stressful on the 3D printed parts.

Go back to rubber bands? THe problem with torsion springs is that they have most of their torque when the

chutes are packaged, and least torque when the chutes are completely deployed. At first I thought this was a good thing, because it gives the initial “oomph” necessary to get things moving, but by the time the chutes are deployed, they’re moving really fast without even that much holding torque. As a result, I’ve been making stronger springs to have better holding torque, but that just makes the deployment more violent.

The rubber bands give us the most torque when fully deployed, but not that much when packaged. This may end up being advantageous.

Reinforce 3D printed parts ­ I’m pretty sure the shafts I am using are too thin. I’ll try to hunt down beefier ones

to reduce the slop, which should in turn also reduce the wear on the 3D printed parts.

Maddy and I talked about reinforcing the 3D printed parts ­ maybe using some scrap filament and a soldering iron at low temp to reinforce critical parts.

2016­02­23 James: After Ben adjusted the ball casters and I increased the torque from the motors by about 20%, the bot drives straight on the course. The drivetrain should be good for checkoff, but after checkoff I will push the torque and speed up to the limit of the motor drivers and motors. We will want a heat sink for each of the motor drivers for sure. Eric: Assembled rev2 chute assembly (minus the center output chute which is printing now). Deploys well under servo control, and servo gates work well.

I would like a shroud around the left wheel to prevent the string that holds the chutes from tangling

It looks like the chips will definitely trip up our wheels. Can we design a skirt either around the whole robot or around just the wheels to push tokens out of the way?

come to think of it, we probably want shrouds around the tape sensors too. Eric: Chute deployment mechanism prototype is working! Just need to wait for the new rev2 base to finish printing and I’ll start assembling the new chute platform.

Also, I realized I forgot to put in slots for the chip gates, so I’ll have to dremel those in :( James: The robot is driving on the course! The plus side is that the new wheels seem to be much more firmly attached to the motors. The down side is that the new wheels are too slick to reliably drive our heavy bot on the course. At 0.9 A current to each motor, the limiting factor in reliably moving the robot forward is the low coefficient of friction between the wheels and the course floor. Also, the friction changes between the wheels and the white section and the wheels and the black tape, which could cause the robot to drive fine on one surface but not the other. We should look into a tape or something that will firmly keep the wheels on the course surface. We may also want to increase the current to the pololu motor drivers to 1.5 A, because the additional weight of the other motors and structure will increase the torque necessary from the motors. I am a bit nervous that our structure will be too heavy to be reliably driven by the stepper motors… We should figure that out soon. Actually the limiting factor might be the torque and ball caster adjustment. I am upping the torque by connecting the batteries directly to the Pololu motor drivers. I am now stepping the current to the motors to 1.6 A to maximize the torque that can be outputted from them. I am connecting the batteries directly to the pololu motor driver. It technically shouldn’t matter what voltage is on the motor drivers, so it should be ok for the voltage to sag over the battery lifespan. 0.5*(1.6 A)/(.71)=1.12 V. So I am setting Vref=1.12 V on the motor drivers. Electronics components I would like: ­Two 12 V voltage regulators which can supply over 2 A maximum current ­2 A fuses that fit into the fuse holders that I have installed into the bot (I am using 3 A fuses for now) ­Heat sinks for the Pololu 8825 motor drivers ­100 mA fuses for the Arduino and fuse holders that can hold these fuses 2016­02­22 James: I got the new drivetrain wired up and driving! The platforms work great for multi­layered arduino and electronics. I also switched in and configured the 8825 motor drivers. There is a switch for connecting the batteries, and separate switch for turning on the Arduino. For each new panel that is attached to the threaded rods, make sure to use two hex nuts on each side. This is a classic trick for preventing the nuts from coming loose. Once we have a more permanent set of heights for the platforms, we would torque the 4 nuts sandwiching each layer. As a final precaution, we could glue the nuts. I noticed that the platforms would come loose even with 4 nuts. This should be resolved by torquing the nuts. Alternately, we could use “flex­loc nuts”, which are a special kind of nut that are designed to NOT come loose, but are

more inconvenient to get into position on the shaft (you can’t just spin them up to position with your fingers). Notes on setting Pololu 8825 motor driver current limit: Nominal Current limit=Vref*2 for 8825 motor driver But Pololu limits that current to 71% of that limit when in full mode. So if I want the motors to draw around 0.9 A, I set Vref=0.633 V for each motor driver. I was able to get the left motor driver to Vref=573 mV and the right motor driver to Vref=610 mV. So the motors will get slightly less than 0.9 A each. Using the 8824 motor drivers, the bot did not have enough torque to drive, so I am hoping that using more current will help with this. It was too late to test this though. Motor to Pololu wiring configuration: Red wire=A1 Blue wire=A2 Black wire=B1 Green wire=B2 We have the sense electronics on the third level. We may find that the noise from the long wires down to the sensors on ground level necessitates moving the sense electronics down to ground level, so we have our analog to digital conversions as close to the sensors as possible.

Redesigned IR circuit to have less noise, work at very short range and long range, work better with Arduino program. Works well to identify frequency from 0in to 6ft away (need 3ft in game play). Going to build on a mini breadboard for integration with drivetrain.

Redesigned chute base to have a shorter footprint, which allows a twice as steep rolling

angle and more clearance to the force balances.

Final drivetrain

2016­02­21

James: Got tape sensor working on the bot using Ben’s tape sensor drive code. The bot will drive up to the black line and then stop. I am now attaching two tape sensors to the front of the bot and will modify Ben’s code to make the bot line follow.

Drivetrain to be printed tomorrow. Note that the height of both the tape sensor holder and the IR sensor holder can both be changed independently. The height of the caster balls can also be changed, so we have the option of using the new wheels or the old ones.

Partly assembled and tested the chute mechanism.

There isn’t quite enough slope to get the chips down the chutes as reliably as we want.

The chute ends can hit the force balance if the force balance is tilted away from our side (just barely). This is OK for beating the brick, but will need improvements for the competition version.

temporary solution for beating the brick can be to simply lower the front of the chute mechanism.

I’ll redesign the system to have a steeper slope, which will require a new printed base piece and loading chute, but all the output chutes will stay the same.

Beacon circuit: Filtering to separate the two signals is too hard! I have tried various combos. Want to try to solve it in software. See below.

New idea for beacon sensing: use the PulseIn (pulse interval) function to determine frequency (aka use the digital comparator output from beacons and then determine the frequency to decide what to do). This should not affect other functions. It will also only be active during the initial “lost in space” state. This works when you vary the frequency of an input using the function generator (testing the code not the circuit, but we know that can work). As soon as the frequency reaches 5kHz, the state changes. Idea is to implement this such that as soon as all three IR sensors trigger (depending on how we space them), we know that we are oriented toward the FLAP beacon and can switch to line seeking mode.

int pin = 7; unsigned long on_time; unsigned long off_time; int period; float freq = 0.0; int state = 0; void setup() pinMode(pin, INPUT); Serial.begin(9600); void loop() if(state == 0) // Example implementation of how we could avoid unnecessary beacon sensing Serial.println("I am lost in space"); on_time = pulseIn(pin, HIGH); off_time = pulseIn(pin, LOW); period = on_time + off_time; freq = (1000.0/period); // Returns the frequency of the signal in kHz Serial.print("Beacon detected with frequency:"); Serial.println(freq); if(freq >= 5) state = 1; if(state == 1) Serial.println("I have been found in space!"); // If state is 1, this means move on to other functions 2016­02­20

(Ben) Stepping code works! Getting issues with the stepper motor making a whining noise… I’m implementing an enable on pin 9 of the Arduino to turn it off when not in use.

Hissing noise due to low voltage (on power supply or on the batteries). Need well above the 12V regulator in order to work. Is the voltage regulator necessary?

Number of steps input in computer depends on the motor speed (MAXPWMPERIODFAST vs SLOW) ­ this could be dialed in, or we could just set a speed (and PWM period) that we want to move at and make all of our hard­coding based on that.

Need to figure out why the motors default to on. I have a motor enable/disable coming from the arduino. It disables the Left motor correctly, but does not disable the right motor. There is something wrong with the enable pin in the Pololu 8824 ­ pulling it high to disable the motor only pulls it to 1 V. Hopefully the Pololu 8825 we get will not have this issue.

Need to change the “TMRArd_InitTimer(0,500);” for pressing spacebar, as well as for the set steps for inputs j and k so it doesn’t jump as much.

Tape sensor: should be 0.2 inches above the ground, mount on a L bracket that has a slider hole

Tape Sensor datasheet: http://www.mouser.com/ds/2/414/OPB703­705_70A­70D­B­9449.pdf

Taking a look at the datasheet, it is optimized for around 0.15­0.20 inches off the target. With this, I got a very reliable signal straight out of the phototransistor ( White>3V, Black<2V). Adding an op amp buffer, we can pull the op amp output straight into an Arduino analog pin, and set software thresholds or do analog­based line following.

2016­02­19

(Eric) Minor edits to the chute tier base Added holes to mount toggle switches (4) and LEDs (18). Added more lightening holes

(Eric) With the rule change about the different size of the MTFBWY zone, we no longer need a double link input chute. However, since our loading cartridge can no longer touch the robot, ill redesign the input chute to allow for faster loading.

Tape Sensor Circuit V1 Improvements needed: tuneable to ambient light conditions (phototransistor resistor → trim pot?) Maybe add a shade to our housing so that we control ambient? (eric’s idea) Testing: Detecting line hits with interrupts is possible! See code volatile int state = LOW;

void setup()

Serial.begin(9600);

pinMode(13, OUTPUT);

pinMode(2, INPUT);

attachInterrupt(digitalPinToInterrupt(2), blink, RISING);

void loop()

digitalWrite(13, state);

void blink()

state = !state;

Serial.println("HIT!");

IR circuit testing: Problem ­­ computationally difficult to distinguish beacon frequencies given the rest of the events and services we need to handle. New idea: Focus on making a circuit that passes only the 5kHz signal to Arduino. Make it such that the 1kHz is excluded and that the amplitude of the signal read by Arduino corresponds to beacon proximity in a predictable way. That way we can do Analog Read and not worry about timing/interrupts.

2016­02­18 Battery­powered motors and Arduino (James) Aft=towards the back of the robot Fore=towards the front of the robot Today I built up a tidy version 0.1 powertrain on the version 0 chassis. This powertrain powers the two motors, the Arduino, and provides a 5 V supply for logic and whatever Eric needs it for. This chassis is completely self­powered, so you can plug in your computer to the Arduino to upload a new program, and then unplug your computer, switch power on to the Arduino from the on­board batteries (this switch is taped to one of the motors, and will cause the Arduino power light to turn on when switched in the right way), and press the reset button on the Arduino to execute your program with no external wires! I connected the two 7.2 volt batteries up in series to provide a high enough voltage for the motors. The black wire out of the series­connected batteries is connected to the blue (ground) strip of the protoboard. The ground is shared on both the fore and aft blue strips on the protoboard. The red wire out of the batteries is hooked to A25 on the protoboard. The (A­E 25) 5 pin node acts as a central hub for the input from the batteries. From this node, 1 A fuses connect to the input terminals of the 5 V voltage regulator(the one with a heat sink in the fore portion of the protoboard), and to the two 12 V voltage regulators on the aft portion of the protoboard. The 5 V voltage regulator is expected to get hot because of the huge step­down voltage, which is why I put a heat sink on that one.

The aft red rail of the protoboard is kept at 12 V. This voltage from the rail is provided to ONE of the pololu motor drivers (since each motor is expected to draw near an Amp, or as high a 1 A, so I used two voltage regulators since they can each supply 1.5 V). One of the 12 V voltage regulators outputs is directly connected to VMOT pin of the Pololu left motor driver. So the Arduino and the right motor are hooked to the aft red rail of the protoboard. I’m not sure whether powering both the Arduino and motor from one voltage regulator is okay. When looking at a voltage regulator from the front (with hole metal sheet away from you), Vin is to the left pin, ground is the middle, and Vout is the right. I followed the data sheets and put capacitors between ground and the Vin and ground and Vout of the voltage regulator. I twisted the +/­ wires of the motors to minimize inductive coupling (noise from the motors which will show up in the IR sensor input). I got a 100 mA fuse from somebody in lab to put between my Arduino and 12 V supply rail, but couldn’t find a small enough fuse holder for it. So notice my sketch soldered wires to this fuse. If this fuse blows, at least my Arduino is okay, but we should buy more 100 mA fuses and properly sized fuse holders. 2016­02­18

Realized we need to redo the state diagram (again!) because the FLAP beacon will physically be inside the FLAP and impede the movement of the bot

Met with Alexandre. No major issues, and he’s definitely a fan of using steppers and not having to move a lot. He recommended getting checked off as early as possible (it starts to get crazy when all the teams are trying to work at once), prioritizing drivetrain debug, and finding ways to fabricate the arms faster (maybe by laser cutting and just buying COTS hinges).

Tape Sensing

This preliminary circuit can detect the presence of black masking tape, registering 2V when on the white table and 0.75V when on the black masking tape (uses gain of 100 op­amp), when held at a steady height of 1in from surface.

Next step is to put this into a comparator and interpret the digital signal with Arduino

Then, develop sensing functions using interrupts with Arduino.

For Power Distribution (by Eric):

Requirements 8.2­45V for the Stepper Motor Drivers (potentially in the Amps range) 7­12V for the Arduino OR 5V on the USB connector (probably up to a

couple hundred mA) 5V for Servos (potentially up to 1A, and doesnt need to be super

accurate) Option 1: 2 7.2V Batteries in series = 14.4V. Directly power Pololu drivers from

this. Linearly Regulate down to 12V for Arduino, and Linearly Regulate down to 5V for servos. Power sensors off the Arduino regulated 5Vout.

Pros: Cons: Lots of different voltages to keep track of (GND, 5V for servos, 5V

for logic, 12V, 14.4V), and 2 linear voltage regulator circuits. Option 2: 2 7.2V Batteries in series = 14.4V. Directly power Pololu drivers from

this. Linearly Regulate down to 5V for servos and Arduino. Hack a USB cable to get pin level access to the 5V in (unfortunately there’s no built in pin access)

Pros: It should work, only 1 voltage regulator circuit Cons: Have to hack the arduino cable, and unplug every time we want to

program. Option 3: Step up voltage on 1 battery to power Pololus (called a buck boost?),

use the other battery to power Arduino directly, and regulate voltage from 1 battery to 5V for servos.

Pros: completely separates moving stuff from logic stuff (what’s the advantage of this?)

Cons: Don’t know much about the step up voltage chips out there. Option 4: 2 7.2V Batteries in series = 14.4V. Directly power Pololu drivers from

this. Pull 7.2V off one battery to directly power Arduino. Linearly regulate 7.2V off the other battery to power servos.

Pros: No cable hacking, only 1 voltage regulator circuit. Cons: won’t be loading batteries the same (probably not a big deal). Kind

of tricky to keep track of all the voltages (7.2V on batt1, 7.2V on batt2, 14.4V, 5V for servos, 5V for logic).

Opinions: I like Option 4 ­ Eric

State Diagram:

2016­02­17

CADed hinges, release/deploy mechanism. Still need to add servo chip release and

torsion spring holders. Today’s meeting whiteboard:

Idea for the Chuck E Cheese: have an asymmetric line sensor that is far enough away from the FLAP that it will not hit the FLAP, it will hit the center line first. Then use the center tape sensors to hone in on the centerline.

Eric will make an Ace hardware run in the morning to get 8­32 threaded rod, nuts,

washers, and to see what torsion springs they have.

2016­2­16 Rolling Chassis progress

1. Drive forwards, drive in reverse, turn left, turn right, and make a gradual turn. Done except for gradual turn.

2. Wire LEDS onto PCB and write in code to indicate which tape sensor is activated. 3. Drive along tape sensor line. 4. Get into chip rolling position. We tested this out using keyboard control today, and

were able to move the bot from starting position to chip unloading position in 7 seconds using a 5 microsecond stepper motor PWM period.

5. Reload procedure. Drive backwards, pause for 5 seconds, then move back into chip rolling position.

Rolling chassis version 0 assembled successfully. I accidentally got the Polulu low­current stepper motor driver (8824) instead of high­current stepper motor driver (8825). I will try to use this power driver for just getting the robot to drive, but we will need to order the high­current stepper motor drivers next if we increase the torque. Alternately, our lab kit contains one Pololu high current driver, so if we borrow the driver of another group, we would have enough to run our motors.

Additionally, the set screws used to couple the stepper motor to the wheel is not reliable due to the vibrations of the stepper motor. Fairly quickly one of the wheels will come loose from the motor shaft. We need to come up with a better way to hook the motor to the wheels. I set the current limit on the Pololu motor driver by adjusting the potentiometer on the opposite face from the screen­printed side with all of the pin labels. Make sure to set the current limit on any new Pololu stepper motor driver using the potentiometer or else risk frying the motor or driver. Vref is measured with respect to ground using the little ring next to M2. Pololu 8824 (low­current) motor driver uses a 0.333 ohm current sense resistor: Current limit=Vref *0.61 Pololu 8825 (high­current) motor driver uses a 0.1 ohm current sense resistor: Current limit=Vref*2 I set the current limits to 0.75 A, which is the highest current that can be supplied without heating up the 8824 drivers too much. My latest working driver code is uploaded to the code repository and enables control of the bot using “w” “a” “s” and “d”. The power drivers and arduino should be transferred to a more robust circuit board. Every time I hook up the bot to a power supply, one or both of the motors do not work because of a loose wire to the power supply or touching motor connection pins. The current setup is incredibly finicky. We were able to drive the stepper motors with a step period as low as 5 microseconds. Functional IR detection circuit

2016­02­16

Curved chute (radius 17”) works well. Ready to prototype full length folding arms. Preliminary state diagram made for the IR Bounce Preliminary ideas for control of Chuck E Cheese Due to revised rules, we will need to move out of the loading zone in order to score.

Therefore, we plan to shuffle the bot forward to score, and backwards to load. To make this work, we need to be able to load all 12 chips very quickly. maybe

preload some sort of cartridge that loads all 3 chutes simultaneously? Arm mechanisms reference dimensions (sorry its so hideous. I’ll make it prettier):

IR Sensing Circuit

Built the following circuit Testing:

2016­02­15

Force Balance max height to safely clear is ~7.5in Chips are actually 40mm x 3.6mm (Not 3.0mm as stated in the rules) 2012 had pretty much the same game:

https://www.youtube.com/results?search_query=me210+2012 Sensing circuits designed and tested

2nd order high pass for 5kHz beacon Results:

Band pass for 1kHz beacon Results:

Active band pass (infinite gain multiple feedback) Circuit design

Specs: Results:

Circuit Ideas Active band pass + low pass to average the signal, analog read

Description: create two band pass circuits for each beacon frequency, then low pass the output to average the waveform. Analog read this value with Arduino. Read both circuits for a given signal detected. Returns 8 bit values, compare them. The circuit with higher value (aka higher amplitude waveform out of band pass) will reveal the identity of the signal.

Problem: Analog reading the value is non­ideal. Also, there is messiness from the fact that the signal amplitude will vary significantly with distance. Better to convert to a digital signal.

Op­amp with high gain to make digital signal, digital read and use Arduino timers to determine period, therefore frequency and signal identity can be determined.

Problem: Can’t create a digital signal from op­amp alone given the significant variations in amplitude with distance, also the somewhat significant DC offset from the ambient conditions

Solution: New best circuit plan: op­amp, high pass filter, op­amp, comparator = digital signal that

can be read by the Arduino Other possible circuit: trans resistance amplifier (add a comparator)

2016­02­14

Eric starting prelim design on full arm prototype Hole grid on the current drivetrain base is 7”x9”, holes spaced 1” apart, 0.17” holes Long 10” arms deploy fine. Torsion springs are better for deploying arms, but hard to find

small enough. We can get away with making our own with music wire.

2016­02­13 James lasercut the design for the base Ben made preliminary code to test the drivetrain. It will be tested when the motors arrive

next week. It should be able to understand the following serial inputs: ‘w’ = move forward ‘s’ = move backwards ‘a’ = turn left ‘d’ = turn right

Eric assembled the automatic unfolding arm prototype, and it works! Printing longer (10”) arms now.

2016­02­12 Eric designed prelim concept design for automatically unfolding arm­slot (it will get

longer later, its just faster to print this short for now):

Ben designed drivetrain platform

Ben cleaned up code for stepper motor control from Lab 3 to prepare to test the

drivetrain Eric made a scale drawing of the field (helpful for visualizing scale, sketching game

strategies, etc). It’s on the root drive folder called 20160212_fieldlayout_letter.pdf

2016­02­11

Team meeting to develop strategy and brainstorm ideas. Ben and James ordered parts (stepper motors, motor drivers) for the drivetrain