or How not to win 2,000,000 and have fun doing it.
This is the first in a series of instructables that is intended to be complete documentation of how we built our 2013/2015 DARPA Robotics Challenge Robot (named Buddy in the 2013 DARPA DRC Trials, and Cog-Burn in 2015 DARPA DRC Finals). This first article will discuss the challenge itself and the broad categories for activities. Then later instructables will go through subsystems including software, computer hardware, mechanical systems and lastly management tools and approaches used to create our robot.
All opinions expressed in this series are my own. Other roboticists and computer scientist may disagree but I come by my opinions by 30+years of building robots and experience working with many different engineers and scientists.
The current DARPA challenge is to build a robot that can go into a failing industrial or nuclear facility and help bring the facility back into a safe mode. The most recent example that is often used is the Fukushima nuclear power plant that became dangerous after a tsunami.
This brings up the first criteria of the DARPA Robotics challenge that is difficult to achieve, the robot needs to be human scale, it cannot be a cute little 24 inch robot. This usually means you are going to spend $500.00 or more per Degree Of Freedom(DOF), and you will need about 30 DOF. So some quick math should arrive at about $15,000.00 in parts for joints alone.
The robot needs to be able to interact with an environment intended for humans. This implies that the robot needs some components are like "hands" and other are "feet".
In the DRC Trials in 2013 we used an off the shelf servo. At the time we bought the strongest most affordable servos we could find. In the end we did not find them to be a robust solution and thus the legs in the 2015 Finals are made in a even more component based manor that makes repair cheaper and easier.
The robot was supposed to drive a vehicle, open a door, close a valve, cut a hole in a wall, go through debris or over rubble, then go up some stairs.
Step 1: Choose Your Size:
There is no reason to build a big or heavy robot for the challenge. So our team decided to design toward an average female height and a slight build. This made our design about 4 foot at the shoulder and about 70lbs. And just to make the math easy we chose 1 foot members for femurs, tibia, radius, humurus. This made the torso about 2 feet tall.
Using americans as an example an average woman is 5 foot and 5 inches should be 111lbs at the least, to have a healthy BMI. This is not a target as much as a guide, so 400lbs robots that are 6+ft are not easier to get through a door.
We also choose not to have too much grip strength. Numbers on the internet are about 60lbs for grip strength for womean. Really we go below this to make the robot safe to do things like shake hands. Again this is a guide not a target. More that 60lbs seems extreme and will add power consumption, and require sensors to make sure you don't break things.
Step 2: Choose Your Parts
As I said earlier we chose one type of device for joints but do not believe that was a good choice. So we are not working with VEXRobotics motors, gearboxes, axles, and gears. These are the kind of components that most FIRST robotics teams are familiar with. This also means they are available and durable. The DC motors that we used are connected to a Talon SR motor controller and a LiPo RC car battery (7.4V 5000mah 25-30C). We will add a very specific instructable on this mechanism very soon.
We also have continuous rotation mechanisms that are stepper motor based. The nice thing about stepper motors is that the current to the stepper motors can be limited in the stepper motor controller. This allows you to do things like know that 8 motors running 2A can be used for a certain time on a set of LiPo RC car batteries (14.8V 10000mah 50-60C). An instructable for the swerve steer feet is here.
Gazebo Sim is a tool that allows you to simulate a robot. Each joint is a connection between two members that are rotations in some axis relative to another member. http://gazebosim.org/tutorials has a number of good tutorials to help make this idea clear.
Step 3: Choose the Computer and OS
We choose to use a fit-pc with a solid state drive. But for the DARPA DRC Finals we added a NexCom embedded PC as a field computer. More details on the perception side of our robot will be in a seperate instructable.
We use GNU-Linux Ubuntu 12.04. We could have used 14.04 but some of our code that was written in 2013 relied on features that changed in 14.04 so we did the usual of just leaving development system back a version.
Not to start any IDE wars but really we let anyone use anything they wanted. We are a mostly volunteer effort so we had development using Emacs, Eclipse, Geany (my favorite for windows as well). We do have a seperate make build system so almost any development environment can trigger a build and take you to your errors.
We used git and git-hub for source control. We plan to make public that repository as soon as possible. We have to strip any connection to non-redistributable components.
Most of the code was written in C/C++ using libraries like STL and BOOST, but sometimes we wrote code in C/C++ for Arduinos. More on that in the specific joint, stepper, sensor, and lidar instructables.
Step 4: Choose Your Sensing
We are a fans of simplicity with sensing.
We have high-end lidar, stereo camera, and Intertial Movement Units (IMU) available to use, but really we are focused on only collecting the data we need.
The pressure sensor on the feet are simple pressure sensor like the flexiforce from Sparkfun.
We used two simple netcams (Logitech 720p) but any reasonable resolution will work. Part of the DARPA DRC was interrupted network communications. So a very high resolution camera data is not likely to get through the degraded communication.
We used the 9DOF sensor stick from Sparkfun and the same Arduino collects pressure sensor data from the feet. There will be a separate instructable for this combination of components.
For the DARPA DRC Trials we used a Hokuyo LIDAR UTM-30LN but for the Finals we switched over to the LIDAR Lite from sparkfun. This is a good example of not collecting more data than you need. We collected 270 degrees of lidar data every 20ms with the Hokuyo. Then we had to work to ignore all but a few points in the area of interest. For the finals we closed loop controlled the position of the two head and neck servos so the item of interest, the valve for example, as centered where the LIDAR could measure it. One number every 100ms, not 270 numbers every 20ms where we only want one. The LIDAR Lite weighed less and consumed less power. We would write a seperate instructable but really we used the code off of the github for the sensor and just added some LEDS so we had simple confirmation of the LIDAR Lite working properly. An LED for 1m, 2m, and 3m for example.
What about hand pressure? Already solved the hands are strong enought to grip and operate the drill/cutting tool. Not strong enough to destroy it. So grip as hard as we can, and we are good.
Step 5: Choose Additional Software Libraries:
We are fans of open source. We use Standard Template Libraries (STL), and BOOST libraries. Many of the features we used from BOOST are not part of C++11 so using the latest C++ and STL should be plenty to start.
We use 0MQ and raw UDP for network communication. 0MQ (zeromq) is a nice set of tools to have messages passed between processes across a set of computers. We used it starting in 2013 but added raw UDP sockets because we needed simple fast and transient communication attempts. So the sensor data will make an attempt to make it to the control station, but if it does not, sending updated data is better than trying to resend old data.
We use Open Computer Vision (OpenCV) for recognizing things like valves, door handles.
Then of course if there is a special library, like for interacting with the Hokuyo, we include those build tools as well.
What about GazeboSim? In 2013 we found GazeboSim to be more complicated than we had time for, but in 2015 the latest GazeboSim SDF seems to be more approachable, just the timing on using that tool for our robot did not workout.
Step 6: Build the Mechanical Systems:
The mechanical systems can be seen as the bones of the robot.
In the DARPA DRC Trials we used 3D printing to produce gearboxes, hands, and forearms. Also any piece of structural connection between components. For instance the connection between the "shoulders" and the two neck servos is a relatively simple 3D printed piece.
We have used a variety of 3D printers. We have a Lulzbot AO-100, but the most robust printer we used is a Stratasys. Recent prints on a PrintrBot Simple Metal kit have been impressive. Our rule of thumb is this. If you need the part to be printed constistently and reliably use the higher end machines. If you can tolerate some glitches in printing and some small blemishes, use a consumer grade printer.
In the DRC Finals we found ourselves printing just the the pieces between Laser cut aluminum structural pieces.
Laser cutting. A local manufacturer helped us by cutting many parts for Cog-Burn's legs. Our rule of thumb is to design a piece so the it can be cut out of flat stock and then only have a single bend to make a complete piece.
Mechanical pieces are included in the individual instructables for the feet, legs, hands, and arms.
Step 7: Bring It Altogether and Test:
We then take all the sensors, computer, joints, feet, arm and hands then connect them all together in the design configuration.
- Cameras and LIDAR make up the "head". 2 DOF make up the neck.
- The arms are made up of 5 DOF each. These are 2 rotation joints and 3 angle joints.
- The hands have 4 DOF (yes we skipped producing a 5th finger).
- The torso contains the power distribution, PC Fit-PC, Arduino for the 9DOF IMU and feet pressure sensors. Specifically for the DRC Finals we added a 40A circuit breaker for the E-STOP.
- The legs are 3 DOF each. One old Dynamixel rotation joint, and 2 new VEX robotics joints.
- The feet are 2 DOF each. Stepper motor wheel control.
Testing is where we failed. We redesigned the legs too close to the DARPA DRC Finals to have them fully tested before the competition. Really no way around taking this complicated machine and putting through its paces before you need to put it through its paces in front of the world. We knew the change would likely make us fail but felt we had no alternative that would plausably work.
Step 8: How We Did, Why You Should Read This Instructable
Our team scored a 0 so if you build this robot realize you are building a robot that did not score any points at the DARPA DRC Trials or Finals.
I can understand someone who would say "Why would I follow this instructable?". The answer is simple. First if you read through this and see the errors of our ways we have saved you some time and effort. Secondly though the subsystems do work. They could work better. Our goal is to see a set of instructables that could build a human scale robot reliably for around $5000.00. There may be some updates to this set of instructables that make this goal happen sooner than if we kept all the details, even the ugly ones, to ourselves.