This report discusses the processes involved in constructing a multi-robot exhibit designed to demonstrate the configurable priorities of autonomous robots' behaviours and the responses. The ultimate goal is to have a self-sustaining system with up to 15 robots in an exhibit -- this article however is a report on the development of four demonstration units prepared for the Science Rendezvous as an early systems prototype. The robots would freely roam their designated area avoiding collisions with obstacles and where encountered follow a line on the ground or one of four light sources. Upon experiencing low battery power, the robots will seek the recharging stations and drive up into them to recharge their batteries. Once fully charged, the robots will drive out and continue their normal behaviours. Each individual robot could also be remote controlled to allow observers to participate in interactively manipulating the robot and its priority of allowing an encounter of ground line to break its trace of the light source and vice versa.
The body of every unit was constructed by hand whilst utilizing off-the-shelf parts for most of the construction; such as casters, wheels and motors. Electronically, an onboard Atmel ATMega644 MCU controls each unit as well as process instructions sent from the central control system, the "CA" (Central Authority) via 2.4GHz RF systems.
Objective was to have an autonomous vehicles that were capable of:
To avoid colliding into objects, and each other, the vehicles need some form
of mechanisms to sense their surroundings. The simplest method is using lever
switches attached to bumpers on the robots and allowing this mechanical form of
obstacle detection (through contact) to have the robot sense each other and
obstacles in vicinity -- this is the simplest technique and the least complex to
implement. The concern arises when objective #8 is made part of the design
consideration; operating for extended periods of time, the switches will
experience multiple triggers through the countless interaction between the units
which could wear the switch out and lead to a mechanical failure in a particular
switch. More importantly the bumper triggers rely on intentional collisions to
detect obstacles, purposely colliding with each other, no matter what the speed,
would eventually lead to body damages and could propagate into the sensitive
electronics inside and could knock any component free causing unexpected
behaviour from the unit and contributing to permanent damage to the hardware.
Repeated stresses would also have similar ill effects on the batteries of the
units and could knock any unsecured battery loose.
The non-mechanical approach to this problem would be to either use ultrasonic range finding, laser scan or infrared emitter and detector pairs. The most accurate choice would be to use the laser obstacle detection modules which would give the most precise distances between it and the obstacles. However considering budget and time allotted for the project the suitable choice for collision detection was the IR emitter/receiver pairs. As figure 1 illustrates, the setup would be an emitter projecting 850-940nm IR light at 1.2V, 30mA out from the body and the receiver collecting the rebound light. After the construction of the robot, the voltage supply to the emitter would be calibrated so that on the IR only rebounds off of objects very near the robot.
Immediately several impediments in this plan are encountered, two of which are critical and must be addressed before anymore work on the design can occur:
The invisible light
Unfortunately the robots will not be housed in a dark enclosure and that means there will be light present; light from the overhead spot lamps, tube lights, and possibly even the sun if the exhibit is places anywhere near a window. These sources of lights will almost certainly carry large quantities of energies in the infrared band and interfere with the robot's ability to accurately detect obstacles -- a direct view of the evening sunlight pouring in at an angle will be enough to set the IR phototransistors off and signal a false positive to the robots and unexpected behaviours will follow.
Earlier work in Ryerson's CPS607 course brought the concern to light when the sensitive phototransistors used to detect an IR beacon caused robots to drive towards the windows and the doors as well as the erratic behaviour observed in robots following lines during the morning hours when sunlight reflected into the hallways of the building.
The solution employed in this project was the technique used by television remote controls to transmit control signals to their sets. The IR signal is modulated at the carrier frequencies -- a concept not unlike the modulation used in transmitting signal over some other physically transmittable signal, while manipulating either amplitude, phase or frequency. In this case the remote control sends key codes (e.g power codes to turn the TV set on or off, change channel or alter the volume) modulated over some carrier signal frequency. This modulated IR pattern is distinctly different from the random frequencies that are otherwise flooding the space where the robots are operating. If the receiver is tuned to the carrier signal frequencies, generally in the range from 30 kHz to 60 kHz, and if the emitter modulated at the same frequency as the receiver is listening to, the MCU should detect high and low alternating patterns on the receiver, even if no filtering and amplification are applied. To make this work easier, inexpensive IR receiver packages exist that perform band pass filtering, amplification and signal to TTL conversions such as the TSOP4856.
Figure 2
Figure
3, TSOP4856
© 2001, San Bergmans, www.sbprojects.com
Figure 2 shows how the modulated signal causes a "low" output on the receiver output. Packages such as the TSOP4856 perform similarly where detection of any signal modulated at their tuned frequencies (in the case of TSOP4856, 56kHz) causes a "low" output. This is particularly convenient as for the purposes of this project, there is no need to transmit modulated binary data -- just a constant output of modulated signal from the emitter at the calibrated voltages and any reflected signal detected by the TSOP4856 would trigger a low on its output pin, a TTL compatible solution that's easy to work with with an MCU.
Robots Shining Modulated Signals In Each Other's Eyes
While the IR setup is great for an individual robot to detect obstacles, it becomes a problem when multiple robots are near each other. Light from any one particular robot could directly enter the receivers of other robots simulating an obstacle detection for robots that are outside each other's collision vicinity. The robots' IR emitters are calibrated with enough intensity to have the light be detected after being reflected -- calibrations must take into account that the beam will lose significant energy when rebounding off the obstacle's surface. Therefore in the case where one robot causes false detections in another robot the beam normally, in a straight line, has enough intensity to trigger an obstacle avoidance behaviour in the receiving robot more than twice the distance for which each robot has been calibrated for obstacle detection.
There were a few possible solutions to this problem.
Different Carrier Frequencies for Each Robot
Assigning different IR modulation carrier frequencies to each robot was a simple
solution, however manufacturers of integrated devices like the TSOP4856 only
produce for a handful of frequencies. With our goal of producing up to 20 of
these robots and having anywhere from 10 to 15 active at any given time would
require at least 15 different frequencies, yet the TSOP family only has up to 4
different frequencies. This solution would evidently not work.
Different Carrier Frequencies With Custom Receiver
Setups
While manufacturers may have provided only 4 or 5 different frequency packages,
it was possible to use a simple IR phototransistor to manually perform the same
operations as the TSOP family of devices, and tune it to any frequency required.
This would allow each robot to have it's own frequency and avoid the
interference problems. The issue with this solution is that the
phototransistor's output must be filtered and amplified then monitored by an
accurately timed counter calibrated for each robot's assigned modulation
frequencies, a very resource intensive task. With each robot having up to 6 of
these receivers and each positioned to detect an obstacle on its respective side
of the robot (must have individual detection, rather than a single signal summed
from all the phototransistor outputs) the task would be very resource intensive
and require multiple dedicated MCUs to accomplish. While there maybe methods
like "switching" between the phototransistor and thereby using only one MCU
,
the method was still very time consuming and required time to develop and test.
Under budgeted time this method was one of the things that would have to be
dropped.
Angled emission, scoped detection
The simplest technique to have the robots avoid interfering with each other was
discovered to have the emitter and detector mounts be on an angle below the
horizon's 0 degrees. In this manner the emitters would be facing the ground
ahead with very narrow beams and the detectors themselves would have similar
angles to maximize detection whilst minimizing interference with other robots.
In figure 4, it is desirable to have the robot detect obstacles as far away as
10 cm from the robot's body edge. The height of the sensor mounts from the
ground will be 6 cm and that yields an angle of 31 degrees down from horizon
that will allow the robot to detect obstacles up to 10 cm away from the robot.
This was an acceptable low cost alternative to the methods above of limiting IR
interference between robots. The emitter and receiver sensors would be mounted
behind the robot's "walls"; and it is in these walls that the holes will be
drilled on the determined angles -- so that the emissions occurs roughly in a
beam and the receiver would be mostly receptive to the light reflected back at
the same angle.
Note the interference would continue to occur, but less frequently as now the direct line of sight possibility is removed, any interference would be scattered reflections from the ground and would need an alignment of two or more robots, more or less 20 cm apart, there by limiting direct visibility and reducing chances of direct interference.
After the obstacle is detected the robot needs to respond by executing a
manoeuvre, most likely a 90 degree turn to the left or right or in the even that
those directions are also blocked, a 180 degree turn to drive out of the
situation. However in robots with traditional bodies where the motors and wheels
are placed in the very rear and a castor in the front, creating three points of
contact with the ground, turns can also be a cause for collisions. This is due
to the rectangular bodies of these robots and the front segment of the robot
that is outside the wheel turning circle and literally dragged into the position
during the turn as the image explains:
This segment can either collide with other obstacles or in the event that the
robot drives into a "channel" wide enough for it's body, but not width enough to
accommodate its length, the robot will be indefinitely stuck unless it reverses
back out. The solution is a circular robot body which means it can turn in-place
and face any direction without the overhead of the collisions encountered by the
long-body robot. However designing and building a circular frame requires
precise planning and machinery, something that the budget did not permit.
Instead it was found through the prototype development that an octagonal frame
would be optimal for the robot as it will be have 8 straight edges to which any
panel can be mounted containing sensors and the straight edges meant it can be
cut with low-tech and inexpensive tools. Other shapes such as decagons and
hexagons were also experimented with, but their edges were found to be either
too steep with respect to one another or too small to mount sensors. The octagon
provided a front-facing edge and two angled sides to mount the obstacle
detection on, as well as two left and right edges to mount beacon detection
sensors on and as such was deemed the perfect alternative to a circular frame.
The design called for having the capability to acquire and follow a line on the ground. To minimize costs and resource spending -- such as preserving battery power and the ADC pins on the MCU (the system already used a 3-to-8 multiplexer to extend the number of devices that the MCU could perform ADCs on, however those 8 pins were already full and having comprehensive sensing capabilities for the ground line tracking would require more multiplexers, putting yet more stress on the power supplies) it was optimal to use two IR Emitter-Receiver pairs (the TCRT5000L) to acquire and follow the line. The IR light in these did not need to be modulated as it was underneath the robot, away from the edges and close to the ground, ensuring minimal interference from outside sources (such as the sun). The emitter's light intensity was calibrated and so was the receiver to make the largest voltage change possible in the voltage divider created with a resistor and the photoresistor (the IR receiver). The modules were placed apart with a distance of 2x the width of a standard electrical tape. This allowed the robot to utilize simple detect-and-turn algorithms that would see the robot 'bounce' off of the line as it traveled down the path; but the 2x the tape width distance meant that the sensing wasn't very 'tight' nor was it very 'loose'. The robot was instructed to turn less than 15 degrees in the direction of the activated sensor and then continue moving forward -- this reduced the jerky motion associated with the 'bouncing' method. Furthermore the motor speeds were reduced to about 4.5 cm/s to give the robot plenty of time to not only react to obstacles (and thereby prevent damage associated with collisions) but also allow the ground facing sensors to acquire and follow the lines without losing the line that would otherwise happen with faster robots -- and correcting that would need more sensors and more resource intensive algorithms such as the PID algorithm.
Robots must also be capable of detecting and heading in the direction of a light source. Like all the other sensor medium, this too was selected to be IR. As with the other sensors that were affected by external light sources, this too would be affected and as such it was fitting to adopt the modulated signal for this task as well. Four beacons of which one could be active at anytime would be placed at each of the four corners of the exhibit facing inwards towards the center. A column of singly stacked IR emitters, modulating at 30kHz with a constant high signal would beam the light into the exhibit with enough intensity to reach the opposite end of the region. A user-interactive mechanism allows the participant to turn any of the four beacons on at any one time.
Detecting the beacons
In the early prototype there was a single 30kHz IR TSOP package mounted on a high platform above the robot, looking out front with a cone in front of it to create a "tunnel vision" so that only when the beacon is straight in front would it receive any signals. When the TSOP receiver was "activated" by the light, the robot would drive towards the source until it lost it or a collision avoidance routine was triggered (either by the walls of the exhibit or an obstacle in the path) at which point it would turn and veer off. This method was a balance between the viewing angle and how wide the detection range was. However the speed of the robot, as slow as it already was, was a big factor in the instability of the method. The detection happened in a very specific angle and as the robot turned to center itself with respect to the beacon, it either lost the source of the light (by over turning) and if it back tracked to recapture the beacon, it performed static movements and become occupied in repeated turns as the detector periodically detected the beacon on each turn and caused the robot to attempt to center itself again. Slower or lesser turns gave an unpleasant feeling to the robot's smooth movements when attempting to follow the beacon.
The solution was to have three 30kHz IR TSOP detectors on each robot to detect the beacon instead of one -- on the front, left and right side of the robot. This allowed directional sensing and prevented the problems above. When the beacon was encountered by only the side sensors the robot would turn 90 degrees in that direction, if the front sensor is activated along with any of the side sensors, the robot would turn 15 degrees incrementally until only the front sensor was activated. If the sensors 'lost' the beacon, the robot would not try to recover the signal as the side sensors are likely to find the source again frequently.
As part of the demonstration of behaviour prioritization, the design called for each robot to be able to have its routine and task orders rearranged by the user. If the line following was first priority then the robot would prioritize the routine for following line over beacon following and vice versa. In this regard, if the priority was following the line and in the event that the robot was at any moment engaged in the line following routine and should its beacon sensors detect the light source, it is to ignore the beacons and keep following the line. Similarly, if the robot was driving towards a light source (beacon) and it encountered a line on the ground, it would stop driving towards the beacon and instead start following the line on the ground. Alternatively, it would do the opposite if the priority was following the light source instead of line following. Allowing the user to swap the order of these routines individually in any of the robots was a principal objective in this demonstration.
For this purpose there would be a need for a console from which each robot could be given certain instructions. Given the expanding nature of the requirements, should there ever be need to have the duplex communication between the robot and the console, there would have to be a radio frequency based communication device which would work on the same frequency, but allow each robot to be individually addressed. The initial choice was bluetooth based systems where each robot could be paired with the central authority (the console) at which point duplex communication would begin. However price of the bluetooth units is particularly high and pairing any number of robots to the console would not be trivial. The Bluetooth piconet supports only 8 devices, with one of those being the master and the remaining being slaves because of the 3-bit MAC address. Yet this project called for upwards of 20 robots with up to 15 active at any given time, as such there was a desire to seek out cheaper alternatives that could support more devices. The most suitable and relatively inexpensive solution was from Nordic Semiconductor, the nRF24L01+ chip. The nRF24L01+ is a transceiver chip that operates on the 2.4GHz bandwidth, capable of transmitting and receiving on multiple channels, packet-based messaging and most importantly the packets can be addressed to any particular device listening on the communication channel that's in use. SparkFun Electronics offer a prefabricated PCB module with the voltage regulator, crystal and the ceramic antenna soldered on it to make the nRF24L01+ a drop-in solution and that is what the robots and the CA use to communicate with each other.
When powered on, each robot registers itself with the CA with its unique ID
allotted to it when it was programmed. The CA then allows the user to select
from a list of registered robots to toggle between their behavioural priorities.
In the event the robot senses malfunction in any of its subsystem it reports
this behaviour to the CA, moves to the nearest exhibit wall (if possible) and
powers down.
Like design requirement number 4, setting priority override of the
behaviours, being remotely driven is another design requirement that aims to
allow the users to directly interact with the robots and more importantly create
an environment of uncertainty inside the exhibit and observe how other robots
react to the user induced events. And not unlike the requirement above, being
remotely driven requires the selection of the robot to manipulate via the CA and
then using a joy stick manipulate the robots. Instead of the toggle-behaviour
command being sent to the robot from the CA, a "capture" command would instead
be sent disabling all of the robot's autonomous routines. When 'captured', the
robot would not move on its own and instead move only when the user controls its
via a joy stick. Because the robot is 'captured', it would not honour any beacon
tracking or line following routines, however will always prioritize collision
detection over user commands to prevent colliding into objects or another robot.
After 2 minutes of inactivity from the user with regards to remote controlling
the robots, both the CA and the robot independently break out of the capture
mode and the robot would switch back to normal operations.
To ensure the exhibit continues to operate without unnecessary human interventions and that it continues to operate without much maintenance, it was necessary to have the robots recharge their batteries automatically. Several method were explored for this task -- including solar panels, and recharging station concepts.
Solar panel was the most intuitive concept where the panels would sit atop the units and continuously charge the batteries as the robots drove or the robots would drive up to a lamp to periodically recharge their batteries and commence normal routines. Solar panels available through retailers offered adequate voltages and amps but were deemed too expensive to affix with every unit and with time would collect dust on the surface, reducing the current output.
The recharging station was a less out-of-the-box and more labour-intensive solution but was deemed less expensive so the next step in preparing the full-scale exhibit is to implement this concept -- as it was not implemented in to the demonstration for Science Rendezvous. The recharging station is designed in the shape of a large circular carrousel with up to 10 slots and one port of entry, large enough for the robot to drive up into one of the slots, after which the unit revolves to expose the next empty slot. Every robot unit will have 4cm2 pieces of exposes copper on the left and right sides, when the robot has driven itself up into the slot of the carrousel it will break the IR beam of the slot and trigger the recharging routine -- two spring-loaded contacts will rest on the exposed pieces of copper on the body of the robot and begin charging the batteries. The robot's on-board bq2002C charge management chip will manage the recharging of the battery pack and once fully charged will notify the robot's MCU, which then notifies the CA. CA queues the robot for discharge from the charging station. Once the carrousel is ready to discharge the robot, the carrousel will spin around that particular slot to the port of exit and notify the CA, which then instructs the robot to reverse out of the slot.
The robots will locate the port of entry using the same concept as the light source following -- however instead of the 30kHz modulation, this will be 37.9kHz modulation and the robots will again have the same placement of the TSOP devices (for the 37.9kHz detection) on the 3 sides of the robot to assist in locating and driving up to the recharger. The first 20 cm of ground leading up to the carrousel's port of entry will be lined with IR contact-break sensors. If it is detected that the robot is moving towards the port of entry via those sensors, the CA will instruct the robot to disable it's obstacle detection routine and activate the line following routines. A line will then assist the robot drive straight into the port of entry. Once inside the slot, a mechanical switch will be activated by the robot causing the CA to order the robot to disable all routines, motors and cut power to all sensors and emitters to preserve power while recharging. Upon completion of the charge, all routines on the robot will be brought back online.
The next issue was to decide what type of battery would be used in such a scenario. The de factor choice of battery type in all modern light weight robotics is usually Lithium based. Lithium Polymer batteries, specifically, have many advantages over the conventional Nickel Cadmium and its more superior sibling, the Nickel Metal Hydroxide and of course Lead batteries are far too heavy, dangerous, and require, as well as provide, higher voltages than are necessary for this project and as such it was not even considered. Lithium bat
teries have higher discharge
rates and continue to provide
near constant drainage (source:
ibt-power.com, graph shows the draining of a single battery, charged up to
4.2V at 0.5 C, at various C's [the multiplication factor of it's rated mAh
capacity]) until the battery has been considerably discharged. They can also are
capable of going through more charging cycles (than NiCd/NiMH), have low
self-discharge rates and are the lightest of the three types. However the
disadvantages of the LiPo batteries were of grave concern for this project. LiPo
batteries are very sensitive in their charging states to over charging and in
their discharge state to being overly discharged -- both conditions can lead to
fire hazards and explosions, and in an exhibit where the robots are to run
unchecked and unsupervised the last thing needed is a melt down. Many batteries
however come with overcharge and over-discharge protection circuit that protects
the battery from entering hazardous states. Unfortunately because of the need
for 5V circuitry operating voltage and 5+V for motor operating voltages the
standard 3.7V LiPo cell would not be enough, it would have to be wired in series
with another 3.7V cell to create an adequate supply of 7.4V. Since charging LiPo's is such a sensitive task, it requires professional chargers and each cell
must expose its "taps" (direct line to each cell to detect its voltage and
assist in balancing the charge -- otherwise any of the cells can become over or
undercharged giving a false average reading to the charger and exposing the
setup to fire hazard). This setup was becoming expensive as the batteries
themselves were relatively more expensive than their NiCD/NiMH counter parts and
on top would require a professional charger on each of the charging station's
slots and this meant that not only would the ground/positive pads need to be
exposed on the robot's body, but also pads for the cell taps. These concerns
forced the consideration between NiCd and NiMH battery types, leaving out the
LiPo batteries. NiCd is better in every regards than NiMH except four pivotal
aspects; Firstly NiMH is "environmentally friendlier" than NiCd due to the
absence of the highly toxic cadmium, secondly it can hold about 30% more charge
-- giving a longer charge life and thirdly the self-discharge rate is 5% per
month, as opposed to NiCd's 10% for the first day, then 10% per month. Lastly,
and probably the reason NiMH was preferred over NiCd, was it being less affected
by the "memory effect" which the NiCd is so infamous for. NiCd may be prone to
the memory effect if they are discharged up to a sane level and then recharged
over several cycles. This causes the battery to memorize the point at which
recharging begins and when the battery's charge reaches that level and is not
charged, the battery suffers from a sudden voltage drop. As the device continues
to draw current from the battery, it dips past the "memory effect" point and the
voltages return to normal. This drop in current however would reset the robot
causing all states to be lost and because the memory effect is likely to occur
when the robot is low on charge and possibly seeking the recharger or driving to
it, it would be disastrous to have the robot have its systems reset at that
critical time. As such, despite NiCd needing less sophisticated charging
circuits, no explicit trickle charging, low heat emission from charging, higher
discharge rate, being capable of withstanding very fast charge, and more
recharge cycles, despite all that, NiMH batteries were preferred because of
their larger capacities and low me
mory effects.
Much of what the exhibit is about is observing the automation of the robots and as such the observer must be able to see the robot acquiring the line to follow or moving away from it to follow the light source. The prototype 1 used small 6V motors that have 100:1 gearbox in the front (figure 5). These were pwm'd by the MCU to control the speed, however the robot's body was too heavy and the torque was not enough to allow the these motors to pick up the load and over come the inertia. The MCU was performing dynamic PWM to ensure the speed of the robot stayed slow enough to observe the behaviours and prevent unwanted collisions. From a dead stop, the MCU would increase the PWM until the wheel encoders recorded the optimal wheel revolutions, however since the motors were not capable of moving the robot at voltages less than 5V, the robot would jump start at that point and the MCU would attempt to slow it down by reducing the PWM once the encoders detected revolutions above the optimal. The behaviour was acceptable so far, however as it encountered an obstacle, it would break the motion and turn around in the desired direction to avert the collision only to be stalled once again and the MCU would have to raise its PWM again. This cause a 'jerky' motion in the robot's movements which was not desirable.
To alleviate the problem, the second prototype featured high torque 6V motors
with gearboxes. They spun slowly which was naturally desirable as no PWM would
be
required to slow the robot down and the freed MCU resources can go towards other
priorities. Now that the robot was not moving too fast, the wheel encoders were
deemed unnecessary and an expensive part that would reduce the cost if purged
from the design. This created the problem inaccurate turns and non-synced wheel
motions that made the robot sway one side or another. These problems were not
any major concerns as the robots would never be involved in any activity that
would require accurate positioning. The turns were timed and calibrated using
fully charged battery packs (as well as almost dead battery pack) and during the
robot operations a voltage divider battery sensors senses the battery levels and
manipulates the turn times by creating a ratio from calibrated ranges of the
turn time of a fully charged battery pack and the turn time of an almost dead
battery pack. By acquiring the voltage of the battery the turns times can be
shortened or lengthened to ensure proper angled turns.
Figure 6:
The frame of the first prototype with motors and
castors.
The material of choice for the frame was acrylic -- strong, durable and visually appealing. The design envisioned robots of uniform looks with few varying colors to create some distinction as well as give a sense of individualism rather than uniformed drone appearance. In keeping with the octagonal design of the robots the frame would have three layers;
The chassis plate was designed in CAD with a diameter of 19 cm. Early on in the design phase it was decided that to prevent the wheels from colliding with other objects and as a bonus side effect of a smaller turning circle (which in turn meant faster turns), they would be placed with-in the perimeter of the robot body (figure 7). This meant designing and cutting out precise locations for the motor mounts and the "wheel wells" for the wheels.
Since the "wheels wells" now reduced the flat useable area on the chassis, the other components, namely the PCB of the controller circuit didn't have enough space to sit flat against the chassis. They would have to be raised on mounting stand-offs leaving about 2.5-3.5cm of space underneath it -- the perfect height for the AA NiMH battery pack of 6 cells to be secured under it.
The
CAD drawing was stencilled into the shape as seen in the image on the left. From
this stencil, eight plates' perimeters were marked and four of those plates were
marked with the additional motor regions and the wheel well markings.
Drawn in QCAD Community Edition. Win32 builds compiled by ximuntxo.
As 3-D printing prototyping and access to workshops was not possible, all
constructions for the 4 robots prepared for the Science Rendezvous would have to
be done by hand and inexpensive power tools. A Jigsaw (pictured) was used to cut
the plates from the acrylic sheets, a miniature drill press was used to create
pilot holes for the wheel wells large enough for the blade of the jigsaw to
enter a start cutting out the holes.
In the original prototype, prototype 1, there were a few
things different. Specifically the motors and the sensor placements.
Light weight, high speed motors were used which were later dropped from the
design due to their lack of cold start torque. The sensors in this prototype
were bolted to the chassis via two thin strips of tin that could be adjusted to
set the visibility distance from which objects can be detected; entire panel of
sensors would tilt back and forth to obtain the appropriate emission angle. This
was superior to the drill-at-al-angle concept that was later employed in the
demo versions of the robots, but because of lack of aesthetics these strips of
tin were dropped from design.
Left: The first prototype, powered by the Arduino Duemilanove variant, Freeduino.
The
Right: Portrait of the first prototype; IR receivers and emitters visible in the
three panes -- 6 emitters and 6 receivers, forming roughly 140 degrees of
forward visibility to help detect obstacles. Panes bent forward roughly 20
degrees.
This photo
shows the underside of the robot chassis. In the first prototype, the batteries
were mounted underneath and towards the back of the body. However this added a
lot of weight to back of the robot causing obvious problems when making fast
turns, also because of the inaccurate alignment of the battery pack (no
perfectly centered) the weight shift caused the prototype to veer off slightly
to one side. The batteries would also eject from their sockets on fast
manoeuvres and shut the robot down. The final design placed the batteries on top
of the chassis, inside the body, facing upright and secured using screws. The
pack has also been centered and there is evidence of less veering and smoother
turns. The first prototype also had the line following IR sensors places as far
away from each other as possible, almost near the edge of the body, this causes
the robot to have significant side-to-side scanning-motion as it followed the
line by 'bouncing' its sensors from side to side as it crawled along the path.
The final design has the sensors places at a distance of twice the width of the
standard electrical tape apart -- making the side-to-side motion less intense
and barely noticeable.
To address the concerns discovered with the first prototype, notably the motor issue, a second prototype was built. To make the body of the robot even 'rounder' the chassis was experimented with and made into a decagon. The material was also changed to the less expensive wood pressed-board instead of the thick acrylic. This second prototype was aimed at reducing cost of the units -- the expensive hardware on the first prototype was the motors and encoder wheel set, the castors and the acrylic itself. To trim bulk of the cost this prototype was designed to not only address the practical issues of the previous motors being too weak to move the robot at a slow and stable pace, but also getting rid of the expensive hardware bulk. Unfortunately the parts involved in this motor setup (wheels, couplings, and the motors themselves) totalled up to the cost of the encoder wheel set -- but the motors were powerful enough to carry out the requirements of slow, relatively steady movements. The coupling also had the flaw of slipping off the motor's gearbox shaft, during operation. This physical problem would be catastrophic in a self-operating environment that these robots were being designed for. Another alternative motor was discovered that was cheaper, lower voltage and allowed the wheel to sit directly over the gearbox shaft and be screwed in, eliminating the possibility of the wheel slipping off during operation. This is featured in the final build.
(here the
camera is looking down on it from top, front -- its 'nose' being outlined by red
'dashed' lines.)
The electronics to control all the behaviours of the
robot and provide the logic behind its decision meant it had to be a digital
circuit with a programmable microcontroller. The s
election
was simple, either Microchip's PIC or PIC based (PICAxe) MCU or Atmel's AVR
based MCUs. These two brands dominate the hobby industry and provide inexpensive
and powerful processing capabilities which are readily available in local
electronic hobby shops. Given the popularity of Atmel's ATMega brand there are
plenty of third party tools available for it, in particular the AVR-GCC, which
allows developers to skip the low level assembly instructions and write in the
well versed c/c++. This tool is open source and follows the ANSI standard
meaning one project will compile everywhere and on every platform to the very
same Intel HEX code for uploading into the MCU. Whereas the Microchip's PIC has
no stable opensource gcc-like tool and the two major commercial compilers have
differing key aspects, including syntax and constants. Meaning if a code is
written with one commercial product, it most likely will always compile with
that product. Hence it was because of the abundant tool sets and support
available for the AVR platform that it was decided that an AVR MCU would drive
the units. Given the number of sensors and supporting subsystems attached to the
MCU, a larger MCU -- such as the ATMega32 or the ATMega644. Plenty of code space
for large code write up and 40 pins with 4, 8-bit ports means plenty of pins to
communicate with subsystems and have some left over for further expansion and
upgrade of the circuitry to provide more functionality in the future.
The ATMega644 can run between 1 (8Mhz default oscillator with an eight-divider) and 20 MHz, using a 16.000 MHz crystal, the robots run at 16 MHz clock speed (so that the system is backwards compatible with the ATMega32 chip salvaged from the 2nd Prototype -- the ATMega32 can run at a maximum of 16 MHz), plenty of speed to perform obstacle detection, line detection, beacon detection, LED controls, managing driving logic and communicate via RF.
Since the system ran on such a fast frequency, there wasn't a large enough divider to obtain the slower frequencies on the timers required to PWM the IR emitters for obstacle detection. The timer overflow is already reserved for another purpose and as such cannot be used for this purpose. This meant having a separate chip to PWM the IR emitters and the perfect candidate was the PICAxe 08M, 8-pin versatile MCU. The simple language syntax of BASIC-like language used by PICAxe meant writing one line code to have the relatively inexpensive 08M PWM its output pin from power up till power off without any further circuitry or code. To protect the 08M from becoming a high current source, a high current, high frequency transistor is used to switch the emitters.
There are 14 IR sensors on the each robot (six 56kHz obstacle detectors, three 30kHz beacon detectors, three 37.9kHz recharging-station's beacon detection and two line following receivers). The MCU is merely checking for the output of the phototransistors to be above or below a certain threshold (ADC), yet the MCU only has 8 ADC lines. The solution was to use a 3-to-8 multiplexer chip, the 4051; eight of the twelve lines feed into the MUX and 3 I/O lines from the MCU are used to address the MUX which feeds the output into just one ADC pin. The remaining 4 sensors come right into the ADC port, plus another pin is used to detect battery voltages, in total using 5 ADC pins.
The MCU controls the motors through a quad half-H bridge motor driver chip, the SN754410 by Texas Instruments. The chip switches to high impedance state, Z, when the motor's enable (EN) inputs are set to low, causing the motor to coast. This feature can be used to PWM the motors, however since the motors used in this project are already considerably slow there was no need for PWM the EN pin. Instead, the EN pins are driven to ground and the motor is stopped (breaking) by setting both control inputs to the same levels (either both high or both low). When the charger circuitry is implemented, the ground pins will sink through a Darlington transistor, controlled by the MCU. During normal operation the Darlington will allow the sinking of the current, however during charge, the MCU will close the sink. This is to shut the entire chip down and not just set the EN pin to low to turn the motors inactive -- thereby preserving battery power and providing a faster charge. In fact the MCU will shut almost all non essential components and wake the important components up periodically to process information. This will include the RF transceiver that will be awaken and used to send charge progress to the CA, then shut down again once both sides have communicated.
To communicate with the computer during debugging sessions the circuit needed a serial-to-ttl level converter chip. The RS-232 interface operates between -15V and +15V, on voltage change edge triggers. The MCU's built-in serial UART circuitry operates on the transistor-transistor logic of 5V. Connecting the 15V from RS232 directly into the MCU would damage it. The famous Max232 and its cheaper alternatives are perfect for the task. The chip sits between the 30V (peak to peak) serial IO of the computer (RS-232) and the 5V serial IO of the MCU and converts the levels, bi-directionally.
In order for the MCU to be capable of bi-directional wireless communication with the CA, the robot is equipped with the nRF24L01+ module from Spark Fun which has the regulator, antenna, and oscillator already soldered on to it. The device works on the 'non-standard' four-wire SPI interface (plus one wire for the chip-enable pin) and because the AVR MCU supports SPI interfacing, is very trivial to pair with the device. The chip-select pin, along with the chip-enable pin act as the switches for pushing the chip onto various states; configuration, reading, writing and power modes. The 3-wire SPI interface is then used to either send commands or send and receive data.
The chip is initialized by setting the CE to low and CSN to high, which
causes it to enter the standby state. In this state, configuration changes are
made. First set the local receiver "address" which can be between 3 and 5 bytes
long. To achieve high uniqueness in the addressing to prevent cross-talk, the
addressing in this pro
ject
is standardized to 5 bytes wide. Keeping the CE low, the CSN is switched high
causing the edge trigger on the chip to send it into REGISTER write mode
(specifying the mapped address of '0x0A', the 'RX_ADDR_P0' register), quickly followed by the transmission
of the 5-byte receiver address and then switching the CSN back high to signal
the end of register manipulation. This combination of instruction basically
tells the chip to set it's new receiving address (the address to which packets
can be sent). This custom stack protocol is useful as it allows many devices
listening on the same frequency to ignore packets not destined for themselves,
rather than waste time listening to data, reconstructing structure, performing
integrity checks and then find out the instruction was not intended for that
unit. Likewise, the destination address (the CA for
the robots) is set exactly in the same manners, but the memory address of the
register is '0x10', 'TX_ADDR'. The radio channel and payload sizes are defined next by
setting the RF_CH and RX_PW_P0 registered respectively in the same fashion as
defining the addresses previously. Once this configuration is complete, the next
stage is to boot the chip into receiving mode, that is also done by setting the
PWR_UP, EN_CRC (to enforce CRC packet integrity and to have the auto-retransmitter
send the data again in case of corruption), CRCO (the CRC scheme selection for
this project is one byte wide) and PRIM_RX bits in the CONFIG register. At this
point the Chip Enable (CE) is pushed high to begin operations.
The nRF24L01+ also provides an IRQ line which becomes low when the chip has received a packet and the payload is ready to be read. However there are so many procedures that need to run on time inside the loop that hooking it up to the AVR's external IRQ would constantly delay the logic every time a message is in queue. As such, the system loop inside the MCU polls the RF chip to see if a message is waiting. To do this, the chip-select pin (CSN) is pulled low and the NOP command (0xFF) is sent to the chip via SPI. This causes the chip to return its STATUS register. If the RX_DR bit is set in the returned STATUS register, then a messaged is queued and waiting to be read. CSN pin is pushed back high to return the chip back to stand-by mode. If RX_DR bit is set, the data can be 'downloaded' into the MCU from the chip through SPI by first setting the CSN to low and then sending the SPI command of R_RX_PAYLOAD followed by 'reading' the payload from the chip via a SPI transfer. The CSN pin is pushed back high and the RX_DR bit in the STATUS register is cleared at which point the chip is set to receive new messages.
To send messages the commands are similar as it involves first setting the CE low and clearing the PRIM_RX bit in the CONFIG register to stop the receiver and start the transmitter. First the transmitter buffer needs to be cleared in case some data was waiting in the buffer; pulling CSN low, writing the FLUSH_TX command to the chip and then pulling the CSN back high causes the chip to flush the buffer. Then the data can be transmitter -- pulling the CSN low again and after writing the W_TX_PAYLOAD command, sending the payload itself. At this point CSN is pushed back hi and so it CE.
In order to ensure circuit integrity and guard against any wire coming loose,
a printed circuit board needed to be created. The traces were designed in the
industry acknowledged Eagle CAD software. The paths were created using the
schema designer, and the PCB board designer auto-routed the paths (traces),
creating the double sided board. The board house used for this project offers
free drill set for all the common hole sizes -- 10 standard holes that are
provided for free. To take advantage of this discount, all the pad sizes of
every component needed to be manually adjusted to qualify for the free drill
set.
View: Schema -- Board;
Top, Bottom,
Layout,
PCB.
Once the PCBs have had the components soldered on to them, the next task is to assemble the entire robot unit. The chassis is already cut out from a sheet of acrylic, wheel wells bored, motors placed. The next stage is to construct the line following module and place under the chassis [image]. The "walls" of the robot are then cut and drilled to accommodate the sensors and emitters [image1, image2]. They are then screwed on to the chassis. PCB is placed onto the chassis on standoffs and the wires leading to the sensors are paired with the appropriate PCB port. Once battery is installed the robot is ready to roam [image]. The top plate then sits on top of the walls and encloses the robot.
There are numerous concerns that have either arisen after the final body construction or an issue that goes back to the first prototype. Once such issue is the switching of fluorescent lamps; the switching frequencies or their harmonics interfere with the IR TSOP packages, causing false reading when operating under certain types of tube lights. This issue was found in the first prototype but was never addressed due to no tangible fix.
Another concern is the aesthetics of the robot -- the pieces cut out from acrylic with a hand held jigsaw requires immense strength, precision and patience. The blade either becomes hot and the cutting area becomes very thick as the acrylic melts rather than 'saw' and as it melts it melts material around that spot. Due to the accumulating errors and faults, the walls of the robots are of varying dimension, when in fact they should all be the same dimension. This creates gap between the wall joins and is not as visually appealing.
