Next: 8 RTEMS Up: BOTZILLA PROJECT Previous: 6 Architecture Contents
Last updated:
$Date: 2002/11/27 20:05:54 $
This section is especially targeted towards students aiming to enter the eurobot competition.
So far was the project was presented in a very high-level manner, so before we dig in some nifty details we would like to say this:
The three of us added reach an age of more than a century. We're supposed to have some experience, here we will try to transmit some of this experience. You will find here some general advice, questions that you should ask yourself, and other philosophical stuff. Though we hope not to, some of this may sound pedantic, provocative or ``do as I say, not as I do''. That's OK, just think about it.
This is not about engineering matters as in OO versus imperative programming, UML design, SART, and such. Not that these subject are not interesting, but:
A robot is mainly a software project, not a hardware one. I'm terribly sorry if this comes as a shock. Note: the hardware guy on our own project is the first to agree with that. Love it or not, providing you have the budget everything is there for the hardware. On the other hand the robotic field as a whole is still struggling with software problems. So how does it come that most teams are from hardware cursus one may ask? Simply because a hardware person, these days, can't do without knowing a minimum of programming (note: I said ``programming'', not ``software engineering''). There's not much they can do without this minimal software knowledge. Whereas software persons are not taught hardware - they don't need it. A hardware-based team will be able to come up with a viable robot. Notice again I said ``viable'', not ``good''. A software-based team won't be able to bring a robot at all. So if you want a ``viable'' robot you need hardware people. But if you want a ``good'' robot, you need some software people.
So a robot is mainly a software challenge, but many if not most eurobot team come with a strong hardware bias. You do need a multidisciplinary team. If everyone want to do the hardware, it ain't gonna work. If everyone want to do the code, it may be worse! This may be a problem - did you considered presenting your school as a whole, with various competencies from different sections, rather than a team coming from a specialized class? Believe me it's a lot of fun and much more effective to work with ``another-side person'': focusing on your side, your motivated because you get the feeling that your special talent is used as it may be, you learn from each other, can delegate the part that you don't feel at ease with, and ultimately this is the just the way it's done in the real world (the industry).
Who do you need? A bare minimum would be an application software programmer, an hardware designer, and an embedded software programmer (that's to say someone with a good understanding of booth hardware and software) to make the joint. A mechanical designer is handy to: this is real craft, don't underestimate it. A system-administrator would be a great plus for all of them, and this need will grow as your team. If you find someone who's really good and willing at analog electronic catch him by all way, because this is a rare talent and one can can't be build overnight. Try to build such a team. There's no need at throwing more members to a project which is already unbalanced in the first place. Especially if the project is late on schedule: it takes time to integrate someone. If there's no other way, have the hardware people do so software, but never ever the other way around. Note: I (Jean-Baptiste Maillet) am a software guy, I did hardware too, believe me, I know.
Don't necessarily use what you have, use what you need. This one's for sponsored team. Example: because you have a sponsor which can provide you PCB, do not spent your time designing PCB just for the thrill of it. And don't over-design your PCB, making multi-layered design when single face would be enough. Because: your loosing time having fun with tools and means, loosing the project goal, you over-design, spending too much resources on side-features (especially bad in the industry), you become overly dependent on the sponsor. Because you would have a wheel sponsor would you put additional wheels on your robot?
Do you know what you need as technical tools and supply? Don't hesitate to challenge yourself. Don't necessarily use the tools at hand just because they are there. Don't try to adapt tools that you already know/use just because you already know/use them. This is the bad side of re-use (see below for the good side). This leads to immobility, narrow view and ``bloating''. If you're used to this micro-controller family, is it well suited? What about this other one? Don't forget the fun factor. You're still young and at school, there's no real risk, enjoy it and discover new things. In the industry, you'll be supposed to come up with new solutions to new problems: be creative and curious.
By all means avoid overkill. Don't use a 100,000 gates FPGA when a 10,000 would be enough. Don't use a Pentium III when you can use a 386. This is the worst kind of engineering that you can do: spending much more money than needed on a product. This is not the way it works in the industry (read this phrase again: this is not the way it works in the industry). In 1976, two spacecraft arrived on the planet Mars and after a 34 millions miles travel, collected samples, analyzed them and send back the results to earth. Do you think that more than 25 years from now they used Pentium? Or even 386? More recently the pathfinder mission launched another mission to mars: the rover vehicle is equipped with an 8 bit processor and 512 KB of memory. Right now in 2002, the launching system used for the NASA space shuttle is still made up 74xxx circuit and processor with a 64 KB address space (well OK, here it's a re-design budget versus maintenance budget, but still...) Let's take some example closer to us: during the 80's, the old Sun station a.k.a. the pizza box ran Unix system on Motorola 68k processors at a speed of a few tens of MHz, and Apple Macintosh on the same kind of processors ran Microsoft World, Excell, or some electronic CAD system. Today, look at the processing power of your mobile phone, of your PDA or of you hand-held video-game. Do you need a Pentium III to run the eurobot?
So this is supposed to be a software project, but we're advised to use some small CPUs, then you mean we shouldn't use an operating system? Yes you must use an OS for anything but the simplest tasks.. What other alternatives do you have? Wired logic is OK for specialized and/or sequential subsystems. An interrupt driven state-machine is still OK for simple automate-like systems, let's say a coffee machine or a data acquisition machine. It's complexity will grow endlessly and it will become a real burden with more and more regressions as your robot will grow up. Ultimately it'll explode in complexity for the task at hand in the eurobot. How will you had devices drivers? How will you perform such simple tasks as ``wait for 2 seconds on this job to see if anything happens, but in the meantime continue performing the jobs at hand'', or ``if the eurobot match is to be finished in 15 second, then go for the secret emergency plan right now''. Will your robot be able to do several things in the same time, like moving, analyzing its environment, and store the collected targets. You do need an OS. The world hasn't waited for today's CPU to come up with operating systems, and there's an hidden world between finite state machines and full-bloated OS like Linux and Windows. OS comes in all shapes and size, from a few hundred KB to several MB. Did you considered real-time executives, like uCOS, eCOS or RTEMS? these can fit in a few hundreds of KB, provide hard real-time capabilities and a more feature rich API that you'll need. Even on 8-bit CPU like Microchip PIC, primitive operating systems are available TODO: link here.
But what if it don't get the drivers I need? Do you mean I may have to develop my drivers myself? Yes, I do mean that. As an hardware designer it will be you job to provide the software team with a good enough specification and possibly firmware so that they're able to do so. As an embedded software programmer it will be you daily job to deal with the bare-silicon and make it alive. Be prepared, this will be your job for years. But don't forget to re-use. If you choose an OS by its driver set, then you're probably choosing a CPU and a development chain too as a consequence of the OS - you're taking it the wrong way.
Re-use. The rule here is ``find the guy who already did it''. Admit one for all that you're probably not the first one to stumble on a given problem. Come on, you're not so special - I'm not, I know. Forget the ``here, we have a really special problem that nobody can help us with'' attitude. The Internet is a wonderful tool: source code, and to a lesser extent electronic designs are just there waiting for you. You want to do I2C? Do you know that not only tons of hobbyist code is available for it, but also that rock-solid production code for I2C is available in the Linux kernel? Need to do some USB? Same thing. Need a driver, a BSP? Are you sure someone didn't make it already, did you looked for? Even if you can't use it as is, there may be there the precise bit of information you just needed. And dealing with other's production will be your job too in the real world. The same goes with hardware: do you really think you have to develop a CPU board? Did you look at the existing one? Wouldn't your time be better spend on some peripheral design (and still, there are lot of peripheral boards available). Don't worry, you'll have enough to do with integration. This can't be emphasized enough: do not re-invent the wheel.
Choose software tools first, hardware second. The hardware almost always dictate the software, the reverse is rarely true. You don't want to be dictated things. Hardware is cheap: think of the capabilities you can have with a cheap USB web-cam. Software is expensive: think of the cost of the development tools MS (Visual Studio/MS SDK?) and possibly underlying OS (Microsoft Windows?), consequently underlying hardware (Intel PC?) host CPU associated, associated with this web-cam. Does this as a whole fit your needs? Do you want to design your system as a whole because of this USB web-cam? This would be taking the problem reverse-side.
The fun factor. TODO.
The reality factor. TODO.
Invest on yourself. TODO.
Document, document, document. TODO.
Forget the ego factor. In France at last thanks to media coverage, the eurobot as became really important for some schools. For such school's teams, the goal is not to compete, the goal is to actually win. This as some unfortunate sides effects on the competition spirit itself, which is a problem, and on some team/individual behavior, which is another problem. On the former, this is ANSTJ's job. On the latter, we would like to convince you that winning is not the goal. You may be convinced that a good score at the Coupe de France de robotique/eurobot is a good point on your resume for when you'll leave school. You' re wrong. First, this score is supposed to be a team result. You can't take personal credit for it. Second, and most importantly, a good score on such competition may be a valuable point on your resume when fresh out of school, though not necessarily, but in a couple of hear as your experience will grow up this will look funnily childish and anecdotal, if not geek-ish on its worst sense. Your score on the competition will be meaningless. Whereas if you can say/put on your resume ``I used/developed an operating system on 8/16 bit CPU'', ``I developed device drivers for this and this peripherals'', ``I was responsible for the system administration of a 15 persons development team'', ``I integrated an image analysis library in an embedded development environment'', this will be hard-facts that you'll be able to take credit for. These realizations - yours - won't wear out before long and will proof your professional attitude from school time. In order to do this you should of course document your work and be ready to display it proudly (no ugly code and straps all over your boards please). I don't talk about the nifty implementation details: I talk about the how's and why's of your project. We're not in marketing, we're in engineering: enhance your craft, not your market score.