Sunday, January 27, 2008

Systems Engineering: Part 3

Architecture Synthesis
It's been awhile since the last post on Systems Engineering for robotics. I've been pretty busy building and tinkering. Anyway let's get back to it. We've been defining the problem carefully. It's finally time to start solving the problem. This is the fun part!

Ask 10 people what Architecture means in the context of systems engineering and you'll get 11 answers. :) But the answers are more or less along the same lines. Architecture defines the most critical solution elements of the system. Whereas requirements define the problem in a solution-agnostic fashion, and functional analysis decomposes and organizes the problem without solving it, architecture is the first step at solving the problem.

Examples: What type of steering is your robot going to employ? What motors are you going to use and how many? What kind of batteries? What device is going to control the robot? What kind of algorithms are you going to use? Answers to those questions are the architecture.

Architecture synthesis is the process of developing several combinations of solutions from all the possibilities and picking the solution set that is most optimal--the one that best meets the requirements. The real system will be built within the constraints of this solution set.

I started with the functional analysis and use that as an outline, and then over the course of several days, identified technical solution options for each item of the functional architecture. I didn't try to figure out which options I wanted to pick right away, I just wanted to spend some time seeing what the options were. Above right is a snippet of some notes I took (click to enlarge). I tried to be very specific as I could -- part numbers, with URLs, costs, etc. I would list some items as "selected" or as "to be decided (TBD)" or as alternatives. This helped me attack the problem bit by bit and evaluate various possibilities.

A little at a time, I started eliminating options that didn't fit with budget, size, performance, or other requirements. I selected options that were clear winners. Sometimes selecting an option would be eliminate because of its overall impact. For example, large 24V motors required heavy lead acid high capacity batteries that I felt would be way too heavy and require a new battery charger that would increase the total cost of the project too much. A better option was to use AA rechargeable batteries. I had two chargers already, and these batteries are relatively light, cheap, and powerful.

Over the course of several days I whittled the architectural options down to a manageable set. There was a lot to think about, but having an outline really helped keep it all straight and kept me from feeling overwhelmed. But, I ran into a roadblock.

Selection of motors, the power supply, chassis size, wheel size, and motor controller ended up being a crucial set of interdependent architecture elements and I was having trouble picking a solution set. Picking one item affected almost all the others, directly or indirectly, as shown in the diagram below.
Here are a couple example solutions I came up with. (1) very high power motors, large platform (10" wide x 10" long), home brew discrete H-Bridge, large wheels ~ 5-8" (2) much smaller platform around 10-12 cm square with Tamiya Double Gearbox with 3V motors, a discrete H-Bridge using low voltage N-channel MOSFETs, Tamiya 56 mm wheels, and a set of AA NiMH batteries for power. I came up with quite a few more variants, making it difficult to pick.

The question of speed as the result of weight, motor size, tire size, gearing was such a point of uncertainty that it led me to build a prototype robot, Sparky, to do some performance testing and get some answers.

Let's talk specifically about wheel size and rpm. I want to have a fairly fast robot, as specified in the requirements. I figure even with the best programming, unless the bot is pretty fast, it is going to be kind of hard to place well in the competition. I calculated out several configurations of wheel size, wheel rpm, motor rpm, and gearing that would achieve the target speed requirement of traversing the 248cm arena in ~ 3 seconds.

Here's the chart I cooked up to evaluate the different options. I am trying ot use various calculations and analysis tools to help figure out which solutions are optimal for the various elements of the functional architecture.

This helped, sure, but the biggest help was Sparky. Now I had a concrete, real life example of performance that I could see, measure, and compare to the calculated values. From this analysis I ended up selecting the Tamiya Dual Gearbox and it looks like either 38:1 or 12.7:1 are the ideal gear ratios, but I can finalize that after awhile. It felt good to resolve this huge uncertainty in the architecture and finally place my order for real parts after noodling it for a couple weeks.

The prototype really helped in selecting other pieces of the architecture, too. I decided the H-bridge would be too technically hard to build reliably in a short time. Likewise, I felt building my own CPU system (ATmega16 + support components) would be unlikely to go smoothly and would take too long, distracting me from sensor and software development. The prototype helped me to identify and address these risks. Speaking of which, we'll talk about risk management next time.

Previous: Part 2: Functional Analysis & Allocation

Friday, January 25, 2008

Speed Test

Early this morning I completed the main goals of the Sparky prototype build: to answer critical architecture questions about speed, weight, and size of the to-be-built competition robot.

Sparky achieved autonomy and completed several test runs across a 248cm distance, the maximum span of the firefighting contest arena. The video below shows Sparky's buildup and performance test.

I can now make a drivetrain selection--motors, gears, wheels--and the rest of the pieces of the complex architecture puzzle--motor controllers, power supply, computer systems--are rapidly starting to fall into place. Good thing because the clock hasn't stopped counting down the days and hours until the showdown on March 8.

Thursday, January 24, 2008

Success! Servos and Motors

It was a brutal fight but I coerced Sparky under the control of his little Basic Stamp 2 brain. As mentioned previously, Sparky's little DC motor is controlled by an IRF510A MOSFET which in turn is controlled by the BS2 which in turn kept resetting right after powering up the motor. As for the 3rd wheel, the HiTec HS303 I had on hand was broken. Or so I thought. I couldn't get it to center properly with the sample code from the Basic Stamp Manual.

Basic Stamp Servo Control
So that you don't struggle with this yourself, here's how to properly control a servo with a Basic Stamp 2. Timing is everything. Servos require pulses separated by 20ms. The pulse length determines the position of the servo.

A 1.5ms pulse should approximately center the servo. To get the right pulsetrain you have to know a bit more about how your Basic Stamp (or other MCU) works. I just copied source code out of the manual. Big mistake. The manual's source was for a slower Basic Stamp 1 so the timing was off by a factor of 5! You want to use the PULSOUT command but on the BS2, each value lasts 2us instead of 10us on the BS1. So here's the source:

PULSOUT 0, 750 ' The servo signal line is sitting on pin 0

Once I figured this out, the HS303 worked beautifully. So did the brand new servo I had just bought thinking the other was broken. Oh well, I will put the new servo to good use. It's a HiTec HS311 and a cheapie at $11.

Basic Stamp Motor Control
With one problem slain it was onto the motor control issue. DPRG had a thread going about driving inductive loads and MCU resets due to brown out detection kicking in when the motor, relay, or other inductive load was shut off, creating a voltage spike as the magnetic field in the coil collapsed. This voltage spike is seen by the MCU as a raised voltage on the ground line which reduces the effective voltage seen by the brown out circuit on the chip causing the reset.

That wasn't what was happening to me. The MCU was resetting when turning the motor on. I am still trying to figure out what was happening but I did find that putting a 100uF capacitor across the Vdd / Vss (regulated 5V) pins on the BS2 solved the problem (temporarily, I later found out). The capacitor decouples the chip from the batteries so if the ground line rises in voltage the capacitor and chip kind of ride the surge. So I understand. I'll update this if I get more insight.

So, with these two problems solved, Sparky is able to control motors and servo and is very, very close to autonomy. Just a question of tying down batteries and boards and he'll go for his first test run and then I can figure out what powertrain to use for the real firefighter.

Tuesday, January 22, 2008

Tinkering Update

Last week I had a family emergency but things are better now. I've had a little time for experiments with light sensors and motor control for the firefighter (FF). You can see the mess I accumulated on my tiny work area in a short time!

For experiment uno, I wanted to put the Tamiya motor/gearbox under Basic Stamp control. Eventually this gearbox, attached to Sparky, the firefighting prototype, will be used for speed and acceleration tests to select a final drivetrain.

Motor control is covered endlessly in just about every robotics book and on so many web pages. But, I can share my woes. I thought I had it made, since I have a stash of IRFZ20 Power MOSFETs and some other transistors. But none of these worked when using my two AA batteries (2.6V).

A trip to Radio Shack netted a single IRF510A Power MOSFET which worked fine as a single solid state switch. I'll deal with H-bridges later. David Cook's book Intermediate Robot Building has some great tips on selecting MOSFETs.

Next step for Sparky: autonomy! After I replace that broken servo...

Experiment numero dos involves various light sensors. Of note, I picked up an $8 Parallax sensor (actually a TAOS TSL230R) that converts light intensity to frequency. I'm looking forward to playing with this more.

Meanwhile I did some experimenting with a lone IR phototransistor as well as some IR LEDs (thanks to "The Mad Professor" and this thread for the reminder that LEDs can also detect light). Both seem promising for detecting a candle flame. Likewise, a set of assorted CdS cells may be helpful either in identifying the candle, or interfering ambient light, or both.

The most exciting sensor news is a secret. As in, secret weapon! (insert mischevious grin here) If it pans out, this sensor will be a cheap but effective and reliable flame detecting sensor to supplement or even supplant those mentioned so far. Much to do...

Saturday, January 12, 2008

Firefighter Chassis Done!

Check it out! I made a lot of progress on the firefighting robot prototype over the last few days between work and babysitting our nephew. The chassis is done!

Here's a quick howto. The goal for the prototype was to build it super cheap so the robot is made almost entirely out of stuff I scrounged around the house.

Admittedly, I partially made it up as I went, so it is a bit... rough. (And it is my first from-scratch robot, after all)

A few years ago my best friend and I each bought one of these Tamiya buggy kits to build into robots. I decided to go with a front two wheel drive, rear single wheel steer figuring this would be simplest to put together. Conscripting OmniGraffle for drafting duties, I put together templates for the top and bottom decks and transferred the design to 1/4" furniture grade plywood. Three times. It took awhile to get it figured out, what can I say? Here's the templates:



About the rear steer. A strip of brass makes up a U-shaped bracket that mounts the wheel and attaches to the servo horn. The servo is a cheap analog HiTec unit I had on hand. The axle is a 6-32 threaded rod with washers between the bracket sides and wheel, and nylock nuts keeping it in place. I had to buy this hardware for the whopping price of $1.50. The servo rear bracket attaches to a piece of aluminum channel stock via self-tapping sheet metal screw and the channel attaches to the upper deck with the same screws.

The caster bracket could stand some refinement in execution, but it seems to work well enough for now. The downside of the rear steer setup is that the robot can't spin in place, an advantage in navigating maze situations, I would guess. Also, the dual motor front drive doesn't have a differential so that increases turning radius, but also traction (knowledge I gained from four-wheeling).

Plywood is a bit fragile in some circumstances, and mounting this particular geartrain required reinforcement in the form of aluminum channel stock along the edges. You can kind of see these in the photo.

The rear cutout is for the caster steer wheel, the hole behind the motor is... an unrealized idea, shall we say. 1" square by 1.5" long blocks are the supports for the upper deck. They're glued and screwed to the lower deck.

The upper deck required a cutout for the servo. It also has a hole for routing wires. I screwed the aluminum channel to the servo, inserted it, and screwed the channel to the top deck. In turn the top deck screws into the support blocks. Et voila, the firefighter prototype chassis is ready for testing!

Turns out the little bugger is a lot quicker than I expected. Looks like a fast robot is within reach after all. Without having to get gargantuan motors and without spending a fortune. I'll do some timed runs tomorrow.

Thursday, January 10, 2008

'Scope & Tinkering

I've been wanting one of these for years... and now I have officially purchased an oscilloscope! I learned on Tektronix scopes in college so I'm glad to have found a reasonable deal locally on this military version of the 465, a dual-trace 100MHz unit. I hope to pick it up tomorrow or early next week. I think this will be invaluable for troubleshooting and for research, like figuring out the capacitance of a capaciflector in various situations so I can build a circuit to interface with an MCU.

Meanwhile I've been working hard on the firefighting robot architecture, but have run into a snag. I don't know how big of a motor I really need or what size wheels. That depends on how heavy the robot is which largely depends on what kind of batteries I choose, which depends on the selected motor. Wheel size and chassis size are interdependent too. Selecting 10" wheels on a 10" chassis means I have to be more creative with side sensor placement.

If I weren't on a tight budget I'd just buy a pair of interesting motors and see how they work, but instead I want to eliminate some of the uncertainty ahead of time. So I'm building a proof of concept prototype, a robot much smaller than I originally planned to make, measuring only 12cm wide by 12cm long. I'm using some Tamiya motor and wheel parts, a servo, and some other material I had on hand from the last robot experiment years ago. It's not even using the same drive/steering mechanism I plan to use, but ... so far it's only cost $1.50 for some small hardware. It'll sort of look like the (staged) pic to the right. Yeah, I know it's ugly as sin...

Once it's done, it'll be a good, cheap prototyping platform to prove out the IR flame sensor 40khz wall collision sensors, and other hardware, while I use the Cruiser to prove out the software. Initially, I'll drive it with a Basic Stamp 2 I got several years ago and do some speed tests and see what kind of weight capacity it has.

Wednesday, January 9, 2008

Systems Engineering: Part 2

Functional Analysis & Allocation
I admit, I'm getting a little obsessed with this firefighting robot competition. I tend to get of focused on things rather intently, sometimes (and I tend to be good at making understatements, too).

But, hey, that's ok, because where I was feeling overwhelmed at all the massive uncertainty of how to build a firefighting robot, all this analysis work is paying off. I have a better idea of the problem, and how to solve it, as well as a better sense of the feasibility in time and cost of this project (my budget is a mere $150 and I have until March 7).

Where the story left off was with gathering requirements. The next step in my Systems Engineering Lite kind of approach (the goal is to follow the spirit of the most useful techniques) is Functional Analysis and Allocation, where one organizes the functional aspects of a system into a hierarchy called the Functional Architecture, and then allocates requirements to the functions and sub-functions.

The primary goal is to both decompose the problem, and identify the need for additional requirements. We still aren't really solving the problem, mind you, just sort of organizing the solution. Some functions in this robot: Search for a Room, Search for a Candle, Extinguish the Candle, Move, Steer, Avoid Collisions. There's quite a few more. I arranged these in a simple hierarchy. Navigation covers moving, steering, object avoidance. Control Activities covers the step by step process of searching rooms, finding the candle, extinguishing it, and so on.

Using a matrix (above right), with requirements on the left and functions at the top, I just put an X in the box where a requirement is to be met by a given function. I started with the high level functions first and decomposed as best as I could. If you find more functions are needed to address unallocated requirements, add those if you can. Then I used a series of N2 Diagrams (below right) to model and further decompose the system, and to organize it into a meaningful hierarchy, while identifying subfunctions.

You could start with high level functions, and put them in the diagonal (blue) in a square grid. Outputs of each function appear to the right or left of the function. Inputs appear above or below. Thus, each square represents an interface between functions.

The top-most row in grey represents external inputs (like from users) and the rightmost column in grey represents external outputs (to users). You could have external systems, like if your robot were interacting with another robot, or with a television or something.

Next you decompose each high level function into subfunctions using additional N2 diagrams. You might find that a requirement hasn't been addressed by a function, so you need to add a function. As you add functions, be sure to update the requirements allocation in the matrix.

Perhaps you find you want to combine two top level functions. Or maybe you just need to think through all the subfunctions of a particular high level function. The N2's make this easy to do, and while you're doing this, update the matrix (if I had Vitech CORE, I could build N2's while simultaneously, automagically creating the function hierarchy). I simply kept the matrix and N2 diagrams in sync manually.

After you feel you've captured enough functions and subfunctions to cover the requirements--and in enough detail to jump into selecting your solutions--go back to the matrix a final time and update allocations for the subfunctions.

Right now, most or all your requirements are allocated to high level functions (X marks the spot). You want to allocate requirements to subfunctions (you can do this while decomposing, too), but keep the allocation to higher level functions so you can see an overview. When it comes time to find a solution for a given subfunction, you have fewer requirements to consider.

You're basically dicing up the elephant in preparation to eating it (metaphorically speaking of course).

If you're curious, here's the current version of the matrix and N2 diagrams in Microsoft Excel format: RequirementsAllocation.xls


Previous: Gathering Requirements
Next up: Architecture Synthesis

Monday, January 7, 2008

Systems Engineering: Part 1

Requirements Analysis
I've been doing some preliminary work on the Firefighting Robot. In hopes of making it easier to tackle the problem, I'm applying my ongoing education in Systems Engineering (SE) to decompose and methodically solve this complex problem in a short time by applying an SE-like process methodology.

I've started with the first SE step by extracting requirements from the competition rules. Requirements should describe what a system should do, not how it should do it. They should be solution independent. Decompose the problem first, solve it piece by piece later. Next, I added requirements to better define the problem to be solved. I'll continue to refine these as I go. Here's an initial requirements draft: FirefightingRequirements.rtf (If I could afford it, I'd use Vitech's CORE for SE work, but c'est la vie)

Next: Part 2: Functional Analysis and Allocation

Firefighting Competition

I've found out that there's to be a robot firefighting competition hosted by Front Range Robotics Club and based on the Trinity College Firefighting Home Robot competition's rules.

The Cruiser mousebot I have will be a great platform for prototyping the navigation solutions, but if I were to really enter this competition I might well need something larger, faster, and more expandable. I'd love to give this a try, but it may be reaching for the impossible...

...at least in terms of budget and time. I'm enrolled in a Systems Engineering masters program at GWU through work and those classes start up soon. The other "minor" issue is that the competition is in March. Eek! That's not much time to build what will probably be a relatively complex robot from scratch. Seeings as how I've never built a robot before! Meanwhile I want to get my Jeep ready for Moab by April.

Nevertheless I've started some preliminary planning, using a systems engineering approach. I thought I'd share what I've done so far as it might be of interest.

Wednesday, January 2, 2008

More on Spiders

Have you seen this article on an Carnegie Mellon / MIT spider that walks on water?

Some interesting ideas in here. Like piezoelectric actuators. Didn't know such a thing existed! And the newly discovered way in which water skimmers walk: by slighly pushing down on the water. Cool.

Best news to me is the spiderbot's parts only cost $10. Now that's impressive. And pretty inspirational for those of us without research grants. Here's some engineering guidance on biomorph piezoelectric actuators.