Thursday, March 21, 2013

On track, and on fire!

While I may be a robot-busting-ninja by night, I'm a mild-mannered project manager by day. So naturally I took to laying out the rover build as a project.

Since I don't have access to my day-job tools for this (Microsoft Project), I use a project planner tool from Simple Genius, simply called 'SG Project', for the iPad. And a little secret about it?

It rocks.

Way better than MS Project.

WAY.

If you haven't seen any sort of project management done before, even on paper, most methodologies generally will organize tasks into a few major buckets for a build project like this. A simplified version would look like this:


  1. Define the general requirements or parameters, scope, schedule, cost, and objectives. Even if you are doing this as a hobby, it will help your family understand your addiction pastime and how long it will take, and how much it will cost (and if they should hide their jewelery).

  2. A design phase, where drafts of the design can be 'thought-tested' (or sniff-tested) against what was learned in Step 1. If you do this step well, you shouldn't exceed your budget by too much.

  3. A build phase, where the parts are brought together, assembled, or otherwise created. It helps to give this step a lot of time; since it's my experience that garage sales, junk stores, and ebay (kinda all the same, no?) hold many interesting items, all of which take time to ship to you.

  4. A test phase, where things are tested separately and together (this is sometimes mixed in with Step 3). This is also where a good deal of debugging happens, because although it will test ok the first time you try it, it will go down in flames when you try and show it off. Remember JPL's unofficial mantra "Test as you fly". Or in my case, "Test as you drive". I don't know how I'm going to get 1000kg of sand and rocks into the basement to build my own Mars Yard, but somehow... maybe.

  5. An Operations phase, where it happens for real, often with spectators, and often with embarrassing / hilarious / combustible results.
If I get some time I'll start posting what my plan looks like, and how I'm progressing.

As a side note, I got the first shipment of parts today, which was mostly consumable supplies.

Among the small items was a roll of Kapton tape, which is kinda geeky, but is fairly resistant to high temperatures. So what's the big deal about that? Consider how much cash you could be pouring into your rover, and that it's electronics enclosures might be full of cheap electrical tape.

And then you get an itty-bitty over current situation... I want you to think twice about the amount and location of PVC tape you might be using, and if it could be exposed to flame due to a short or component failure:



If you recollect, Kapton got a bit of a bad rap in the airline industry, although I've read that Airbus still uses it; and of course NASA eats it for breakfast. The failure states it was tested in are pretty harsh, although worth considering.

But this simple comparison I think the results speak for themselves; I'd rather spend the extra $15 on a roll of Kapton than use too much PVC any day!

That is all!

Sunday, March 17, 2013

Next Step: Motor Control!

The next step after choosing motors (like these) is to select a method of controlling them. I prefer to have something with PWM speed control and current feedback, so that's going to narrow down my list a bit. PWM speed control is easy to do with an Arduino / Atmel chip, and you can do things like slow-start and slow-stop. Current-sensing is important too, because even though the motors have encoders, it's possible that a motor can draw more current than you'd like but still be turning, so with that information it's possible to command less speed and cut down the current drain.

The Requirements

The specs for the motors list about a 1A (amp) rated draw, and a 5A stall current. What's the difference? Motor specs usually list at leat two important numbers; free run speed or rated speed in RPM (rotations per minute), and stall current (at zero RPM). Don't assume that if you need, say, 200 oz-in of force that a motor with a stall torque of 200 oz-in is going to work; it won't! Since 200 oz-in is the stall torque (say at 5A), that means the stall was measured as the force to STOP the motor from turning. And 'stopped' means not turning at all. Even getting close to stall torque means a very slow RPM rate. And be sure to read your spec sheets; some motors can actually damage the gears when totally stalled, so you want to build in a good sized safety factor there.

Some motors list a combination of 'rated speed / rated torque', which is handy to know. Although the small torque is probably too small to even move a 'bot on a level surface, it puts a dot on the torque-speed graph that is useful. Like this:


What does this tell us? That for RPM's (the left numbers) in the 100-200 range, we will have current draw in the 1500-3500 mA range (the numbers on the right). Milliamps are just 1/1000th of an amp, so that's in the 1.5A - 3.5A range for useful RPM ranges. It also says that the torques are going to be 1/12 of those same numbers, I multiplied the torque values by 12 to put in on the same scale as the current. That's roughly 125 oz-in to 200 oz-in of torque, so plenty for normal driving over slightly uneven or low sloping terrain.

Those nominal current values are going to come in handy later for battery sizing, too. Six motors drawing 3A is an 18A draw, which is a relatively high amount for a small-ish robot. But we know we have the torque available to lug around a big enough battery, so we won't worry about that yet.

Controlling up to the 5A stall current per motor, with a 3A nominal draw is the next challenge. Some of the wheels will always turn in the same direction, like the two motors on the front and back of the same side, so it's possible to see if a single controller of 10A max would work. It's also possible to see if using single controllers, one per wheel, would work, but that is going to cause some interesting challenges for a single Arduino to control (once we add steering, which I haven't talked about yet).

The first draft plan would be to have four controllers. This is because for some kinds of turns we don't want the middle wheels to turn at the same rate, or at all, because the rover is going to pivot on them. If they did turn, it would tend to drag the rover around a bit. Here it is spelled out:
  1. Right side, front and rear wheels (10A max)
  2. Right side, middle wheel (5A max)
  3. Left side, front and rear wheels (10A max)
  4. Left side, middle wheel (5A max)
Time for a step back. Remember earlier when I said I liked to have current feedback per wheel? This won't give me that, unless I use separate PCB's for current sense on the motor inputs, which is an option, but it might drive up the price. Or not, as the Cytron 10A controller is only about $15 each. They don't have current sensing, but that could be added for another $10 with the Pololu 30A Current sensor board.

If it sounds like the spec is a little too close for comfort, the 10A controller boards appear to be ok for a 15A peak for 10 seconds; plenty of time to dial back the power in software. This should handle the little bumps from things like motor startup and small obstacles without going up in smoke.

Four of the controller boards is $60, and adding per-motor current sensing is another $60. For $120 that gives far more control than simply driving the left and right side motors at the same speed via a single dual-channel controller.

But since I'm considering a simpler control scheme, this controller from DF Robot is darn near perfect (on paper), and is only $50, and includes current sensing and few other perks like temperature and current limiting.

I wonder - what about using two of them? That gives me all the perks for $101 (instead of $120), and four channels of control, which is exactly what I need. That sounds about right. The tradeoff is that I can't get current feedback per motor, since I'd use two on the same output of each driver for the front and rear wheels. I think for $20 extra it's worth it to have current sensing, so I'm sticking with discrete Cytron controllers and current sensing boards.

If I wasn't such current-hungry control freak I might consider two of these Pololu controllers; they can do 3A continuous / 5A peak (the chip datasheet says 5A continous as an absolute max rating), and at $37 each ($74 total) that's even better. But that wouldn't have per-motor current sensing, and it would be cutting the spec a little too close for comfort. I don't want the magic smoke to get out the chips during the race and possibly melting the rover, just to save $25.

The Battery

24V motors in a small rover are pretty intense. At our 3A draw, plus a few other things like steering, sensors, and electronics, we might have a 4500 mA (4.5A) draw.

SLA (sealed lead-acid) batteries are too heavy (actually, it's that they aren't energy-dense enough), so we are left with other choices. For example, two small 12V SLA's in series (to get 24V) would weigh 5 lbs, and only have about 4500 mAh, or about one hour of run-time.

Luckily the world of R/C racing has some pretty steep power requirements that might work for us. Both NiMH and LiPo batteries are good options, and it's possible to fudge getting near 24V and the right run-time if we combine them creatively.

First off, my preference would be to use as few batteries as possible. A common battery voltage is 11.1V, so two of them connected in series would be close enough to 24V to work. At R/C capacities we also need to connect two more in parallel, to yeild a useful runtime. Just for comparison that would weigh less than 3.5 lbs, so it's in the realm of possibility. It's interesting to note that I'm 150% overbudget on battery weight, but there aren't a lot of options here.

I could go with a 3x2 stack of 8.4V batteries, but the weight penalty gets a little higher for similar performance. And charging that many batteries would be a pain.

I could also choose a single 22.2V pack, but it's harder to adjust the capacity at an affordable price.

So two 11.1V packs to start it is! With charger and a few connectors the total price is $150, right on budget. If I need double the run time, it's under $100 to add two more batteries.




Saturday, March 16, 2013

Puttin' Some Rubber on the Road

Ok, last time I mentioned the wheel diameter is 120mm... That's actually the size of tire from the Dagu Wild Thumper, because the tires are BIG (for an R/C style tire), and relatively inexpensive. Which is great when the rover accidentally drives off something tall and breaks a plastic hub. Well, plastic for now; I'm planning for solid cylinder tires to help protect the motors. And motors are what I've been thinking a lot about lately.

Choosing motors - my approach

Before I can consider which motors I might choose, it helps to guesstimate at the total mass (weight) of the rover, and make some ranges for performance, like how fast it should go, how much slope it can climb, and what kinds of payloads it might take.

1. The Weight Budget

After a first pass through the chassis design, I was able to make a guess at the final weight of the metal. A few quick web searches filled in some blanks for things like battery weights, and some total guesses for the weight of electronics (which isn't much). Here is what it looks like:

ItemGrams
Chassis2000
Drive Motors+mounts1500
Wheels, hardware500
Batteries1000
MCU/Sensors1000
Harness250
Mast250
Payload0
Total Grams6500


That's a total base mass (no payload) of 6500 grams, which is 6.5 kg or just over 14.3 lbs. Putting in a fudge factor and payload could be 10 kg. At the time I did this math I wasn't sure that the rules or goal of the race wouldn't change, so I also budgeted another 2 kg for a small manipulator arm in case they added any 'tasks' for the robots to do. But they didn't... so I guess that saves me some mass (and money!). However, once the race is over - on goes the arm! So although I hope it doesn't weigh 12 kg (26.5 lbs) on race day, that's the design mass. And as the bits arrive I'll be putting the digital postal scale to some use...

2. The Performance Envelope

The next considerations are the kinds of terrain slope and speed that the rover should operate in. This is an outdoor race, and I visited the site last summer and documented it photographically. There are slopes, gravel, grass, and small trees. There are also some concrete sewer accesses sticking up, an maybe a few mud puddles, and whatever else in terms of obstacles that the race organizers want.

Having some experience in driving robots up slopes (and a good background in math and physics), I know that as the slope increases the traction decreases, and as it happens, at about the same point that the traction loss is significant the stability (or tippy-ness) usually becomes an issue.

When a robot is operating near its tipping-point driving across the side of a hill and it drives over a rock on the uphill side - even a small rock, it can be game over pretty quickly. So traction and stability are usually in the same general vicinity, perhaps around 45 degrees, or a little less. The design has to also consider that a rocker-bogie suspension control system might be a little insensitive to driving over obstacles of roughly one wheel diameter, which could easily put it over the stability limit. Of course, that's what software and sensors are for... but it does mean that 40 degrees is probably the sensed limit, and 30 degrees is probably the commanded limit. But wait, there's more...

Driving straight up a good grippy slope without stalling the motors, or very near the stall limit, is a pretty substantial torque problem, and it's heavily influenced by robot mass. So the robot should be able to proceed above it's commanded limit, in case it runs over the aforementioned small rock, but designing much above that will lead to having to choose larger (and heavier) motors, bigger (and heavier) batteries, and eventually the math grinds to halt, leaving a lower max incline than either traction limit or stability limit. But wait - still more!!

The rocker-bogie system has a great feature - it can climb obstacles more than one wheel diameter. But that means that when a wheel encounters an obstacle it might have to climb straight up the front face of that obstacle. That's a 90 degree slope, but for that drive motor, it's only a fraction of the total mass of the robot. I chose to consider that two wheels might be off the ground, so the total mass (12 kg) would only be supported on 4 of the 6 wheels; that's 3 kg per wheel / motor.

The best online tool I've found for these kinds of what-if problems is the robotshop.com torque calculator. I've run the math through it, and compared it to real-world machines and I trust the numbers it gives.

For a 12 kg mass, with one wheel lifting 1/4 of the mass (3 kg), or all 6 wheels driving up the maximum slope (say 40 degrees), the torque numbers look like:

Single wheel, 0.06m in diameter, a 90 degree slope (obstacle), and 3 kg mass: 393 oz-in

Six wheels, 0.06m in diameter, 40 degree slope, and 12 kg mass: 170 oz-in

I'm going to use the more common torque measurement of oz-in, since that's what's often listed in product pages, but in my head I tend to think in kg-cm, since I can visualize it better. Just multiply kg-cm by 13.87 to get oz-in.

The second number - 170 oz-in for a 40 degree slope, is the minimum torque per motor for a straight uphill climb on a smooth-but-grippy surface. Actually, since a wheel might have to climb an obstacle, this number is below the minimum, and that a motor with a stall torque of 170 oz-in isn't even worth considering.

So is 393 oz-in of torque reasonable? No, for two reasons, but yes for a third reason.

First, that's a big number - which probably means very low RPM's (speed) because of gear reductions; not the small, fast hub-mounted motor I had in mind. More importantly it's tough to guesstimate a good coefficient of friction for a knobby rubber tire being driven up a rough surface, all the while having 4 or 5 other wheels driving the robot body forward, into the rock or obstacle. There should be plenty of contact force, but once the axle of the first wheel is above the axels of the other wheels it doesn't actually need to pull itself up - it would actually roll its way up if all the other wheels just pushed on it. That's the second reason; 100% of that torque may not be needed very often.

But it does give some guidance on what the upper limit is for the requirement; ie more is better, so it's still a useful number. I know if the stall torque of the motor is closer to 170 oz-in the robot might have trouble mounting a vertical obstacle if the other wheels can't push the robot forward, perhaps because they are in sand or mud. Likewise if the motor is somewhere between 200 and 300 oz-in there is going to be better single-wheel climbing performance.

Where does that leave the search for a motor? There is one last consideration: sensing motor speed. Geared motors are usually sold either with or without encoders; I pretty much need them for the software to work, so that's going to narrow the field of choice quite a bit. Encoders give an indication of speed and direction, so it's easy to calculate a dead-reckoned distance or speed, or detect a motor stalling or having issues with an obstacle.

One company that makes small-ish motors is Pololu. Of their lineup the only motors they carry that might work are in the 37D line. There are three that might work, and their calcuated speeds for a wheel radius of 0.06m are:
  1. 200 oz-in / 150 RPM = 0.94 m/s (just over 3 km/hr)
  2. 220 oz-in / 100 RPM = 0.63 m/s (just over 2 km/hr)
  3. 250 oz-in / 80 RPM = 0.5 m/s (just under 2 km/hr, probably closer to 1.5)
Any of these motors would work in modest terrain, but in some cases even 250 oz-in may not be enough.

Let's try another source; superdroidrobots, they seem to have two that might work also:
  1. 347 oz-in / 265 RPM = 1.66 m/s (about 6 km/hr)
  2. 485 oz-in / 190 RPM = 1.19 m/s (about 4.3 km/hr)
The reason that the second set of motors looks better on paper is that they are 24V instead of 12V; so a little more bang for the buck. But of course this means doubling the battery weight... Ugh!

Revisiting speed, control, and requirements

I like to take a step back at each decision and consider it in context, not just by the numbers, and make sure that I have everything in perspective. My data-driven instinct says that the faster of the 24V motors or the slowest of the 12V motors are close enough to compare.

The first two 12V motors probably aren't torque-y enough for the worst conditions, and down the road that might limit using larger tires on the rover. The torque-monster 24V motor is impressive, but is it too slow? Not really, 4.3 km/h is about walking speed, and it's possible to trade torque for speed by using larger wheels.

In the end I like the idea of a motor that can deliver all the torque required at the fastest possible speed. Although I don't know if the software (probably running on a 70Mhz Max32) can allow for safe navigation at 6 km/h, I think I'm going for the faster 24V motor. This is a race, after all!

;)

Racing Rover!

Ok, last time I talked about some options for off-road vehicle mobility, and a few of my faves from JPL. This time it's all about designing an almost Sojourner-sized autonomous robot, about 640mm long. It's well inside the size allowance for the WCRS race of 1 meter max in width, height, and length, and I can add a manipulator arm and still be within 1 meter.

I've worked with aluminum before, but cutting and drilling with any accuracy takes time and care. There are modular systems, like OpenBeam or MicroRAX, but they are expensive and fairly small. I need something beefy to survive an off-road race.

Lucky for me ServoCity has released an amazing assortment of parts that use a common hole pattern, so they fit together easily, and they have pretty good specs on their website so designing is easy.

This is probably the zillionth design for a six wheeled rover that I've considered on paper, and I think it's the best balance of tough, simple, and lightweight. The top of the image is an overhead view of one of the rocker-bogie arms, and the bottom part is the side view.


These arms connect via a 12" wide body, so my only concern is lateral stability on a side slope... but I have to start somewhere! If you're curious, all the rectangular parts are based on ServoCity aluminum channel, and the wheels are 120mm off road R/C tires. Aluminum keeps it light; I think the chassis should weigh in around 2kg 'bare'; without motors, batteries, etc. As it gets assembled I'll post some pictures and stats.

The body of the rover, roughly equivalent to the WEB, or 'Warm Electronics Box' on Sojourner that holds the batteries and electronics, fits between the arms and extends down to about half way to the wheels. In my case I use the enclosure to force air across the motor drivers to keep them cool, instead of warm. If I can I'll make it even thinner and get some extra ground clearance. :)

One thing that isn't obvious about the rocker-bogie design is how the two sides connect, and why it works. On the smaller JPL rovers a geared system joins the two arms, and on the bigger Curiosity, a torsion bar crosses over the top of the body. In this way the body stays as level as it can (about half of the motion of rocker-bogie arms), and the wheels are roughly equally loaded, so they all tend to want to stay on the ground.

I'm going with the geared half-differential; each arm has a 1/4" rod to the center of the body, with a bevel gear on the end. The two gears from the arms are linked by a 3rd bevel gear at 90 degrees, so when one arm rotates one direction, the other arm is forced down in the opposite direction. Big thanks to Beatty Robotics and their Spirit II robot for such great work and pictures, and they use ServoCity parts, too!

Here is a view of the middle of differential gears (in red) which fits in the central bit of 12" aluminum channel:


I happen to have 3 spare metal bevel gears that fit 1/4" shafting, so all I need are some longer shafts and a bucket of bearings and clamps to make it all work.

Next time I'll describe some of the ways to link multiple microcontrollers together, and some of the ideas I have for sensors and automation.

WCRS Robotgames - 2013

I don't know how I missed it, since I've been checking all the time, but the 2013 Robotgames have been announced on the WCRS site!

I've been doing a fair amount of work to understand how best to get a whole 'schwack of Atmel processors working together, mostly using an SPI bus for heavy lifting, and I2C for talking to individual sensors and really tiny custom sensor PCBs. Most of that has been targeted for the Dagu Rover 5 platform, mostly because it's small enough to run around the house, and because it's a low cost / low barrier to entry for trying out ideas.

But the Rover 5 has one big limit - it's small! Too small for the WCRS Off-Road challenge, I think. And it's tracked, with 4 motors (instead of two), so I actually dedicated an entire AT328 to keeping the motor/encoders running at the same speed to stop it from throwing it's tracks. But that's only half a solution, because any small gravel or twigs that get jammed between the tracks and wheels can cause trouble. It's does drive dead-straight, however :)

So it's time for a bigger build! But what form should it take?

I started down the path of designing a tracked robot, but problems with keeping the tracks clear aside, even finding tracks big enough are a problem. And the ground clearance for tracked vehicles is low - it's great for tanks - the low profile makes them harder to shoot - but it's not the greatest if you want to cross rough terrain.

There are other designs that have more ground clearance; big wheels, for example, but really big wheels take an enormous amount of torque to turn, and there are limits to motor size + battery weight that can fit within the size rules for the off-road race and stay stable.

How about the JPL/NASA designs for 6 wheeled rovers using the rocker-bogie suspension? Those have amazing ground clearance and stability. But they are kinda ... slow.

Really, their limit is more based on a very tight budget for electricity and a huge desire to not 'overdrive' their ability to safely command the rovers. They use small, highly geared motors which move the rovers at just the right speed that the autonomous systems can keep them out of trouble. After all, they do cost a lot of taxpayer money, and it would be bad to put a dent in the fender of the family car. Or drive off a cliff.

But here on earth, for a short race, and a tough little rover, could faster speeds be used?

Kind of. The rocker-bogie design isn't well suited to 'dynamic' vehicle behaviors. By 'dynamic' I mean moving fast enough that you can bounce around, get some air over a jump, etc. So by moving their rovers slowly, NASA keeps the dynamic portion of the vehicles suspension system to a minimum. However, a  faster rover could be slowed when it's time to climb over a rock, instead of running into it full speed.

Here is a good video of testing the design in the JPL Mars Yard:




Could they move faster? On some of the long drives of the MER rovers Spirit and Opportunity I bet they wished they could. The ground was certainly flat enough and free enough of rocks - if they had a bigger power budget I think they could have used a slightly different motor gearing and really put the pedal to the metal.

I'm betting with a little cleverness to slow the rover before a large obstacle is mounted, I could really crank out the speed through the flats, so the 6 wheel design might work in a race scenario.

Now for the details - in the next post ... ;)

Here are some additional links and videos:

Pathfinder / Sojourner This little guy really captured my attention when it landed. It outperformed all expectations, but was finally let down by the lander, which seems to have failed first and cut off communications with Sojourner, who may have driven around until it also failed, trying to call home.

Spirit and Opportunity  Bigger than Sojourner, the MER rovers are going into the history books along with the Voyager probes as well exceeding their design lifetimes; too bad Spirit got stuck. I hope they can re-establish contact with Opportunity after the 2013 solar conjunction, when the Sun gets between Earth and Mars.  Here is document describing the suspension and considerations in a bit more detail.

MSL / Curiosity Even bigger still, this rover didn't even need a lander, although it must have set a record for a crazy-complicated EDL (Entry, Decent, and Landing) system. Check this out:



Here is a longer video with more of the rover and surface operations.



And if you aren't already, you just have to follow @Sarcasticrover on twitter! And the author is a fellow Calgarian, so that's bonus points!