BreakerBot Moves to ConEdison

Yesterday we visited ConEdison in my hometown of NYC to present our Senior Capstone project, BreakerBot. The goal of this phase of the project was to convince ConEd to continue future phases of the project at BU by delivering a prototype that could:

1. Automatically align to the front of the cubicle where the breaker is located

2. Automatically remove the breaker from the cubicle and reinsert it once aligned

We demonstrated these functions for them with our prototype, and we had a long conversation about the technical and logistical constraints that would need to be considered and accounted for in a full scale robot. As for sealing ConEd's commitment for next year, we are still working on the business aspect of the deal and that's really all I can say right now. 

We did leave BreakerBot there so that it could be used to help secure funding for the project from the higher-ups who were unable to attend our presentation. It was hard to say goodbye to BreakerBot, but we are very happy to know that BreakerBot has a new home at ConEd. 

BreakerBot Gets a New Look

Even though our senior design class is technically over, we still have some things to finish with our project. We are traveling to my hometown of New York City to give a presentation and demonstration of our robot at ConEd. The goal of this is to convince them to continue future phases of the project at BU to design and build a full scale version of the robot. 

We spent the day trying to make our robot look a bit more professional and presentable by adding lasercut acrylic plaques of our sponsors' logos. We also turned some aluminum standoff spacers that I think add a really nice touch.

BreakerBot Wins an Award

Yesterday our team had our senior design presentation for our BreakerBot project. We ended up winning the Best Senior Project award from the BU Department of Electrical and Computer Engineering. I also won two personal awards that day for my design portfolio on this website!

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

Learning to Use Simulink

For our senior design project, we are trying to implement a swerve drive system to achieve holonomic robot motion. None of us really know much about controls, but from the information we have gathered online, it seems advantageous to model our control system in Simulink before trying to implement it with code on our robot. Simulink seems pretty simple to use, at least for basic PID loops. If you have a block diagram for the system you want to model, you just drag and drop the blocks of the system and connect them together. You can change the parameters of the blocks simply by double clicking. 

I made a really simple one here of a basic PI loop responding to a step input. You can change the proportional and integral gains to tune the controller, if you wish. 

Here are my concerns regarding the Simulink model:

1. I don't know how to model my inverse kinematics with the standard blocks. Will I have to make my own custom block to do all the kinematics, or make each step of the equation a separate block?

2. How to get the angle of the robot with respect to the ground? In our robot, this will come from a gyro, but how can I model this in Simulink?

3. Step inputs and sinusoid inputs are useful, but it would be really helpful to model the input from our actual joystick. I need to figure out how to do that. There is a joystick block, but I have no idea how to use it.

4. We currently have no idea how to model the robot dynamics (the 'plant', in control theory lingo). This is the most important part. If your plant is inaccurate, your control will not work.

5. Where does the plant begin/end? Should we attempt to model the motor behavior in Simulink? Or make the motor part of the plant? I've found sources online that go either way.

So after a couple hours of playing with Simulink, I think I have solved issue #1. I ended up writing a custom Simulink block from a MATLAB function. It then compiles the MATLAB code into the block. I am making a smaller system to test the kinematics independently. I will check them with the graphs I generated earlier in the semester.

I sort of found a way around #2 for now by integrating the angular rate signal. But the angle from this is before the plant, so it is not really correct. But it may work for now, just to get the system to run.

The main problem I have right now is compiling the code from the MATLAB Function Block. The Simulink-compatible C-compiler is was not installed on my computer, so I had to download the Xcode app and use the compiler. But it's still returning an error, so there is something else I have to fix evidently. 

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.

A Hard Day's Work

I love working with my hands and making things. At the end of the day, I find it very satisfying to be able to look at the things I've made and say "this is what I did today".

What I did:

1. Finished assembling the scaled circuit breaker model for our senior design project. This involved gluing up the sides of the box, and screwing on the wheels and the rollers. We did not have a thin enough wrench to tighten the roller between the two surfaces, so I had to make one.

2. Began prototyping the device to reduce torsion in coils of optical fibers. I used the laser cutter with 1/4" acrylic. I designed the part so that I could prototype it in 1/4" layers, stacking and gluing together different profiles to get the correct geometry of the final part. The part on the bottom is composed of just two layers. The part on the top (with the spiraling slots) is a single layer part.

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.

Omniwheel Design

Currently working on a high load capacity omniwheel design for our circuit breaker removal robot (BreakerBot). Off the shelf omniwheels of this load capacity (750lb) are very expensive! This design is an exercise to see if constructing our own wheels is a feasible solution. Our other options are to choose an alternative drive train system that doesn't require these expensive and complex omniwheels. However, those systems are either non-holonomic (ackerman steering) or even more complex (swerve drive). I am hoping that we will be able to use these wheels with sort of H-drive system. We do not need full holonomic control, but the ability to strafe and turn on a point would be very useful for aligning the robot with the breaker's cubicle for extraction.