Details
Executive Summary
When powered-up, Atlas will calmly wait for you to place a ball on the center of the platform and push the bump switch. This lets it know that the color of the ball is ready to be measured and the color tracking system should be calibrated accordingly. Once Atlas is ready to move it will let you know via the lcd display. This gives the user the opportunity to get out of the way before witting the bump switch one last time to send the robot on its way. While moving, Atlas will be looking for obstacles by using two sonar devices and a bump switch. If Atlas detects anything directly in front of it, he will move to avoid it. In order to balance the ball a vision system was used. This system tells Atlas where the ball is. Atlas can then determine the velocity of the ball from previous position values. It is these two variables (position and velocity) that determine the orientation of the platform.
Introduction
Balancing a ball on a platform is a classic example of a control dynamics problem. This problem is of particular interest because the system is unstable, meaning that once the ball is moving it will roll off the platform if no action is taken. This as opposed to a stable system, such as a ball in a bowl, where if the ball is nudged it will simply oscillate. I chose this project to show that a robot could be made to be as sensitive as a person is to this type of control problem. If you were given a ball and a plate and asked to keep the ball from falling off, you would be able to do it without even considering the complicated mathematics that you are undoubtedly performing.
Integrated System
Atlas is controlled by a Atmega128 processor that is part of the Mavric IIB. This micro-controller is interfaced with many other sensors and actuators that allow Atlas to accomplish his task. The bump switch and sonar sensors data are read by the micro-controller which then decides the speed and direction of the motors. The data from the CMUcam is also read by the camera and the servos are then controlled by the micro-controller. A block diagram of the communication between devices can be found below.
Mobile Platform
Atlas has two types of actuation systems, one for ball balancing and the other for locomotion.
Ball Balancing
This was the most mechanically challenging part of building this robot. I considered many options but eventually decided that using two servos located on each axis was the best way to do it. The servos were placed at the edge of the platform and two arms were used with another mechanical piece that I made to allow each servo to move with out interference from the other servo. Below are pictures of this system
Obstacle Avoidance
This actuation was much easier to develop. I simply added a beam through my robot to mount the motors to. I also added a caster wheel to front of my robot. Sometimes this caster wheel will get stuck and cause Atlas to stop, But this happens infrequently and a little push will get it started again.
One lesson that I leaned is to buy motors with metal gears. I stripped both of my plastic gear motors within an hour of getting them.
Sensors
Atlas was built using three different types sensors:
Vision
For the image processing system I chose the CMUCam. More Information on this device can be found in my Special Sensor Report.
Sonar
The sonars that I used are two SRF08. I chose these because of there I2C interface. Having never used I2C, I was curious as to how it worked. I must say from my experience with the sonar, that they are a little hard to get set-up correctly. I had to add a capacitor to the power input in order to satisfy the sonar’s instantaneous need for current when it would ping. Otherwise I would get errors.
After I got them working correctly, they produced very good data. It’s rare that Atlas doesn’t detect an obstacle before hitting it.
Bump Switch
For those few and far between times when the sonar doesn’t see something, Atlas will need to know when it’s touching something. For this reason I attached a long stick to a limit switch and mounted it to Atlas’s camera arm.
Behaviors
Atlas performs two behaviors, ball balancing and obstacle avoidance. Both of which are completely independent of each other.
Ball Balancing
This, by far, was the most complicated and hardest part of this robot. Balancing a ball on a platform is really child’s play, for us. For a robot though, everything has to be broken down into numbers that it can perform math on. What Atlas needs to needs to know in order to control the ball is at most, three things; position, velocity, and acceleration. Since velocity and acceleration can be derived from position, that is the only real measurement that Atlas needs to make. So the ball balancing behavior goes as follows:
-
-
-
-
1.1.Take position measurement from camera.
-
2.2.Derive velocity from previous position measurements.
-
3.3.Multiply them both by constants and add them together.
-
4.4.Move the servos to the new position.
-
-
-
This algorithm works so well that I didn’t even need to add acceleration to the equation. The ball usually settles within a few seconds.
Obstacle Avoidance
obstacle avoidance was a mush easier task to complete. Motor speed and direction were controlled by sonar and bump switch values. The behavior for obsticle avoidance goes as follows:
-
-
-
-
1.1.Ping sonar.
-
2.2.Read sonar and bump switch values.
-
3.3.If sonar reading is below a given threshold or if bump switch is pressed, stop.
-
4.4.Back up.
-
5.5.Turn in the appropriate direction.
-
6.6.Move forward.
-
-
-
When the above actions require a change in motor speed, a smoothing function is applied to make sure Atlas doesn’t change direction too quickly. This provides a much nicer environment for the ball balancing behavior.
Conclusions
I am very happy to say that Atlas does almost everything that I wanted it to do. I can place a ball on top of the platform with little fear of it falling off. If I were able to redo this project, I would do some things differently. First, and most importantly, I would not use the CMUcam. This, by far, is the weakest link in Atlas. Whenever Atlas does drop the ball, most of the time it is because the camera was unable to find it correctly. I’ve tried illuminating the platform with a few different methods but was unable to find a method that would create even and consistent lighting conditions across the entire platform.
Another thing that I would do is spend more time on the control algorithm. Most of the time the ball will not return to the exact center. There is usually some error that I blame on a variety of things; such as the ping pong ball having a large seam and the friction between platform and the ball. Dynamically changing the coordinates of the center position would allow me to program Atlas to “draw” shapes with the ball. Unfortunately I was unable to control the ball precisely enough to do that.