iRobot Solenoid Kicker

One of my coworkers is heavily interested in and quite adept at developing curriculum using the iRobot Create platform.  It's a wonderful platform with two wheels and multiple sensors including encoders, IR sensor, touch sensors on the front and sides, and the ability to detect an edge in front or when wheels dip.  It has bluetooth capability with an optional module, Arduino-esque capability with an optional module, and I believe there are wifi modules (a la Raspberry Pi) which are compatible with the iRobot Create.

My coworker and I ran a three day workshop on robotics with the goal of building and programming robots which could play soccer via remote control.  My coworker has done a huge amount of work on setting up an HTML -> Python -> iRobot platform so webpages can be written to control the robot.  He is also very interested in using them for remote teleoperated applications using readily available technologies like Skype to handle the remote viewing operation.

For this workshop, I spent a couple weeks working on a way to install a kicker on the iRobot.  I had a 12V solenoid, and thought that I could use it, driven through the iRobot's battery, to "kick" a ball.   I designed the kicker in SolidWorks to have a lever which pulls an arm forward when the solenoid is pulled in.  This is the "kick".  I wanted to do this when the solenoid is energized, because otherwise the robot battery will drain all the time except when you are kicking.

The setup for the lever is a good example of a third
class lever.  The pivot is at the end, with the effort in the middle and the load at the top.  The load is the force required to kick the ball.  Third class levers amplify the distance traveled and speed of the load relative to the effort, since the load is positioned further away from the pivot than the effort.  The trade-off is that the effort must be larger than the load, since the torque exerted by the effort must be greater than the torque created by the load, but the distance from the pivot to the effort is less than the distance from the pivot to the load.

I 3D printed the kicker and laser cut out a base platform, two side panels to mount the solenoid, the lever, and the pivot point.  I used a spring around the ram between the solenoid and the lever to provide a restoring force to move the kicker back into the robot when the solenoid electromagnet was released.   I designed a simple and compact electronics board to drive the solenoid based on a digital signal from the iRobot.  Four wires from the electronics board to the robot connect ground, battery power for the solenoid, +5V for a relay circuit, and a TTL signal to drive the relay.  I used a voltage regulator to step down the iRobot battery voltage to 12V for the solenoid.  I 3D printed a nice little box to hold all the electronics.

Electronics Board Files

The input and output pins for the iRobot Create can be accessed using a series of bytes sent (via bluetooth in this case) over a serial port to the iRobot microprocessor.  I played around with the bytes.  Check out the work in the two links below; the first is the manufacturers document which describes the available commands for hacking the iRobot.  The second is my notes to show what I was able to implement.

iRobot Create Interface
Practice Document

FRC Pneumatics

I setup an FRC compressor with the basic pneumatic kit from Andy Mark.   This was my first foray into pneumatics with the exception of a failed attempt with an educational kit from Clippard. The theory of pneumatics is well documented and the FRC resources out there are extensive.  The links below are for two different primers on pneumatics.

FIRST 2013 FRC PneumaticsInfo_RevC
FIRST Pneumatics Explained 

The setup I used involved a 12V compressor with a max rating of around 120psi.  A pressure switch increases from a short to high resistance when the pressure  reaches 110psi, allowing feedback control to be implemented if the compressor is driven through a microprocessor which also reads the pressure switch.   While the master circuit is highly pressurized, a regulator can be used to create a lower pressure circuit (60psi) which is used to drive pneumatic cylinders.

Learning involved here included how to use teflon pipe tape (1-2 wraps max, wrap in the same direction that you will turn the female so that the tape is locked in, leave thread off the last 2-3 threads), to turn carefully when using NPT fittings in order to not strip threads (which leads to pressure leaks), to wire up the regulator correctly (the arrow indicates the OUTLET, not the INLET), and to use a correctly rated relay for the compressor (which can draw up to 10A at startup... the first relay I used overheated drastically because of the current running through it).

I also learned a great deal about solenoids and about pistons/cylinders.  Solenoids come in two types, double and single.  A double solenoid has two separate electromagnets which must each be separately controlled by your microprocessor.  Switching one on and other off diverts air pressure into one of the two outlet ports.  Reversing both electromagnets switches the port, causing the cylinder to pull in or extend, depending on how it is hooked up.  A single solenoid has one electromagnet and a spring to return to a default position.  Energizing the electromagnetic cause the air pressure to switch from the default port to the other port.  When the electromagnetic is released, air pressure switches back to the default.

Single Solenoid

Double Solenoid

For the single solenoid shown above, the inlet port (labelled #1 on the bottom) is open by default to the top right port (labelled #2).  When 12V is applied, port #2 is now connected to a release port (open to atmosphere) labelled R2 or #5 in the bottom right.  Simultaneously, the inlet #1 is now connected to the top left port (labelled #4).  So if ports 2 and 4 are connected to two ends of a cylinder, the pressure will switch, causing the piston in the cylinder to switch locations (out if in, in if out).  When the 12V is removed, port #4 vents through R1 (labelled as #5, bottom left port).  This is shown below.

The double solenoid is similar, although a little simpler because of the symmetry.  In this case, applying 12V to either side of the solenoid connects the inlet (#1) to the port on that side (#2 on the right, #4 on the left).  The other outlet port then vents (#4 vents to #5, or #2 vents to #3).  If neither or both of the electronics see 12V, behavior is unpredictable; there is no default behavior to this type of double solenoid.

I learned a bunch about pneumatic cylinders.  I knew the basics already, namely about pressure versus force.  Cylinders have a bore which is the diameter of the pressure chamber and of the piston.  The bigger the bore, the larger the cross sectional area upon which pressure is being exerted.  This leads to a larger force, since F = P x A.  You have several other choices with cylinders, including the initial length, the stroke (how far the piston extends), the methods of mounted on each end, and double acting vs. single acting cylinders.  When using a solenoid of the types listed above, double acting cylinders, which have two air inlet ports, are used.  This allows active motion of the cylinder with positive air pressure to cause motion in both directions.  Conversely, single acting cylinders have only one port.  The cylinder is extended by air pressure, and then has a strong spring on the inside.  When the air pressure is relaxed, the spring retracts the cylinder.

I used Bimba cylinders, the type used by FRC this year.  They have a website which allows you to customize the cylinder you want and then display it.  You can even export CAD files of the cylinder:  http://www.bimba.com/Products-and-Cad/Actuators/Inch/Round-Line/Non-Repairable/Original-Line-Cylinder/ .  In my case, I used a Bimba 096-DX which has a 1.09 “ bore, 6” stroke, is double acting and has a rear pivot hole for mounting. I bought a D-166-1 rod clevis for the front.  The cylinder is 10.78” in length from front to back pivot points.

Simple arduino code was written which fires the cylinder in either direction based on a keyboard serial input.  The code is available here.  A video of the setup in action is shown below.

Stepper Motor XY Interweave

The final task that I played with before beginning to construct a device with stepper motors and boards was the concept of making two motors move simultaneously.  This is very important when playing with 3D printers because you often want to trace out specific geometric shapes which require two motors moving in the XY plane simultaneously.  I kept it pretty simple to start by looking at how to move the "tool" in a straight line from a start point to an ending point.  I used a concept I called interweave, which basically means that you move both motors sequentially in very small increments, going back and forth to "stairstep" your way to a line.  This is shown below... the yellow motions approximate the blue line.  In the limit that the number of staircases is increased, (or to use calculus times, in the limit that the yellow step size goes to zero), the staircase becomes the blue line.

The basic idea of interweave in the way I did it, was to calculate the slope of the line, and step in small increments dx and dy which reflect the slope of the line.  This is easy to do if the slope is a whole number.  For example, in moving from position (50, 100) to position (100, 200), the slope is dy/dx = (200-100)/(100-50) = 2.  So a simple program which interweaves would have the form:

void moveSlope2Steps100()
{
  for(int i=0; i<100; i++)
  {
      takeSingleStep(YstepPin); //One step up
      takeSingleStep(YstepPin); //Second step up
      takeSingleStep(XstepPin); //One step across
    }
}

Generalizing this form is not too hard as long as the slope turns out to be a whole number... We need to know if the slope is greater than or less than one, and then we'll move more steps in the y or x direction, respectively.  Note that there are no cases here for infinite or zero slopes (eg horizontal or vertical lines).


void lineInterweaveWholenumberSlope(int deltaX, int deltaY)
{
  if(deltaX > deltaY) 
  {
     int slope = deltaX/deltaY;
     for(int i=0; i<deltaY; i++)
     {        takeSingleStep(YstepPin); //One step up
        for(int j=0; j<slope; j++)
            takeSingleStep(XstepPin); //Across number of steps equal to slope                          
     }
  }

  else 
  {
     int slope = deltaY/deltaX;
     for(int i=0; i<deltaX; i++)
     {        takeSingleStep(XstepPin); //One step across
        for(int j=0; j<slope; j++)
            takeSingleStep(YstepPin); //Up number of steps equal to slope
     }
   }
}

An example is shown below.  Suppose deltaX = 12 and deltaY = 3.    The program reduces to:


lineInterweaveWholenumberSlope(12, 3)

{
  if(12 > 3) //YES!!!
  {
     int slope = 12/3;  //4
     for(int i=0; i<3; i++)  //repeat 3 times
     {        takeSingleStep(YstepPin); //One step up
        for(int j=0; j<4; j++)
            takeSingleStep(XstepPin);//Four steps over                          
     }
  }
}


If the slope is not a whole number, then we run into issues because we cannot do moves with less than a step.  There are a lot of approaches that I considered.  Most of the early ones involved trying to convert a decimal number into a fraction made of whole numbers.  But this doesn't work because the size of the yellow staircases quickly becomes huge, or because you cannot express irrational numbers as a fraction made of whole numbers.  So the approach that I have employed is to find the nearest whole number slope, and find the remainder (modulo).  Then we can move as though we had a whole number slope, but add in extra steps to compensate for the remainder.

As an example, consider that deltaX = 14 and deltaY = 3.  Fourteen divided by three is 4.666, or we can think of it as 4 with a remainder of 2.  If we execute the same motion as described in the previous example, BUT add an extra step in the x-direction for the first two iterations, we arrive at the endpoint.   The picture at right shows the idea, with the extra steps shown in red.

It's pretty easy to code this type of behavior, because the extra step just happens as many times as the remainder.  The remainder and the slope are both easily found using integer division (the remainder is removed so int[14/3] = 4), and modulo (which records the remainder so 14%3 = 2).  Sample code for the case where deltaX exceeds deltaY is shown below.


void lineInterweave(int deltaX, int deltaY)
{
  if(deltaX > deltaY) 
  {
     int slope = deltaX/deltaY;
     int remainder = deltaX%deltaY;
     for(int i=0; i<deltaY; i++)
     {        takeSingleStep(YstepPin); //One step up
        for(int j=0; j<slope; j++)
            takeSingleStep(XstepPin); //Across number of steps equal to slope
        if(i < remainder)                          
            takeSingleStep(XstepPin); // this is the step in red
     }
  }


One thing to point out is that the extra steps mean that the actual path traced out will deviate from the ideal path; in the example above the "tool" moves too far to the right early on, but ends up in the right place.  This type of deviation is exacerbated when a) the remainder is large and b) the number of steps is small.

I created an Excel spreadsheet to explore how far off the actual line would be from the theoretical line.  The spreadsheet shows a series of points on the left corresponded to the coded actual line (based on integer slopes and modulo calculated remainders) and the theoretical points based on floating point calculations.  You can play with the number of steps in the X and Y directions to get a better sense of the errors discussed in the previous paragraph.  Here is a link to the spreadsheet.

The complete code for interweaving is below:


void moveXY(int _Xsteps, int _Ysteps)
{
  int slope[2];
  if(_Xsteps > _Ysteps)
   {
    slope[0] = _Xsteps/_Ysteps;  //calculate slope to nearest integer
    slope[1] = _Xsteps%_Ysteps;  //calculate remainder
   }
   else
   {
    slope[0] = _Ysteps/_Xsteps;  //calculate slope to nearest integer
    slope[1] = _Ysteps%_Xsteps;  //calculate remainder
   }
   if(_Xsteps == 0)  //vertical line
    {
      for(int i=0; i<_Ysteps; i++)  {takeSingleStep(stepPinY); }
    }
    else if(_Ysteps == 0)  //horizontal line
    {
      for(int i=0; i<_Xsteps; i++)  {takeSingleStep(stepPinX); }
    }
    else if(_Xsteps > _Ysteps)
    {
      for(int i=0; i<_Ysteps; i++)
      {
        takeSingleStep(stepPinY);
        for(int j=0; j<slope[0]; j++)
            takeSingleStep(stepPinX);
        if(i < slope[1]) // this is where we compensate for the remainder
            takeSingleStep(stepPinX);  //take one more step each round 
                                       //until we've taken as many as  
                                       //the remainder
      }
    }
    else
    {
      for(int i=0; i<_Xsteps; i++)
      {
        takeSingleStep(stepPinX);
        for(int j=0; j<slope[0]; j++)
            takeSingleStep(stepPinY);
        if(i < slope[1])
            takeSingleStep(stepPinY);
      }
    }
}

Stepper Motors and Drivers

PSMD Triple Axis Stepper Controller

A coworker gave me a PSMD Triple Axis Stepper motor controller about a month ago.  This is a device designed to make your life easy when building a 3D printer or something else which requires high level precision of motion in three orthogonal directions.  It provides easy connections between three stepper motors, three stepper drivers ( Polulu A4988), a microprocessor controller, and power.

The gift stimulated me to learn about stepper motors and drivers, as well as ultimately to put together a functional device which makes use of both.  While at the beginning I was shying away from 3D printing, in the end I've migrated in that direction given the wealth of information available on the subject.  This post is not about a 3D printer, but rather about the motion systems used in a 3D printer, or in any CNC machine for that matter (milling machine, laser engraver, etc).

Here's what I've learned about stepper motor drivers.  All stepper drivers activate or deactivate coils in the motors in order to step the rotor around the stator.  There are three types of stepper motors; I used bipolar motors which are common for 3D printers.  They have four wires, two of which connect to each of two sets of coils in the stator.  The rotor has permanent magnets; the number of these magnets, along with the way the coils are arranged in the stator, determines the steps to degrees turning ratio.  The stepper motors I used with the PSMD are 200 steps/turn or 1.8 degrees per step.  Stepper motors can also be microstepped so that each step moves less then 1.8 degrees.  The A4988 allows up to 1/16th of a step to be taken by changing the resistance on three pins.   Stepper motors also hold a position actively; current is constantly applied to the coils in order to stay at the current position while the motors are enabled.  There is a ton more information at this site:  http://openbookproject.net/electricCircuits/AC/AC_13.html#xtocid174388  .

All stepper motor drivers operate in current limiting mode.  This means that they turn off voltage when a maximum current has been reached.  The stepper motors that I am using for the x-axis and y-axis positioning are rated for 4V.  Yet they are being driven by a computer power supply outputting 12V.  If the 12V remains applied for the duration of a step, the motor would get too hot or could have windings burn out.  The A4988 and other similar drivers sense the current through a resistor and limit the duty cycle (amount of time) that the voltage is applied to the motor through an H-bridge, effectively limiting the average current seen by the motor.  The details are a little more complicated:

"Each full-bridge is controlled by a fixed off-time PWM current control circuit that limits the load current to a desired value, ITRIP . Initially, a diagonal pair of source and sink FET outputs are enabled and current flows through the motor winding and the current sense resistor, Rsense. When the voltage across Rsense equals the DAC output voltage, the current sense comparator resets the PWM latch. The latch then turns off the appropriate source driver and initiates a fixed off time decay mode."  See the A4988 datasheet here for more details.  

You can adjust the reference voltage, Vref (which is, I think, the DAC output voltage referenced above) using a potentiometer wired to the REF pin on the A4988 chip.  In my case, I purchased stepper motors rated at 1.2A per coil of current.  (Other important facts about the motors:  44 oz-in holding torque, and 4V rated voltage, see here for motor specs ).  According to the data sheet, Itrip = Vref/(8Rsense).  Looking at the Polulu website for the A4988, Rsense = 0.05 Ohm, so we can solve for the desired Vref = Itrip x 8 x 0.05.   With Itrip =1.2A, we get Vref = 1.2 x 8 x 0.05 = 0.48V. I set the potentiometers for this reference.  There are excellent directions online for setting up the A4988 at this URL: http://aeons.phrenzy.org/~berserk/reprap/PololuPres_V3.pdf .


All the stepper drivers which I have are controlled by three digital TTL level pins.  One controls whether the stepper is enabled or disabled.  The second controls the direction of spin of the stepper.  The third is a step pin, which initiates a step when it is pulsed high (or maybe when it drops low again... I'm not sure).  A simple function to "step" a stepper has the following form:

void takeSingleStep(int stepPin)
{
  digitalWrite(stepPin, LOW);
  delayMicroseconds(2);
  digitalWrite(stepPin, HIGH);
  delayMicroseconds(1000);
  digitalWrite(stepPin, LOW);
}

When called, this function pulses the step pin low, then high, then low again.  I found that the second delay (currently set at 1000 us = 1ms) is important; if that delay is too small then the stepper doesn't have time to execute multiple steps sequentially and it makes weird noises and moves erratically.

A simple function which turns on or off the stepper motors is shown below.

void enableStepperXYZ(int isEnabled, int enablePin)
{
  if(isEnabled)
       digitalWrite(enablePin, LOW); // enable HIGH = stepper driver OFF
   else
      digitalWrite(enablePin, HIGH); // enable HIGH = stepper driver OFF
 
  delayMicroseconds(2);
}

Two simple set of functions which change the direction of rotation are shown below.  I found that one way did not work for the v3.3 driver; they are labelled appropriately.

The following function worked for only the PSMD and is an absolute function:  it sets the direction either clockwise or counterclockwise.

void setCurrentDirection(boolean dir, int dirPin)
{
  if(dir == false)
      digitalWrite(dirPin, LOW);
  else
      digitalWrite(dirPin, HIGH);
  
  delayMicroseconds(1);
}


The following two functions worked for both boards and are relative functions:  they set the direction to be opposite the previous direction.

boolean currentDirectionZ = true;

void setCurrentDirectionZ(boolean dir, int dirPin)
{
  if(dir == false)
      digitalWrite(dirPin, LOW);
  else
      digitalWrite(dirPin, HIGH);
 
  currentDirectionZ = dir;
  delayMicroseconds(1);
}

void changeDirectionZ()
{
  setCurrentDirectionZ(!currentDirectionZ, dirPin);
}

Besides the step, enable, and direction pins, there are other pins on the A4988 which are important, but the PDMS board takes care of most of them for you.  For example, the reset and the sleep pins are both pulled high, effectively making them unusable but so you do not need to worry about them.  The board has three mini-switches attached to MS1, MS2, and MS3, which allow you to easily set the stepping mode (full, 1/2, 1/4, 1/8 or 1/16).

MakerBot v3.3 Stepper Driver

I also worked with the StepperDriver3.3 from Makerbot as there were several of those sitting around from previous work done by others on Makerbot3D printers.  The documentation for these has been largely pulled from the web since they are older products, but they are totally functional.  I've posted the relevant file here.  Most of the information is really similar to the PSMD board, because the v3.3 is based off of a predecessor chip to the A4988, the A3977.  Here's the datasheet for the A3977 chip.  If you compare the two datasheets, you'll see that they are essentially the same at the level of detail that I have been talking about.   One difference is that the A3977 does not have 1/16th stepping possibility, only full, 1/2, 1/4 and 1/8th, set by two pins, MS1, and MS2.  A second difference is that the A3977 supports higher currents and therefore bigger motors, with a rated current of 2.5A compared with 2A for the A4988.


I used the v3.3 board with 42BYGHW-811 Wantan stepper motors, which are rated to a higher current of 2.5A.  The Rsense resistors are 0.25 Ohm for this board, so with a rated current of Itrip = 2.5A, we can calculate the value of Vref to set for the v3.3 board as 5V.  The maximum permissible for the logic of the A3977 circuits is 4V according to the datasheet, so I set Vref = 4.0V.

The PSMD board also has integrated pinouts for limit switches, which are sometimes used to detect the end position in the X, Y, and Z axes (both low and high limits).  The pins provide +5V, and a signal pin.   You can digitally read the signal pin to see when it is shorted to ground with a pullup resistor enabled on the Arduino.

v3.3 Cable Ribbon Pinout

PSMD Cable Ribbon Pinout

Wiring up the stepper motor boards to an Arduino is very easy to do if you have some ribbon cable and the pinout diagrams for each board.  The pinout are shown here... I wired together the enable pins for all the steppers into one pin on my Arduino allowing me to turn on and off all the motors at once.