Kinematics of Wheeled Mobile Robots Pt. 3

Our team finally got the robot moving and steering! Which means it's finally time for me to start the implementation process of the kinematic and control equations. To further verify and help prepare for the implementation, I made a little simulator in MATLAB to help visualize how the robot will move given certain (steady state) commands. Transient commands are a whole other issue, which I may discuss later. 

The structure of the top level code is simple. It defines the parameters of the robot and of the simulation, and calls the swerve_command function. This function performs the inverse kinematics and spits out the wheel angles and speeds, as well as the position (x, y, theta) information for that time step. Over several time steps, the robot will move. If steady state inputs are held, the wheel angles and speeds will remain constant, even if the robot itself is executing some curvilinear motion. The robot is plotted at each time step. To verify the wheel angles are correct, you need to visually confirm that the wheels are tangent to the path taken by the wheels in each snapshot. 

Confirming the wheel speeds is more difficult. For any type of pure translation all the wheel speeds just need to be the same. This has been confirmed. If there is any type of rotation involved, the wheels will orbiting some central point. If the location of the point is known, then the radius to each wheel can be found and using the omega = v/r equation you can confirm that all the angular speeds about that central point are equal. This is hard to do currently because we are normalizing all our speeds because they are simply throttling values which will be sent to the motors. We do not know exactly what speeds they will spin at. However, the ratios of the speeds are telling. What we know is that the wheels on the largest radius of the orbit must have the highest linear velocity, and the wheels on the smallest radius of the orbit must have the smallest linear velocity. This allows all the wheels to have the same angular velocity around that central point. As you can see from the photos, this phenomenon is evident by the colored velocity vectors. 

There is something funky going on with the way that the motion of the robot is plotted. The wheel angles and speeds look okay, but when I try to plot the motion some of the components of the motion (X and rotation) have the wrong sign and it looks like the robot is skidding across the floor. I haven't been able to figure out why that is yet. I have a feeling it's some kind of sign error but I haven't found it yet.

Open Issues:

1. Figuring out how to update the wheel speeds and angles while moving (transient command inputs)

2. Normalizing the wheel speed outputs to prevent speed commands to the motor from saturating

3. Finding the little sign errors that are messing things up

Bonus:

We also made a little case for the webcam BreakerBot will be using for the First Person View mode for remote operation. BreakerBot is watching you...

MATLAB Four-Bar Linkage Design

The Product Design class I am a TA for had an assignment to design a four-bar mechanism to move a lid on a shipping container up and over so that it rested on the top of the container during loading. There was extra credit awarded to those who could analytically arrive at a design using MATLAB (or some other language). I made my own solution for fun and to check student's solutions. I tried to get it to plot each snapshot (in magenta) but it was not correct and I didn't have time to figure it out. 

So, here's how to design a typical four-bar linkage:

1. Define the desired locations of your coupler. You define two or three locations you want the coupler to travel through. My code only works with three locations.

2. Find the locus of points that is equidistant from where the crank connects to the coupler in each position. If two coupler positions are defined, the locus will be an infinite line (think of the intersection of two circles; connecting the two points forms a line). If three coupler positions are defined, the locus collapses to a single point. This point also happens to be the circumcenter of the triangle formed by the three vertices the bearing must be equidistant from. The bearing must be placed on a point on the locus. If the locus is a single point, your job is done. If the locus is a line, you must select a point on that line to be your bearing location.

3. Repeat step 2 for the points where the rocker connects to the coupler.

4. Once you have the bearing locations for the crank and the rocker, you can easily calculate the lengths of each link.

Kinematics of Wheeled Mobile Robots Pt. 2

I discovered a few minor issues with my previous derivation. I had not converted the unit vectors from one frame to the other correctly, and I left some of the expressions in the unit vectors of an inappropriate frame. MATLAB was used to verify the equations. Simple inputs were sent to the equations and various outputs were plotted for evaluation. The rainbow plots show the physical path of the robot in the XY plane. The color indicates the angle of rotation in degrees. The last graph shows my original eureka moment when I finally realized I fixed the problem. Previously, there was a cusp in the magnitude of velocity when it should have been constant. When I saw the constant red line, I knew I was on the right track. 

Because the control inputs are centered to the robot's frame, if you hold constant translational inputs with a rotation, the robot will end up taking a curved path. However if you hold constant translational inputs with no rotation, the robot will travel straight. This is shown by the graphs with no color change.

Isolating Pure Bending in Optical Fibers

One of the grad students from the nanophotonics lab I developed the microbend apparatus for contacted me regarding a question he had. He was trying to isolate bending and torsional loads in optical fibers to investigate their effects. Introducing pure bending in a fiber is difficult because the fibers have very little torsional stiffness. It's easy to eliminate bends to a twisted fiber by simply adding a bit of tension to the ends. But how do you eliminate twist? There is so little stiffness that you cannot rely on the restoring torque to eliminate small twists in the fiber. The current solution is to coil the fiber very loosely (coiling is just one very long continuous bend) whatever twist is inadvertently introduced by the act of coiling will distribute itself along the length of the entire fiber. In contrast, in fiber optic gyroscope winding, because the coils are so tight, the minor twists in the fiber get trapped between turns of the coil, leaving behind localized residual torsions in the fiber. 

The downside to a loose coil is that it is very hard to get each turn in the coil to the same diameter. A constant bending radius is required for accurate measurements. We decided to use an iris diaphragm mechanism to control the diameter of 6 pins, which the fiber will loosely be wrapped around as guides. This way, a very minimal amount of tension could be used to make sure the coils are all the same diameter, and the diameter can be adjusted using the iris mechanism. To go along with this, it would be helpful to have a limited slip fiber clamp and constant force spring loaded spool so the diameter could be adjusted either direction without having to manually pick up slack in the fiber or loosen the coils to reduce the tension. 

One other alternative to this 'loose coil' solution is to actively measure and correct the fiber twist. However, this method seems overly complex. It really depends on how much twist is tolerable. Once that is quantified, we will be able to determine what type of solution is required. I have a feeling the tolerance will not be so tight as to necessitate some type of active system. But I wonder if there is a better solution for an active system? Perhaps if instead of wrapping the fiber around pins, we could wrap it around an expanding cylinder controlled by the iris mechanism. But I have no idea how that could work. Time to start brainstorming...

Kinematics of Wheeled Mobile Robots

After many discussions, our group has decided that four-wheel drive simply does not permit adequate control of the robot for aligning with the circuit breaker cubicle. So we are reverting to our original drive train choice: swerve drive. Swerve drive is a holonomic locomotion system in which each wheel can pivot about its own vertical axis. Using a swerve drive, the robot will strafe sideways along the face of the circuit breaker cubicle, detecting the edges of the cubicle and using those edges to laterally align the robot. Then, the robot will perform an angular alignment to the face of the cubicle, and advance forward to extract the breaker. The angular alignment and subsequent forward motion would not have been possible with a four-wheel drive system; as the translation and rotation of the robot are coupled.

I derived the inverse kinematics of the robot for our computer engineers to use in their control algorithms. The derivation is quite simple mathematically, but it can easily get confusing to understand from a physical sense. I like to imagine what I would experience if I were sitting on the different points where the wheels are located on the robot. This helps me to see why certain terms are in the resulting equations and verify if the results make sense. 

PDF derivation of the kinematics.