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