Robotics Logic Development Platform

From OMAPpedia

Jump to: navigation, search

[edit] Proposed Development

One balancing robot ready for your commands!
Why spend the extensive time and money researching and developing an advanced robotics platform when what you really want to do is give commands. Move forward 1 foot at 3 inches per second. Turn 180 degrees in a 5 foot radius turn at a speed of 1 foot per second. You also want a significant sensor platform to pull real world data from. No, not how far is there 'something' infront of us. You want to know what is around you. You want to know what is going on. You want to know what you are doing. And you don't want to reinvent the wheel finding out!
I am working on developing an inverted pendulum robotics platform with an extensive sensor array integrated into an economical package so you can write the code and see the results without having to build C3PO from scratch! Having an environment where extensive data integrated over the entire sensor array is available at your finger tips. And where you only have to say the word for a full logical action to take place without worrying if the thing will fall over just to spite you!
Reasoning of Design
I chose an inverse pendulum design for the limited ground contact and for the smaller foot print. Having only two wheels on the ground keeps you from shaking around with a caster wheel, or worse, simply dragging a leg. By having the wheels two inches larger in radius than the round platformed body we can reduce the cances of ramming a wall with the body of the robot. With the smaller foot print we can turn in place and not worry about running over something we have so far avoided. ie. If we haven't hit it yet and we are just turning in place we are safe, less any manipulators.
The platform design was used to give the maximum space available to people who wish to add onto the robot. It also gives mounting points for sensors such as ultrasonics, laser range finders, and pressure pads. It is also a nice shelf for the 26 AH battery used to power the motors. New sensors can be fashioned either on a platform or across a strut harp, a mostly vacant mounting sheet that slides over two adjacent struts.
The sensor package is based on the maximum amount of data we can collect with reasonable if not down right cheap components that work. The sensors all overlap in some manner giving us either a confirmation of what another sensor said or a bias towards the correct answer. Using kalman filtering we can integrate sensors into useful real world data instead of readings. I have also done development of my own to expand the capability of the existing sensors by bringing new ideas on how to use the existing technology to provide new and non-trivial data to the programmer.
General Design
The chassis is to be a vertical series of platforms connected together with with vertical struts. Though not shown in the very rough mockup of the chassis there will also be cross supports between some of the struts to prevent rotational travel between platforms. The platforms are as follows:
- The motors should be mounted on the under side of the bottom platform. This is to reduce the chance of the bottom platform from dragging in high speed runs and to sheild the platforms from much of the EMFs that are produced.
- The brain will be mounted on the top of the bottom platform. With a daughter board monted to the PandaBoard we want the accelerometer and gyroscope sensors as close to the wheel pivot points as possible. We also want the sensors to be as close to the center of the platforms as possible thus the accelerometer and the gyroscope sensors will be mounted on opposite sides in the center of the daughter board.
- The second platform is, for now, void and present for future development by the community.
- The third platform will hold the majority of the external sensors, sensors not on the daughter board. On bottom it will hold a webcam that is centered left to right and pointed forward with a known distance between the platform and the center of the lense. The top side will hold the forward and rear facing ultrasonics along with the aiming mechanism that holds a line laser at a known height above the platform.
- The fourth platform will be dedicated to our battery as a power source for our motors as well as our dead weight for locomotion.
- The top platform is reserved for development of a manipulator. Potentially a multi-joint arm that can spin 360 around the top. After all, what fun is a robot if all it can do is run around in circles. Lets move things!!!
Sensor Technology
Dynamic Range Infrared Laser Range Finding Scanner
Using a laser pointer and a web camera both aimed in the same direction with one directly over the other it is possible to calculate the distance to the object the laser is hitting. This requires calibrating against the lens of the webcam, which can be done automatically with the use of ultrasonics, and knowing the distance between the camera and the laser. As the object the laser is hitting gets closer the further from the horizontal centerline the point appears on the camera. The remainder is basic trig. There are many limiting factors to this technique:
- The laser pointer is a single poing and a single measurement
- If the laser doesn't hit the object then the camera doesn't see the object
- The laser is always pointing in the same direction
These can be overcome by using a line laser. This will give a distance for every column of pixels in the image. With the laser always pointing horizontally we don't get much usefull data than what objects are as tall as us and in front of us. By tilting the laser towards the camera we make the math harder but we get much more information. We get a distance to the object as well as how high off our plane of ground the object is. We are still only looking at one spot but by rolling around we can form a 3D image.
Though we now have 3D images of our environment we still have to get x distance away from an object to see it. This can be overcome by varying the angle at which the line laser is shot. Thus we can scan the horizon for a general point of perspective in the land but then we can scan layers closer to the bot getting finer 3D detail as we aim further down.
Compensated forward and rear facing differentiating ultrasonic range finder
Ultrasonic range finders have been the common tool for most robotic projects that cover more than a few inches. Click a pulse and wait for an echo. The ranges can be as great as 15 or even 30 feet for some basic setups. This still only gives us the information that there is something x distance away from us. What if we could get more detail from the sensors. How about getting a crude 2D image of the soroundings!
By placing an ultrasonic transciever on either side of the robot facing in the same direction we can start to do just that. By sending a signal out with one transciever and waiting to listen with both we can get a distance from the transciever that transmitted the signal to the object and back as well as the distance from the same transciever, to the object, and back to the second transciever. We can divide the first signal in two to give us the time of flight to the object from the transmitter. We can also subtract that result from the second time giving us the time of flight from the object to the second transciever. Using basic trig we can calculate how in front of the robot the object is and on which side of the robot the object lays.
The down side to ultrasonics is how sensitive the speed of sound is to temperature and humidity. We can see up to a half inch change with a single degree of fahrenheit change. To adjust for this we can take reading along the metal of the robot. Some people claim that a piece of metal is colder than the air but in reality it is simply more efficient at heat transfere and thus very close to room temperature. Humidity also effects the speed of sound in air. This is compensated with a hydrometer.
Pressure sensors for grip and body torque
If we place a manipulator on an inverted pendulum robot most people would think it should simply fall over. The force the arm applies to the robot that we care about will always be in a stright line going forwards or backwards from the aim of the robot. By mounting the manipulator in such a way as to measure the force from a distance of the mounting point the torque on the mounting point can be computed. With the knowledge of the torque and the position of the mounting point we can compute the torque on the base of the robot, the center of gravity of the robot and manipulator, and the offset angle the robot would need to be at to balance. With a simle pressure measurement we can do away with trying to balance the robot with an accelerometer and gyroscope alone.
Tripple axis flux magnetometer
Magnetic north. Great reference for a heading ... if you are no where near ferous metal. So it is hopeless for robotics and metal boats. Wait! This problem was solved. By placing ferous metal perpendicular to the axis of distortion the distortion can be eliminated. By placing a flux magnetometer in the center between two of the metal platforms it will not only correct distortion caused by the platforms but also sheild us from the motors 2 platforms below and the battery two platforms above! I can't claim as to how effective the z axis flux magnetometer will be but that is what testing is for.
Tripple axis gyroscope
Hmm... A balancing robot. Must need to know which way is up. We can use an accelerometer but then we have to compensate for our acceleration. If we use a gyroscope that is tared off an accelerometer then we can get the same data for half the effort. We can also use it to keep track of our heading when our compas goes astray from nearby cabinets and pillars. And, should we pick something up that tips us onto a single wheel we can sense that as well. And, lets not forget, if we are on our side we don't want to try and get up. Will cause rug burns, damage to the wall, and a nasty headache for the robot.
Tripple axis accelerometer
Knowing which way and how strong gravity is can be so handy. If we are pitched at an angle and know the angle and magnitude of the acceleration vector we can easily compute our forward acceleration by subtracting gravity by the inverse offset of the pitch. Why stop there! By monitoring the full 3D vector, along with the forward velocity, we can monitor side acceleration and compute the radius of the circle we are traveling in! We can even integrate the readings and keep a second look at our velocity to proof against a potential spinning wheel.
Battery voltage measurements
Why let noice bark in your processors? Using a small Lithium Ion battery, about the size of the PandaBoard, we can power all our electronics, less the motors, for 9+ hours! Using a sealed lead acid battery of 26 AH for the motors we not only get high current with long life, we also get a great weight for the top of the robot! More weight at the top means less of a needed angle for acceleration as well as more torque! Thus we minimize the noise to ultrasonics and a few servos. Even then, we can put thoes on the sealed lead acid battery if it causes problems. Aren't non-spillable batteries wonderful!
Fluid Flow Via Webcam
Though not slated for this project I would like to explore fluid flow imaging. The process of taking sequential images, finding significant points, and computing the change in those points to discover how close the points are in space, where they are located, and how fast they are moving in relation to yourself. I don't know if a single PandaBoard will be up for such a daunting task but I am sure two would not even blink! This could be a potential addon after further development on the subject has taken place. But for now it is an interesting a potentially fruitful pursuit!

[edit] Original Prototype

Significant Parts
- One NSLU2 (Linksys Network Storage Link for USB 2.0) w/ modifications
- One Tamiya 70168 Double Gearbox kit
- One Tamiya 70145 Narrow Tire Set
- One Tamiya 70144 Ball Caster Kit
- Two CSB 6V 4.5 AH CF-6V4.5 Sealed Lead Acid Batteries
- Four Microchip PIC16F88 MicroControllers
- One Analog Devices ADXL203 Dual Axis +/- 1.7G Accelerometer
- One ST Microelectronics LISY300AL Single Axis Gyroscope on a SparkFun breakout board SEN-08955
- Two 5mW 650nm Red Line Lasers in Full Brass Case off of E-Bay
- Two custom built FET based DC Motor Drivers free formed off 8 pin dip sockets - FET Mouser PN: 781-SI4559EY-T1-E3
- Two 3A 5V LDO Regulators w/ external shutoff pin sharing a small heat sink
- Three 5V 1A LDO Regulators - PN apperently has been obsoleted but was Mouser PN: 879-UPC2905BHFZ NEC PN: UPC2905BHF-AZ
- Three 3.3V LDO Regulators w/ external shutoff - PN apparently has been obsoleted but was Mouser PN: 879-UPC3033HZ
- Two 40KHz 55 Degree 1 KOhm Kobitone 255-400PT16-ROX Ultrasonic Transceiver - Unused and undeveloped so far
- One 40KHz 15 Degree HC-SR04 Ultrasonic Ranging System from IteadStudio.Com - Impulse buy but progressed project
- One Gigaware 25-157 Web Camera
- One Cheap Ball Mouse from RadioShack
- One 9"-ish circle platform composed of Masonite Board
- One 9"-ish circle platform composed of aluminum sheet metal
- Extensive use of 3M's Industrial Velcro
Modifications to Significant Parts:
- NSLU2: Replaced each of the two USB ports with dual layer USB ports and pulled the signals from elswhere on the board. Pulled the I2C port from the board to a 1/8" stereo headphone jack on the front of the case. Glued a generic USB WiFi adapter that had been removed from it's enclosure to a battery holder on the NSLU2 and ran USB signals from the board. Added a power monitor IC to between the incoming power, ground, and the input to a flip-flop that controls power to the board.
- Dual Gear Box & Cheap Mouse: Disassembled mouse and extracted the encoders. Sawed off the shafts on the encoders and drilled holes to precision fit the shafts of the gear box. Installed encoders between gear box and housing. Extracted optical components of encoders from the mouse and fashioned a mount on the masonite platform in which the gearbox is mounted.
- Accelerometer: Chissled out the center of an 8 pin dip socket to fit the accelerometer. Glued accelerometer upsidedown into the socket before soldering the pins of the accelerometer to the socket. Added a dual op-amp to the output of the accelerometer with fine tuning. Placed at the center top of masonite platform.
- Gyroscope: Applied an upward facing header. Placed gyroscope upside down at the center bottom of the metal platform.
- Line Lasers & Web Cam: Modified a piece of solid cylindrical plastic to mount on the top of the masonite platform flush with the front lip. Poked three holes in the plastic. One to hold a line laser at a specific distance up off the platform at a level angle. One to hold the second line laser at a downward angle a specific distance off the platform. And a third in the center bottom of the plastic to mount the webcam after the base has been removed on the underside of the masonite platform.
- FET Motor Controller: A free form motor controller was designed utilizing 6 fets, 2 diodes, 2 H-Bridge FETS, and several resistors on an 8 pin dip socket.
Software Interface:
The NSLU2 is running a Debian Linux distribution at a current revision of Lenny. The WiFi interface is programed to connect to a number of potential WiFi hotspots including a WiFi router that I cary when heading to a new location. Development takes place by SSHing into the NSLU2 over WiFi. All development has been in C. There is a small program for each PIC to connect to the user space I2C interface and pull data. This data can be placed into the MySQL database for logging or can be used to make decisions. There are also secondary programs for any PICs that have controls the NSLU2 can output to, such as the drive pic.
Software Modules:
- accelerometer -- reads current acceleration, velocity, distance, and position. Velocity, distance, and position are integrated from acceleration.
- accelerometer_w -- resets velocity, distance, and/or position.
- drive -- controls speed and direction of the differential drive. Also resets distance and position.
- odometery -- reads current acceleration, velocity, distance, and position. Acceleration and velocity are based on the derivative of the odometer. Position is integrated from odometery.
- power_gyro -- reads current rotational acceleration, velocity, and heading. Acceleration is based on the derivative of the velocity. Heading is integrated from velocity.
- power_gyro_w -- sets a timer to kill main power to the robot after a short period to allow the NSLU2 to shutdown. Also can reset the heading.
- print_lcd -- writes a string out to an LCD module that is not normally connected to the robot.
- ultrasonic -- reads current acceleration, velocity, and distance. Acceleration and velocity are based on the derivative of the distance.
- web_cam_scan -- reads either the long or short range laser path returning a depth and height for each column of pixels on the web cam. Height is based on the objects surface being perpindicular to the surface of the ground.
The following image gallery is of the previous revision boards. Much cleanup has occured and some hardware has been changed out. A newer gallery will be up soon with the latest photos. Sorry for the blurry images, older cell phones aren't the best for close up images.
Personal tools