Subsections
6 Architecture
Last updated:
$Date: 2002/12/04 19:42:10 $
Some ``glue'' that will help understand the rest of this document:
Figure 4.1:
Global hardware
|
In figure 4.1 is presented the system as a whole (well, except the mechanical parts, OK).
We use two CPUs board at the time, possibly more in the future.
Rationale for this:
- Pros:
- allow parallel development (we don't see each other every day)
- allow subdividing the problem in smaller parts
- increased flexibility
- allow experimenting with more targets and technologies, eurobot is all about this
- Cons:
- imply a bus in order for CPU to exchange information (but a bus is needed anyway for ``smarts'' peripherals)
- increased integration cost
- increased hardware cost (more parts)
First and main CPU is a Motorola 68000 based board, the NF300 and its application board. This CPU is responsible for high level strategy and decision making based on information fed up by other CPUs and/or peripherals.
Rationale for this:
- Pros:
- we have one
- classic, well know 32 bit micro-controller CPU
- supported by the almighty GCC compiler
- ideally suited for this kind of embedded project (though when it was bought, we did not had the eurobot in mind)
- allow cross-development which is the whole fun of embedding. Not Intel.
- powerful enough to support high-level operating system
- lots of peripherals, booth built in the 68332 CPU and on the application board
- flexible (but complex)
- very powerful (though touchy) debugging capabilities, from inside the processor itself
- small, lightweight, low electrical power consumption for a 32 bit CPU
- Cons:
- NF300 CPU board as a very good quality/price ratio, but the application board is quite expensive
- complex (because flexible)
- touchy debugging system
The second CPU we use is a Microchip PIC 16F877. Right now it's dedicated to PID control of robot's moving.
Rationale for this:
- Pros:
- cheap
- fast
- widespread
- simple
- popular, and as a consequence tons of applications and documentations available
- Cons:
- no debug to this date
- poor, if any, free/open-source compiler support
Booth CPUs are connected via an I2C bus.
Rationale for this:
- Pros:
- cheap
- simple
- reasonably low I/O consumption to implement on a CPU compared to features
- more than enough addressing space
- native to Microchip PIC
- lots of application circuits
- off the shelves peripherals available and usable for robotics applications
- flexible (master/slave mode)
- Cons:
- serial, and so limited bandwidth
Main points, this modular design design allow us:
- concurrent development, which is mandatory for us
- expand ability and thus flexibility through a bus
and ``modular'' is always good, this design can be recycle on other projects
Figure 5.1:
Global software development architecture
|
Figure 5.1 outline the development system. Software tools and re-used code are parts of the robots as well as gear and electric wires.
The NF300 board run the RTEMS real-time executive.
Rationale for this:
- Pros:
- free and open source
- mature
- hard real-time
- small footprint
- GNU tool-set based
- cleverly designed and small enough so that you can actually understand it
- Cons:
- free and open source (DIY, read the source)
For a more in-depth presentation of RTEMS, see part VIII.
On the host side, RTEMS relies on GCC and newlib as well as other GNU tools. Newlib is an open source implementation of the C library specially targeted towards embedded applications (small footprint and fast, for a reasonable functionality loss cost). Programming and debugging is made trough BDM (Background Debugger Mode) built in CPU32 Motorola architecture, by the way of an host driver and a parallel interface - these two last elements being quite delicate - resulting on 80% of the power of an ICE (In Circuit Emulator) for 20% of the price. The serial port built-in the 68332 provides logging capabilities.
The PIC board, right now performing mainly date acquisitions and actuators, runs an interrupt driven applications. The development chain is an assembly of various tools, ranging from a free but close source compiler to a user space driver: the GPASM assembler is fed through the C2C compiler. Picprog is then used to program the device. The I2C bus, by the way of a serial/I2C interface (19), then give us logging capabilities as a substitute for debugging. Up to now, the PIC application is both:
- very real-time dependent (mainly data acquisition and output update)
- simple enough
... so that a purely interrupt driven code, that's to say without an OS is well suited.
For a more in depth presentation of the PIC tool chain, see part IX.
Synthesis till now:
The key point is the assets: this combination of hardware and software chain is flexible enough to be re-used on many kinds of embedded projects, being robotic or not, and allow experimentation on many techniques and tools.
Figure 6.1:
Global software system architecture
|
Finally, figure 6.1 show, err, the application software as we know it to this date. The NF300 will hold the knowledge about the match rules, and thus will be responsible for strategy and decisions. It will provide event logging for post-match (or post-mortem) analysis. On a smaller scale it will be responsible for:
- self positioning, based on field knowledge and input provided by the PIC motion board
- anti-collision
- target identification, grip and storage
- probably more... (to be continued)
botzilla@free.fr , http://botzilla.free.fr/