I notice I never really wrote about the expected improvements in the new hardware in detail, so I will try to comment some important points here.
Here is a table with some comparisons
| Old | New |
| Processors | Single processor:
| Two processors:
- ARM AT91SAM7X256 @ 18.432MHz
- AVR ATtiny84 @ 8MHz
|
| Program Memory (flash) | | |
| RAM | | - 65K (ARM) & 512bytes (AVR)
|
| Infrared module | - Receiver only,
- filtered carrier freq @ 40kHz
- max of about 5kbps
| - Can receive and transmit,
- IrDA pulse encoding,
- max of 115.2kbps
|
| Compiler | - Proprietary MPLAB C18
- C language
| - Open source GNU GCC
- C/C++ languages
|
| Debugging line by line | - Windows
- using proprietary MPLAB
| - Linux,
- Windows and
- Mac
- using Open source Eclipse
|
| Uploader | - Proprietary MPLAB programmer
| - Standard JTAG programmer (ARM)
- Standard SPI programmer (AVR)
- Implementing USB or infrared uploader
is also theoricaly possible for the ARM - It is also possible to make the ARM upload
firmware to the AVR
|
| Batteries | | |
Wheel radius
(this influences the resulting
linear velocity given the same
angular velocity) | | |
| | |
Based on the table above one can already expect there should a big leap in performance. Let's examine some details
SpeedIt may sound strange, but in this micro-robot more speed necessarily ends up consuming more CPU power. The reason for that is because we do not use DC motors, we use watch stepper motors. This eliminates the need for encoders, since you can calculate exactly how much the wheel has turned. But in order to make the stepper motor spin one has to switch the polarity of a series of magnets in such a way so that the axis of the motor spins forward and rest into the next stable position, then we say the motor moved one step.
In practice this means one has to send a pre-determined binary sequence directly into the four pins that drive the internal electro-magnets that make the wheel spin. The problem is that this motor set implements a massive reduction ratio of 1:240 in order to achieve the necessary torque to drag the robot body. This means the RPM at the shaft of the wheel is 240 slower than the actual speed of the stepper motor.
The frequency within which the processor switches the binary pattern to the wheels will ultimately determine the wheel speed and in a fast processor this can theoretically be implemented by using interrupts and a timer. In practice, however, the PIC18F1220 running at 4MHz takes so long to save and restore context into the stack and move the execution of the program fulfill the interrupt request that the wheel ends up spinning at an unbearably slow speed. So in the end we needed to implement the spinning of the wheels in the main loop of the program.
Another major issue is that the robot is so massive for the delicate motors and the reduction ratio is so huge that it starts creating an inertial effect as speed increases. In practice this means one cannot instantaneously start spinning a wheel at a high velocity without accelerating it slowly first. Then once at this high speed the pace of the stepper control has to be kept constant. One simple longer delay between any given two steps and the motor gets stuck and has to be accelerated again in order to recover its original speed. Since the spinning of the wheels had to be in the main loop in the older robot, whenever one wants to do something else, other than spinning the wheels stopping the wheels was unavoidable. This is the main reason why the old robots "shake" when they receive infrared commands. They are actually stopping, parsing the infrared command, and then resuming their work. As a software attempt to reduce the impact of the slow speed supported by the robots I implemented the so-called nitro speeds. The nitro command is a subroutine that temporarily disables all interrupts and carefully accelerates the wheels to achieve the absolute maximum rotation speed. While rotating at this speed any small jitter causes one or both wheels to lock in place, this is the reason why the infrared listening is deactivated during that window. Since the nitro was tuned pushing the motor/processor performance to its extreme maximum, sometimes one may experience the unfortunate locking of one wheel or another, therefore resulting in the outcome trajectory of a quick spin even when the command was supposed to dash forward.
In the new robot there is an exclusive AVR micro-controller dedicated only to speed control. This AVR controller has twice the speed and twice the memory than the previous PIC micro-controller of the older version. Moreover, this AVR controller will not have to spend CPU time parsing incoming data because it will receive commands directly from the other processor through an SPI port. The AVR has support for SPI protocol implemented in its hardware, meaning the receiving can be done in parallel and an interrupt request is only generated when the data is already available.
We truly hope the AVR micro-controller will thus be able to produce a more fine-grained range of consistent rotation speeds by actually implementing the stepper control via timers, as it should be.
InfraredThe older version of the robot has a kind of infrared receiver module very commonly used in house appliances. This module has an internal filter damping heavily any infrared signal outside the nominal frequency of 40kHz. This means this sensor returns a low voltage only when it senses a series of pulses coming at the specified frequency, otherwise it returns a high voltage (inverted logic). The actual data bits are encoded by variating delays of the the low voltage (pulses@40kHz) and the high voltage (no IR).
For example, the bit 1 could be encoded by 200ms of pulses @ 40kHz followed by 200ms of nothing and the bit 0 by 200ms of pulses @ 40kHz followed 400ms of nothing. The more the pulsing interval gets shortened, the less robust is the response of the sensor. Moreover, the parsing of the signal needs to be done via software, therefore wasting CPU time during the length of a command. One could trade-off command length in ms in exchange for spare time to allow context switching so that parsing could be done via interrupts. The problem is that commands have to be received at a minimum reasonable frame-rate in order to allow the robots to be controlled online in real-time.
Ordinary computers do not have hardware for implementing this type of encoding, so the 40kHz pulse generation has to be done in the computer side as well either by using some sort of kernel module such as LIRC or by acquiring some external device, like IRTrans.
The new robot has an IrDA transceiver, and the ARM micro-controller has a hardware IrDA modulator/de-modulator. The physical transmission of IrDA data is done via pulse encoding (as oposite to delay encoding). The IrDA modulation basically transforms square waves into pulses at their rising edges and can be implemented automatically by the processor. Both sending and receiving use the standard UART interfaces which also have hardware implementation of receiving and sending, meaning that the programmer has only to worry about the logic of the data received, letting the hardware deal with the timings and modulations.
Both the ARM processor and the IrDA module are said to support the maximum transfer speed of 115.2kbps therefore allowing much faster frame rates and more dense information exchange. This means longer commands can be used and nicer error checking methods can be implemented. Moreover, the intrinsic value of a missed command decreases when the frame-rate is higher.
For the computer no special software is needed, the IrDA transceiver will simply be seen as another serial device. The robot can also send information to the computer, as long as some software based collision detection & avoidance is implemented (all robots share the same physical layer)
We also want to allow the implementation of a more flexible protocol in this new robot, supporting both broadcasting and also addressed modes. In broadcasting all robots receive all commands and each robot just picks the information pertinent to itself from the chunk of data (mask out the rest) and execute it. This is because sending ids and parsing them is too much overhead and error prone when you just want to set wheel speeds. On the other hand, more intelligent commands could be eventually sent by addressing a specific robot in addressed mode. Examples could range from controlling the acceleration profile of the wheel all the way up to setting color segmentation parameters in a robot equipped with a camera.
