Long time without posting because I have been focusing entirely on preparing the swarm for the challenge. At some point I do blog entries on the thoughts and activities that went into the project. I will backfill them just to keep the timing straight.
I have received a lot of assistance from vendors. Some in discounts and some in sharing knowledge. One I want to specifically mention is David Gray of ProgressiveRC. David answered a lot of questions about batteries and the wiring I will need which was very helpful. ProgressiveRC is providing a very nicely cased set of chargers - the Double Sidekick Ticket - for the batteries, and special ordered 10.4 Ah batteries. There will be two of those in each member of the swarm.
Pololu provided discounts on a Simple Motor Controllers, Maestros, Wild Thumper 6WD, and other parts and pieces.
The last part of the puzzle is picking up the samples. I have the design concept and it works. I even have a video. I have a kludge for this on the current robot but it is pretty ugly. Looking at using tilt mechanisms from ServoCity. Might also need to use some of their construction beams.
I just looked at the hit rate for this blog and it is doing better than I thought. There are 25,000 or so hits. It would probably be a lot better if I were keeping it current but I am awfully busy with the project itself.
09 April 2013
17 November 2012
Frustrating Week
It has been one of those weeks where you take three steps forward and two steps back.
I got the computer for the prototype. I is targeted at installation in a car. The case is a heavy (!) aluminum with fins for cooling when installed under a car seat. The overall weight is 7-8 lbs. I wanted to order a COTS computer so save time and effort. I need to be working on software, not messing with hardware, either robotic or computers. But I didn't check out the weight when I ordered this beast. The Wild Thumper is supposed to handle an 11 pound payload.
I have the Pololu Simple motor controllers working and can control the motors either using RC or a computer. I ran the Thumper around the front yard and in the street using the RC control. I am on a cul-de-sac and there is an island in the middle of it. The Thumper limbs the curb nicely. Shouldn't need that with competition but nice to know it has that power.
I put the controllers on the Thumper platform along with some euro-type terminal strips for power distribution. Then reaaranged all of that to mount the computer. And reaaranged it all again for another reason. That was at least 0.5 step back.
I tried running the robot under RC control with the computer mounted. That blew the motor controllers. I know they were marginal but I had them on hand. They are rated for 7 amp continuous and higher for stall current. The three motors on the side of the Thumper are rated 7 amp stall for a total 21 amp stall. I thought the controller configuration for acceleration ramping would limit that current. It didn't. Ordered some new higher power controllers to see how they work.
Also worked with the Pololu IMU. That was another step backwards. The IMU generates output faster than can be read using the USB-I2C adapter on the computer. The slowest the IMU generates output is 100 readings per second. The system would need to read 6 data points (3 gyro and 3 accelerometer) at that speed to keep up. There is a FIFO capability so up to 32 readings could be buffered and read in bursts. Basically, I did not want to mess with it. In part because I though my time would be better spent on some other problem.
I found that Phidgets has a series of USB devices that includes spatial sensors. They are configured specifically for connecting to PCs. Their software capability looked interesting and they supported C/C++ on Windows. I ordered their 1042 basic motion sensor. In a few hours on Friday night I wrote the code to set the configuration and acquire data.
The 1042 has a gyro, accelerometer, and compass. I cannot use the compass in the competition. The sampling rate is set through software. The 1042 internally accumulates readings for the specified sampling period. That simplifies using it. That is one of the steps forward after a step backward.
If I had not just ordered the new Pololu motor controllers I would be tempted to order a Phidgets motor controller. The Phidgets' software stack is all integrated so using one type of device shows how to use any of the other devices. (In fairness, the Pololu controllers do the same. Getting the Simple controllers working was easy after using a Maestro controller.)
Back to the computer and its weight. I have another ITX case from an earlier project. The mother board and hard drive are easily moved to it. But the power supply from the car computer won't fit in the case. I need to decide if I should get a power supply that would work and make a lighter computer. Of course that is exactly what I was trying to avoid - building up the computer hardware.
Another piece of electronics I got working was a key fob RF transmitter and its companion receiver board. It operates on 422 mHz. A robot for the competition must stop all motion within 1 second of the press of a remote control button by the judge monitoring the robot. (In a swarm, all the robots must stop!) I have a concern whether these will work acceptably in the competition. Apparently one team last year had problems with their RF pause button and had to switch at the last minute to RC control. That would be nearly impossible to do for a swarm of robots. To many last minute changes. Regardless, I need something for the prototype so this should work for now.
The receiver connects to the Simpler controller's analog input. The controller can be configured to automatically stop the motors when the signal is received. Both the analog input value and an status bit can be read by the PC so the robot knows of the pause request. The robot can then shut down any other moving parts, such as a picker or panning camera.
Speaking of camera, I took a number of pictures in local parks. One park had a construction area with orange mesh fencing so I got a number of pictures of it. That type of fencing is used to mark the perimeter of the competition area. The robot has to avoid getting to near the fence of the judge will stop it. Also got picture of some lamp posts and pavilions with columns. The competition area has similar features that can be used for localization.
Now to see what happens with the computer on the robot with the new motor controllers. Fingers crossed!
I got the computer for the prototype. I is targeted at installation in a car. The case is a heavy (!) aluminum with fins for cooling when installed under a car seat. The overall weight is 7-8 lbs. I wanted to order a COTS computer so save time and effort. I need to be working on software, not messing with hardware, either robotic or computers. But I didn't check out the weight when I ordered this beast. The Wild Thumper is supposed to handle an 11 pound payload.
I have the Pololu Simple motor controllers working and can control the motors either using RC or a computer. I ran the Thumper around the front yard and in the street using the RC control. I am on a cul-de-sac and there is an island in the middle of it. The Thumper limbs the curb nicely. Shouldn't need that with competition but nice to know it has that power.
I put the controllers on the Thumper platform along with some euro-type terminal strips for power distribution. Then reaaranged all of that to mount the computer. And reaaranged it all again for another reason. That was at least 0.5 step back.
I tried running the robot under RC control with the computer mounted. That blew the motor controllers. I know they were marginal but I had them on hand. They are rated for 7 amp continuous and higher for stall current. The three motors on the side of the Thumper are rated 7 amp stall for a total 21 amp stall. I thought the controller configuration for acceleration ramping would limit that current. It didn't. Ordered some new higher power controllers to see how they work.
Also worked with the Pololu IMU. That was another step backwards. The IMU generates output faster than can be read using the USB-I2C adapter on the computer. The slowest the IMU generates output is 100 readings per second. The system would need to read 6 data points (3 gyro and 3 accelerometer) at that speed to keep up. There is a FIFO capability so up to 32 readings could be buffered and read in bursts. Basically, I did not want to mess with it. In part because I though my time would be better spent on some other problem.
I found that Phidgets has a series of USB devices that includes spatial sensors. They are configured specifically for connecting to PCs. Their software capability looked interesting and they supported C/C++ on Windows. I ordered their 1042 basic motion sensor. In a few hours on Friday night I wrote the code to set the configuration and acquire data.
The 1042 has a gyro, accelerometer, and compass. I cannot use the compass in the competition. The sampling rate is set through software. The 1042 internally accumulates readings for the specified sampling period. That simplifies using it. That is one of the steps forward after a step backward.
If I had not just ordered the new Pololu motor controllers I would be tempted to order a Phidgets motor controller. The Phidgets' software stack is all integrated so using one type of device shows how to use any of the other devices. (In fairness, the Pololu controllers do the same. Getting the Simple controllers working was easy after using a Maestro controller.)
Back to the computer and its weight. I have another ITX case from an earlier project. The mother board and hard drive are easily moved to it. But the power supply from the car computer won't fit in the case. I need to decide if I should get a power supply that would work and make a lighter computer. Of course that is exactly what I was trying to avoid - building up the computer hardware.
Another piece of electronics I got working was a key fob RF transmitter and its companion receiver board. It operates on 422 mHz. A robot for the competition must stop all motion within 1 second of the press of a remote control button by the judge monitoring the robot. (In a swarm, all the robots must stop!) I have a concern whether these will work acceptably in the competition. Apparently one team last year had problems with their RF pause button and had to switch at the last minute to RC control. That would be nearly impossible to do for a swarm of robots. To many last minute changes. Regardless, I need something for the prototype so this should work for now.
The receiver connects to the Simpler controller's analog input. The controller can be configured to automatically stop the motors when the signal is received. Both the analog input value and an status bit can be read by the PC so the robot knows of the pause request. The robot can then shut down any other moving parts, such as a picker or panning camera.
Speaking of camera, I took a number of pictures in local parks. One park had a construction area with orange mesh fencing so I got a number of pictures of it. That type of fencing is used to mark the perimeter of the competition area. The robot has to avoid getting to near the fence of the judge will stop it. Also got picture of some lamp posts and pavilions with columns. The competition area has similar features that can be used for localization.
Now to see what happens with the computer on the robot with the new motor controllers. Fingers crossed!
25 October 2012
Challenge On!!
NASA has announced the Sample Return Robot Centennial Challenge is ON for June 2013. It is again a Worcester Polytechnic Institute. The rules appear to be basically the same as the June 2012 challenge. Prizes are similar but there are $500 awards for showing up with a competitive robot and another if the robot picks up the cached sample. I'll read the rules more carefully to see if anything else is changed.
Now I have to decide if I can do this on my own. The registration deadline is 7 January 2013 which gives me ten weeks to answer all the open questions.
I did order a Dagu Wild Thumper 6WD from the Robot Shop. Should be here next Monday.
I have two Pololu Simple Motor Controllers that I bought during a sale last November. I worked with a Pololu Maestro Servo Controller with my iRobot Create so have the basic Pololu control protocol working with a C++ Maestro class. In the last couple days I added a PololuSimple class, and a PololuBase class to generalize between the Maestro and new class, and can now talk to the Simple Controller. Those two controllers will go onto the Thumper. Their amperage rating is marginal for those motors but should be okay as long as there aren't any sudden reversals in direction.
I will probably use the Maestro to handle servos either for the picker or positioning cameras.
Oy vey! Lots to think about in a short period of time.
The more I looked at the Thumper the more I liked the idea of a swarm based on it as the platform. I added some additional analysis tonight to the swarm section and have at least one more page to finish on communications. I am focusing on a swarm of two searcher and five collector robots. There is a lot to recommend this, as some of the analysis shows, but it does introduce some complexity by requiring communications and replicating that many robots. A big advantage in using the Thumper is removing the basic locomotion capability from the design.
Now I have to decide if I can do this on my own. The registration deadline is 7 January 2013 which gives me ten weeks to answer all the open questions.
I did order a Dagu Wild Thumper 6WD from the Robot Shop. Should be here next Monday.
I have two Pololu Simple Motor Controllers that I bought during a sale last November. I worked with a Pololu Maestro Servo Controller with my iRobot Create so have the basic Pololu control protocol working with a C++ Maestro class. In the last couple days I added a PololuSimple class, and a PololuBase class to generalize between the Maestro and new class, and can now talk to the Simple Controller. Those two controllers will go onto the Thumper. Their amperage rating is marginal for those motors but should be okay as long as there aren't any sudden reversals in direction.
I will probably use the Maestro to handle servos either for the picker or positioning cameras.
Oy vey! Lots to think about in a short period of time.
The more I looked at the Thumper the more I liked the idea of a swarm based on it as the platform. I added some additional analysis tonight to the swarm section and have at least one more page to finish on communications. I am focusing on a swarm of two searcher and five collector robots. There is a lot to recommend this, as some of the analysis shows, but it does introduce some complexity by requiring communications and replicating that many robots. A big advantage in using the Thumper is removing the basic locomotion capability from the design.
21 October 2012
Thinking About the Challenge - Hardware
Continuing my summary of thought over the last few weeks, I'll consider the hardware platform. This is not the final platform for the challenge. There are two major issues that need to be settled:
- Swarm or singleton,
- Picker and, related, storage of samples on the robot.
Despite those uncertainties I need an outdoor capable platform to start work on the software tasks discussed in the previous article. One of the interesting ones I'd like to accomplish is proceeding to a potential sample. Keeping the vision processing on the sample while driving the robot is, hopefully, non-trivial but requires a lot of detail chasing. The work on the vision processing should help my understanding of how to locate samples.
The requirements for the robot are:
- Capable of driving in a park type setting, e.g. no major rocky areas, some obstacles like trees and benches.
- Large enough to carry:
- One or two cameras, possibly on a 1-2 meter tall mast,
- A PC class system with Wifi,
- A prototype picker (thinking ahead a bit.),
- Sensors for orientation and obstacle avoidance.
- Drive at 2 meter / second since that is a possible speed during the challenge.
The robot may not need to carry all of the items listed above at the same time since some are only needed for specific experiments. For example, only a single camera may be needed when used to guide the picker toward acquiring a sample.
I've gone through various vendors and reached a tentative conclusion on what to get. I rejected the simple 4 wheel platforms mounted on a solid box chassis. Most are a little smaller that I liked and while they do well for scampering around a yard I have my doubts about them in an environment with tree roots. Specifically, I don't think they will be sufficiently stable for testing when working with the cameras. Ground clearance might also be a problem.
I considered a tracked platform such as the Lynxmotion Tri-Track because it is so neat but it suffers from the same problem as the square platforms.
The platforms I mention on the hardware technology page are very appealing but just cost to much for a platform that is only for experimentation.
Wild Thumper 6WD |
I am strongly inclined toward the Dagu Wild Thumper 6WD (wheel drive) available from many shops - Robot Shop, Pololu, and SparkFun - to name a few. One reason for naming all of them is the documentation on the platform is different on each site. By checking all of them I got a better idea of the capabilities.
The Thumper is a good size (16.5" x 12" x 5") without being gigantic, i.e. it fits on a workbench and can be handled by one person. The suspension and ground clearance (2.5") look good. The carrying capability is 11 lbs so it should handle the devices listed above. Its speed in the 1:34.1 gearing is 7 km, which is around 2 m/s. That is probably unloaded but close enough it will give me a feel for the problems of controlling a robot at that speed.
After considering it, I started wondering if it wouldn't make a good platform for a swarm using it and maybe its little brother 4WD version in combination. Since it weighs 6 lbs and can carry 11 lbs for a total of 17 lbs, there could be 10 of them in the swarm and still meet the total weight limit. Not that I can imagine setting ten of them loose for the challenge. The organizers would probably shoot me for requiring the ten judges to keep an eye on each robot.
Thinking About the Challenge - Software
Despite nothing appearing here for awhile I have been thinking about the SRR Challenge. I had a week in Mexico and a week with a cold that kept me from writing. Now I am back to making some progress. I'll summarize some of the thoughts, possible plans, etc. No additional analysis, but there are some things that need to be looked at based on my thoughts.
As I look at hobby robot builders web sites I've concluded that most build a nice piece of hardware that doesn't really accomplish anything real. I've seen some beautiful robots that are the delight of machinists. But there is no mention of any software driving them that makes them meaningful. As I looked at the robots from the 2012 SRR Challenge competition I wonder how many of them spent many hours on the hardware and let the software go until the last minute.
I know from experience in embedded systems development that the hardware is always late. Since there are limits to what can be accomplished in software when you don't have even the preliminary hardware that makes the software late. (And software gets the blame for the project being late!)
I am going to avoid this trap by focusing on the software first. Still, I need some hardware to make progress but that is for the next entry.
I've thinking about the actions the robot needs to accomplish. Some of these are trivial, some need a lot of detail chasing but are straightforward, others are challenging, and still others are possibly beyond my capabilities.
If there are any of the last group I probably cannot enter a credible entry into the challenge. I won't know until I try. A prime example of this is using the vision processing to identify samples at a distance. Another is maintaining the location of the robot in the search area so (1) all the area is searched and (2) the starting platform can be located so samples can be returned properly.
The trivial items are the basics of controlling the robot:
As I look at hobby robot builders web sites I've concluded that most build a nice piece of hardware that doesn't really accomplish anything real. I've seen some beautiful robots that are the delight of machinists. But there is no mention of any software driving them that makes them meaningful. As I looked at the robots from the 2012 SRR Challenge competition I wonder how many of them spent many hours on the hardware and let the software go until the last minute.
I know from experience in embedded systems development that the hardware is always late. Since there are limits to what can be accomplished in software when you don't have even the preliminary hardware that makes the software late. (And software gets the blame for the project being late!)
I am going to avoid this trap by focusing on the software first. Still, I need some hardware to make progress but that is for the next entry.
I've thinking about the actions the robot needs to accomplish. Some of these are trivial, some need a lot of detail chasing but are straightforward, others are challenging, and still others are possibly beyond my capabilities.
If there are any of the last group I probably cannot enter a credible entry into the challenge. I won't know until I try. A prime example of this is using the vision processing to identify samples at a distance. Another is maintaining the location of the robot in the search area so (1) all the area is searched and (2) the starting platform can be located so samples can be returned properly.
The trivial items are the basics of controlling the robot:
- Controlling the motors to drive where needed,
- Read sensors to determine orientation (gyroscope),
- Drive servos for positioning the picker or cameras,
- Etc.
- Drive to a potential sample that was located,
- Etc. (Which means I haven't identified these.)
Challenging items...well, I'm not sure yet. More analysis is needed to identify these.
03 October 2012
Another NASA Rover
CREDIT: NASA/Ames Research CenterView full size image |
[Lagrange points are stable locations caused by the gravity fields of an object orbiting another object, in this case the Earth and Moon. An object at a Lagrange point is held in place by the gravity fields. See Wikipedia for more details.]
Anyone have more information on this rover?
18 September 2012
DARPA LAGR Project
Today I was looking through some robotics papers applicable to Sample Return that I previously found on the web. One mentioned they were using a DARPA LAGR robot so I looked to see what it was. I found that Carnegie Mellon was involved in producing the standardized robots. The idea was to provide these robots to different researchers, have them develop navigation software, and have them compete on real-word runs to see what went better. The robots only had vision, GPS, and bumper sensors. The outcome of this project seems very applicable to the SRR competition.
One of the researchers at NYU has a long list of papers on navigation.
One of the researchers at NYU has a long list of papers on navigation.
Subscribe to:
Posts (Atom)
SRC2 - Explicit Steering - Wheel Speed
SRC2 Rover This fourth post about the qualifying round of the NASA Space Robotics Challenge - Phase 2 (SRC2) addresses t he speed of the ...
-
The brain of a robot is the software. The software has to take in the sensor data, interpret it, and generate commands to the actuators. On...
-
Another NASA Centennial Challenge began earlier this year. It will be the 3rd I've entered. I also entered the 2019 ARIAC competition...
-
SRC2 Rover This fourth post about the qualifying round of the NASA Space Robotics Challenge - Phase 2 (SRC2) addresses t he speed of the ...