WTH Post Office?!

 I Just don’t get the post office sometimes. Usually I have no problems with them. Packages arrive on time and are sent in a timely manner with no issues. Unfortunately that was not the case for the last package I ordered.

I have recently moved and so I’m having all my mail forwarded. I ordered a motor driver for my tank robot on eBay but forgot to change my address and so the seller shipped it to my old address. Not a problem I thought, the mail forwarding should take care of that.

It should be noted that my old address and my new address are maybe 20 miles apart. My package arrived at my old address on the 10th of September and sat there (according to the tracking number) for 4 days. Then it was sent to a completely different state over 300 miles away! 4 days later it finally arrives at my house. 8 days wasted on something that was ultimately my own doing, but at the same time I’m curious on whether someone made a mistake in sending the package to another state or if that is procedure.

In any case, I now have the batteries, RC controller and receiver, and motor driver to get this tank bot up and running. Pretty busy with a school project for the next week or so, but hopefully I’ll have something up about it after that.

A Time for Waiting

Still have a lot of projects on my plate, but I’m being held back by supply issues. I’ve ordered a 3D printer to prototype and build my DuelBot with, but it has a 6-8 week lead time so I’ll be waiting awhile for that. I’ve also ordered some LiPo batteries and a charger to go along with it. This will enable me to get RC control working with a vehicle. One more coding challenge down means one less coding challenge to deal with once I finally have all the parts to the DuelBot waiting to go. I’m going to put the RC controls on my tankbot, so hopefully in a week or two at the latest I can post some video and pics of the tankbot running around my neighborhood.

I’ve also started a robot for a competition, but don’t feel that it would be useful at the moment to start blogging that since it is in the very early stages of design.

Insomnia Can Be Productive

Had a bout of insomnia the other day and decided to make a scribble bot. I was inspired by this instructable. I wanted to make one a bit more robust, so I made a few changes. I don’t know that the one I made is better than the one in the instructable, but I learned some lessons and I have some ideas on what to change if I need better performance out of the robot. 

This video is 4 videos spliced together. Not a video producer so unfortunately that’s the best I could do, although I’m going to try to get a little bit better and maybe work in some transitions etc. at a later date.

In the last part of the video I needed to readjust the green marker but didn’t because it was late and I needed to get to bed.

Hot Glue Keeps the World Together

My last robot was successful but took some fiddling with to get it right. I developed a few techniques that I thought I would share.

This is actually pretty good!

While it’s fine to have a general idea of what you want your robot to look like and how you are going to build it, one thing that is hard to nail down is cable management. At first most robots start as a prototype, with wires running every which way and connected to breadboards and header pins. I found out the hard way that these wires will come unconnected at the worst possible times. This ruins any testing that was ongoing and can lead to a great deal of frustration.

Enter hot glue. This substance is really just a sticky thermoplastic with a very low melting point. It’s fed into a “gun” that lets you squirt it wherever you want. It has some fabulous properties for robot prototyping. For starters, the glue dries quickly so you can fix a couple of wires in place with minimal time and fuss. The glue also has good holding power, so things that you glue will stay in place. I even glued the IMU onto the robot for the self balancing robot I made, and it never fell off even with all the gyrating that robot did. However, the glue is paradoxically rather easy to remove. Just grab a blob with your fingers and pull and it comes right off usually. And if it doesn’t, a little work with the back of a razor blade or xacto knife will scrape it right off.

I used hot glue to keep the wires plugged into the breadboard and to keep the wires plugged into the header pins on the Arduino itself. The battery holders were affixed with hot glue, and I could have done the same with the motor drivers as well but they already came with their own mounting brackets. The only thing I actually needed to screw on were the motors. Hot glue is good but it isn’t good enough to hold motors on.

For a final robot design something like heat shrink should probably be utilized. This will keep the wires wrapped up out of the way and looks good too. You can also find adapter cables (like servo cables) for certain things. Also,rather than a breadboard a prototyping shield can be used so that you can solder all the connections instead of gluing them on.

Finally the issue of protection should be considered. Since most vehicles or mobile robots will probably fall or roll over, some sort of protection for the electronics should be used. This can be as simple as a plastic food container with a lid glued into place with the electronics inside, or specialty project boxes that can be found online for a more polished presentation. On this prototype of the self balancing robot I just put a large plastic peg next to the Arduino that would keep it from touching the ground if the robot fell over.

Unfortunately that robot was rushed and I was unable to take any photos of it. Hopefully you can see some of what I have talked about in the video.

Self Balancing Robot – PID Control

PID control and PID algorithms are a complicated topic that are a bit difficult to understand. I’m going to try to explain it as it relates to the robot I just did and hopefully it will give you a general idea of what a PID algorithm is and why it is used.

To start off, some definitions. First, an algorithm for our purposes can be defined as a step-by-step procedure for solving a problem or accomplishing some end especially by a computer. The end we want to accomplish is making a robot balance on two wheels, and the PID part is a type of algorithm that follows certain steps in order to make that happen. Next, PID stands for Proportional-Integral-Derivative. The integral and derivative part are related to calculus, but if you haven’t taken calculus you  can still understand and use PID controllers.

If you Google PID algorithms you usually turn up some funky looking diagrams like this: 

PID Control

From left to right:

• The desired state is the position you want your robot to be in. In the case of the balancing robot, that would be straight up and down.
• The e(t) part is the error experienced. So if you want your robot perpendicular to the surface it is on, i.e. 90 degrees, and it is actually 95 degrees, then e(t) is 5 degrees. The MPU-6050 tells you what orientation the robot is in, and you set the value for up and down in code. My robot worked on a value of 181 degrees. This is because I mounted the MPU-6050 parallel to the floor. That’s why I recommend setting up small programs to run each piece individually, because I was able to tell what value I was supposed to get without a lot of trial and error.
• The Kp * e(t) part is the Proportional part. explained later.
• The Ki * integral e(t) part is the Integral part. Later.
• The Kd * d/dt e(t) part is the Derivative part. You guessed it, later.
• The + means they are all added together into a control signal that is passed on to the system. In our case the system is a self balancing robot. The control signal tells the Arduino how fast to move the motors in order to balance the robot.
• Finally the sensor (the MPU-6050 in our case) sends the new current position of the robot back to the Arduino, which calculates the error and does the whole process again. This is called feedback, and makes this type of control loop a closed-loop system (as opposed to an open-loop system, which is easier but much less accurate).

 

The proportional term (gain) makes a change to the output that is proportional to the current error value. Larger values typically mean faster response since the larger the error, the larger the Proportional term correction signal. However, an excessively large proportional gain will lead to instability and oscillation. In layman’s terms, the further away from the desired state the robot is in, the larger the proportional term will need to be to correct it. So if your robot is wobbling a lot or is very off balance, you might need a larger Kp term to offset that because the robot is going to be further off balance. Here is a picture on what certain Kp values might look like:

 So A is e(t), and the value before A is the Kp value. You can see that larger values of Kp help the system achieve stability faster. However, you can overdo it. Too much Kp will give severe oscillations, as seen here:

Note that these Kp values are NOT recommended values for your robot, they are general values only to illustrate a point. My actual Kp value for the balancing robot was 40. Less than that gave a sluggish robot that oscillated wildly, while more than that was too aggressive an approach (like the 100000A example above). The original Franko robot had a value of 70. It all depends on the robot, even two robots that have the same purpose.

In engineering talk, the Integral term is proportional to the amount of time the error is present. The integral term accelerates the movement of the process towards the set value and eliminates any residual steady-state error that occurs with a proportional only controller. The contribution from the integral term is dependent both on the magnitude of the error and on the duration of the error.

What that means is that robots are only as accurate as you program them to be, and as accurate as their motors are. Without going into detail, just because you program the robot to turn a wheel a certain amount doesn’t mean it will turn that exact amount. Usually it will be a little off (due to friction, motor deadzones, power losses, etc.). The integral term (Ki) takes this error and adds it up until it is large enough to make a difference. 

For example, if the MPU should read 181 degrees to be balanced, but reads 181.1, that might not be enough to move the motors enough to correct for that .1 difference. But if the MPU reads that value 100 times in a second, the extra .1 degree becomes 10 degrees of cumulative error, and that IS enough to move the motors.

This can have negative consequences if the Ki error is too large though, as shown here:

Ki Values

 

In this graph, B is e(t) and the number before B is Ki. For the balancing robot, a large Ki will enable it to steady itself very quickly, and will help eliminate drift. If you look up videos of balancing robots on YouTube you will see that a lot of them will roll around. That is because of their steady state error, and a larger Ki will stop that (as long as it’s not too large). Mine was set at 500, which is over 7 times greater than the Kp value.

Finally is the Kd term. With the derivative term, the controller output is proportional to the rate of change of the measurement or error. The derivative term slows the rate of change of the controller output, most notably near the controller set value. It therefore reduces the magnitude of the overshoot produced by the integral component and improves stability. Larger Kd values decrease overshoot, but slows down transient response and may lead to instability from signal noise amplification from differentiation of the error.

To translate, the Kd term helps the Kp term not overshoot the mark and reduces oscillations. Too large of a Kd term will slow down the response of the robot and make it slower to balance, while too small of a Kd term will make it shake a lot. Mine was set at 1.9, so much smaller than either the Kp or Ki terms.

Also I was using the auto tune function of the PID library, and so I do not know the actual final values of the 3 constants. The way I set them got me good enough results so that the auto tune could “fix” them and get the robot to balance well. Some more trial and error without the auto tune will be necessary to get good performance without the warm-up jitters that are shown in the video posted previously. 

Note that all of the “engineer” talk and the graphs came from a presentation from my college instrumentation course that I am unable to link to because it is behind a username/password sign in.

Obviously PID algorithms are complex and are different for each robot you will build. Hopefully this brief overview gives some insight into how one goes about constructing a PID algorithm.

 

Self Balancing Robot Prototype

This robot was developed for my robotics course at UNC Charlotte. It uses a Digilent basic robotics platform with 2 PmodHB5 motor drivers, an Arduino, and an MPU-6050. It is a good test platform for the DuelBot, and helped me to work out some kinks in my understanding of what was needed to get a robot to balance, as well as some good construction techniques.

The code was a modified copy of the Franko robot code. I rewrote the motor controller class to work better with my motor drivers, then took out the unnecessary components of the Franko code and adjusted the PID algorithm coefficients to match my particular robot.

I’m using 2 publicly available Arduino libraries to make coding the robot easier. Unless there is a very good reason to do so, generally it is better to use preexisting libraries rather than try to write your own. The two libraries are the MPU-6050 library by Jeff Rowberg and the PID library by Brett Beauregard. These libraries automate a lot of the code and math that makes a self balancing robot difficult and really simplifies things. The MPU-6050 library filters the data for you (using a complimentary filter I believe), while the PID library has an option to automatically set the PID coefficients for you. I used the auto tune for this robot but will not use it for the DuelBot because it is not as effective (it just takes more time).

I’ll get the code up on github at some point, but the Franko link above should be enough to get you started. I also plan on writing posts about different parts of the robot, but those are more technical and will take a bit of time and planning to do right.

Maze Solving Robot

Here’s my maze solving robot. It uses an ultrasonic sensor on front to detect walls in front of it, as well as two IR sensors to detect when it is about to go over an edge. The robot is a DaNI robot with an sb-RIO FPGA board inside. It was pre-built, which was kind of a bummer because half of the fun of building a robot is building it. The robot was programmed using the LabVIEW robotics package that came with the robot. This was for my robotics class at UNC Charlotte.

The goal was to get to the end of the course successfully, with the fastest time through the maze getting extra points on their grade. My lab partner and I have an excellent score already in the class so we were just going for a successful completion and not for speed. At the end you see the robot spin and then stop. Just a misplaced if->then loop unfortunately, but still counted as a success. Easy to fix but no real reason or motivation to do so.

This is a good opportunity to talk about sensor placement. You can rarely have too many sensors. The more sensors on your robot, the more data points you have to make the robot behave the way you want it to. However, the complexity of your code generally goes up with each sensor added, because you have to initialize the sensor, read the sensor, make sense of the data the sensor is giving you, and then do something useful with the data.

On this robot there is no sensor to detect if the robot is about to fall off the side of the ramps. The placement of the IR sensors leaves much to be desired, but we were not allowed to move them. Therefore we had to run the maze several times to get it to complete the course successfully, and we had to just keep tweaking little values until it finally navigated the course correctly. Better sensor placement, or alternately more sensors, would have made this process much easier.

Building Blocks

I am not a programmer, so the things I say about programming might not be 100% correct when it comes to programming best practices. However, it is what works best for me.

When starting a new robotics project with new parts I like to program them in small, bite-sized chunks. This way I can be sure that I’ve mastered the code to run one part before I move on to another part. 

If I just throw all the parts together and try to program them all at one time, it becomes very difficult in a complex robot to troubleshoot which component is causing your problems.

For example, I’m working on a balancing robot for a class project, and there are  a bunch of new parts that I haven’t worked with before. Not only do I have to contend with new motor driver boards and a new IMU, but I also have to integrate 3 new libraries into my code that I haven’t worked with before.

Therefore, I start with the motor driver and make sure I can make the motor do what I want it to do. Once I work out all the bugs with it, I start a new program and work on getting the IMU programmed correctly. After that I open up a third program and start integrating everything together. I copy in the relevant bits of programs one and two and then those sections should be good and error free. 

I also don’t like just copy+pasting someone else’s code. For one, I don’t learn it  that way, and secondly I don’t understand it. I look at someone’s code, dissect it in my head and figure out why they did certain things the way they did them, and then I recreate it myself. This gives me the optimal chance to learn about why the code works the way it does and how each component fits into the code.

In Other News…

 

I realize it’s been a while since my last post, but I just haven’t had anything to post about. I’ve been busy with school and work and that has sapped a lot of my time I’d normally use for projects. However, I do have several things on the immediate horizon.

First, I’ve been programming a maze bot and have it almost finished. I’ll get a video of it put up once it’s done, which should be Monday.

Second, I have done a lot more research on the balancing bot and have started a school project to build one. That is still in its infancy, but I plan on detailing the motor driving, hardware, and software in separate posts (if there’s enough to talk about for each one) so that should hopefully be interesting.

Lastly, unfortunately I just found out I will have to move in a bit, so I’m putting my major projects on hold until I get set up at my new place. There is some stuff I can do in the meantime, so the blog won’t be totally empty.

I also take requests, so if anyone wants me to do something let me know and I’ll see what I can do (reasonable requests only!).

Balancing the Self Balancing Robot

Balancing

Most self balancing robots try to put all of the weight they can between the two wheels and as evenly distributed from front to back as possible. This ensures that the motors have to do as little work as possible in keeping the robot upright because an even weight distribution makes the robot more stable. The DuelBot is obviously not balanced that way. There’s a 9 inch lance coming out of the front and a 3 inch battleaxe sticking out the other side.

However, the weight distribution may not be as bad as it first seems. For starters, the battleaxe will have a negligible effect on the left and right or  forward and back balance of the robot simply because it is on the same axis as the wheels (while it is stationary). This means that all is required for correct balance is that more weight is on the left side of the robot than the right. The lance virtually guarantees that this is the case, and even if it didn’t the battery, arduino, receiver would.

When it swings might be a different story. During melee competition the lance will be removed and the battleaxe will be moving very quickly from front to back as it is swung. This will definitely throw the robot off balance front-to-back and the electronics will have to be up to the task of keeping the bot upright. This is a pretty big engineering problem that can only be answered once all of the systems are built and the bot is coded.

The lance is also going to cause problems. It is a relatively large weight and it is very far away from where the axle of the robot is which magnifies the problem. Thankfully I took a few steps to mitigate this issue.  For one, the battleaxe can be moved backwards, opposing the weight of the lance. Also, all of the electronics (besides the servo) are on the back of the robot which helps balance the lance. And as a last resort the battery, probably the heaviest component of the bot, can be moved backwards if necessary.

I do think that the robot will have to have a slightly backwards leaning stance, even with the weight balancing effort I’ve put into the design. Not the end of the world, of course, but might require building a lance that is slanted slightly down so that it will end up level when the bot balances itself. Again this is something that can only be determined once the bot is built.