This was posted to a standard Majordomo mailing list I just set up:
``mowbot nospam at dragon.swansea.linux.org.uk'', the name suggested by
Byron A Jeff <byron nospam at gemini.cc.gatech.edu>. The list is open to all;
initially the membership is everyone named in the most recent post
by Raymond Skarratt <skar9500 nospam at mach1.wlu.ca>. All the usual archive
and digest features should be available for those who want them.
I'm sorry it took a while to get the list going. As a result,
some of the early posts haven't been archived, and some of my comments
below should really be edited to take account of things said in those
earlier posts. But this message has got so long already, I'm just going
to send it as it stands.
Incidentally, we're not the first with the name ``mowbot'', see:
http://www.cs.uidaho.edu/~frincke/classes/cs470handouts/projects.html
for the only other use of the word I can find on the Web.
To help structure the discussions, let me try to cut the problem up in
to smaller pieces. In the early stages, we have to consider aspects
from lots of categories at once, but as things settle down, I hope we
will be able to fragment the discussions in to several threads which
each concentrate exclusively on one particular issue.
There are five subsystems which need to be part of any robot design:
intelligence
movement
sensors
effectors
power
These are somewhat independent of each other, although of course, some
design decisions in one area will place certain requirements on another.
The effectiveness of the design needs to be assessed with respect to
several criteria:
safety
security
reliability
efficiency
cost
Unfortunately, improvements in the first four usually lead to increased
cost. While I don't anticipate going in to mass-production, so cost
isn't as vitally critical as it would be in a commercial venture, I do
foresee having things get stuck, damaged, and redesigned and I don't have
an unlimited budget to devote to this project. Cost will therefore rule
out some of the more ambitious ideas for me.
Anyway, in an attempt to get the ball rolling, here are my comments on
the design of each of the above subsystems.
Intelligence
------------
I would want the robot to be as autonomous as possible, requiring human
assistance only when it gets in to some exceptional situation.
The robot needs to cover an area, possibly an area with holes. To make an
attempt at guaranteeing timely coverage of all parts, it needs some sort
of map. But given the nature of the environment and the likely appearance
and disappearance of temporary obstacles it isn't really practical (or
desirable) to give it an idea of its world fixed in advance. The map
is more for keeping track of places that have been visited recently than
to enable sophisticated route-finding strategies to be developed.
A microcontroller with a dozen or so input/output ports and a few K of
RAM should be adequate for the task. Because of my past experience
with them, I suggest a member of the 68HC11 family. This family has
the advantage of having lots of good, free development tools and
a simple download/debug feature that can connect almost directly to
a PC serial port. Many useful variants come in DIP packages so it
is possible to prototype on breadboard and construct on strip-board.
Although I have access to PCB production facilities, in the early stages
(and maybe in the later stages too) it would be an advantage to require
no more specialised equipment than a soldering iron.
There are already some fairly general-purpose HC11 robot controller
designs about (including some of my own) which could be adopted with
little or no modification. Even with the inflated prices for HC11s
we are experiencing at present (14 UKP ($21) for an A1), even quite
ambitious designs with a full complement of 50 ports and 64K memory come
to less than 65 UKP ($100). And we aren't likely to need anything like
that sophistication.
Movement
--------
The principle of safety influences design here. Putting powerful motors
on robots which are not in a restricted environment or under direct
supervision leads to potentially dangerous situations. A much safer
approach is to use low power and be resigned to the job taking longer.
I envisage a small device trundling about at a few centimetres per
second on a 12V battery for whole days (and/or nights) at a time.
Suitable motors needed to drive such a robot are easily obtained from
model shops or catalogues for only a few pounds, and because they are
typically designed to be easily incorporated in models, they pose fewer
mechanical difficulties in their mounting, control and use than their
industrial counterparts.
The drive mechanism also depends on the geometry of the robot. An elegant
and common design which largely avoids the problems of getting stuck
in small spaces places two independent reversible drive wheels on an
axis passing through the centre of a circular machine. Such a robot
can proceed forwards or backwards, or rotate about its own centre.
Its circular perimeter makes it unlikely to get snagged or wedged.
Some experimentation will be necessary to determine the torque needed to
move the anticipated machinery at the desired speed over potentially
rough ground. Large wheels or even tracks may be required to give
sufficient grip and resistance to potholes, but these solutions increase
the torque required.
Sensors
-------
The robot needs to learn quite a lot about its world:
whether it is in danger of hitting something
whether it is in danger of falling off something
where the boundary of its cutting area lies
where it is
whether the grass needs cutting
if it has enough charge in its battery
To protect the robot and its surroundings, some anti-collision and
precipice detectors are needed. In previous designs for use in nice
clean indoor situations I have successfully used reflected-infra-red
proximity detectors, but in the real world, even though the modulated
infra-red sensors I used are almost completely immune to sunlight,
I suspect that the lack of smooth surfaces will significantly reduce
their utility. Cheap ultrasonic transducers might give some long-range
data useful for mapping or position location, but as they are useless for
distances much less than 50cm they can't be used directly for navigation
around fixed obstacles. The fancy Polaroid ones work down to shorter
distances and are less prone to false echos, but they are expensive,
fragile, and need complicated drive electronics. Good old-fashioned
touch bars all around would have to provide the final line of defence.
The robot needs to be careful about slopes. Driving obliquely over a
raised obstacle carries the potential danger of lifting one drive wheel
(or track) off the ground. Similarly, driving up the sort of slope
that surrounds a tree, or down one which leads to a steep bank should
be avoided by means of tilt sensors.
Since the robot would have to be protected from falling off a step, the
same sensors used for ground detection would double up as a convenient
way to sense tamper or theft. All the ground disappearing at once should
trigger a shutdown of all moving parts and could additionally invoke
various levels of alarm appropriate to the owner's degree of paranoia.
Defining the boundary is tricky. I would like to avoid having to
programme knowledge about the world in at the start, because that is a
chore and there is the potential for making a mistake. The collision and
edge detectors will ensure that the robot can be contained in many areas
(such as my own back garden) without any further provision, but inevitably
some areas are more complicated and need additional sense information.
Perhaps an ultrasound transducer could tell the difference between grass
and asphalt or paving; although by itself this information might not be
sufficient since most of us have paths the robot should be free to cross.
I'm not keen on the underground wire perimeter technique because it
doesn't fail safely, but I can see that having such a facility would be
useful in cases where the boundary of the robot's activity is defined in
some arbitrary way, or in circumstances where the boundary is something
that other sensors can't detect reliably. It has the advantages of
needing no advance set-up on th robot and being cheap and reliable
provided its power is reliable, so it probably has a place in the
design, if only as an option. But I would really like to come up with
a passive delimiter: how about a simple painted line? If the delimiter
needs to be invisible, maybe some variation on the tuned coil stickers
they use by the doorways of shops would work.
An interesting flip side would be to use one of the above delimiters
not as a perimeter fence but as a pathway. Suppose we permit the robot
only to travel autonomously over grass, but also allow it to cross other
surfaces as long as it was following a trail. That way we can form
bridges between areas of grass which need no extra boundary definitions.
As mentioned earlier, the robot doesn't really need to know where it is,
just how to get somewhere it hasn't been for a while. Assuming that it it
possible to design a grass length sensor (I envisage some sort of optical
beam in front of the cutter---which could also be an extra safety cutout),
it may be possible to make do with a simple random search pattern which
just slows down when there is grass to cut and strikes off quickly in
new directions when there isn't. I do suspect that a little bit more
intelligence might be required to help give adequate coverage of areas
sheltered behind obstacles like trees.
The robot should be able to maintain reasonably good positional information
simply from tachometers on its motors, although movement over rough ground
will inevitably degrade the accuracy of this information. A long-range
sensor which can pick out features in the environment would be a big help
in maintaining more accurate absolute position, but at much extra cost.
The added complexity of the sensor and the programming to interpret
the data seems likely to outweigh the limited benefit of getting a good
position fix. Beacons might be an alternative; either active infra-red
emitters or passive corner reflectors could be spotted on a simple
rotating scan and used to check on position. But I suspect that dead
reckoning coupled with boundary detection will be adequate.
Battery sensing: I talk about battery power in another section. Adding a
charge detection circuit is simple for lead-acid batteries, and only a
little harder for nickel cadmium and nickel metal-hydrides which have
a much flatter charge/discharge characteristic.
Effectors
---------
The robot has one primary effector: its grass cutter. I am strongly
opposed to a using powerful rotating blade or high-speed cord such as
one might find in human-operated mowers primarily on safety grounds.
Instead, I would prefer a low-power, low-capacity cutter something like
the beard trimmer one might find on some electric shavers. This would
be incapable of cutting anything with a diameter more than a millimetre
or two, and certainly proof against the ingress of fingers. If the
robot should manage to stray in to the flower beds, such a limited
cutting facility should prevent catastrophic damage. Also implied by
the limited cutting ability is the assumption that the grass to be cut
will not be allowed to get too long and tough, which fits in well with
my other assumption that the robot will operate almost continuously
over the growing season. Small, frequent cuts will mean that the fine
trimmings do not need to be collected, thus eliminating a large set of
potential mechanical and logistical problems.
The possibility also exists to add extra features, such as the dispersal
of seed, fertilizer, or weed-killer in a systematic way. These tasks are
free from safety worries (although the latter may pose different safety
concerns) and just need some specialist dispenser. I do not envisage that
the initial design will give many concessions to this sort of expansion,
except perhaps to arrange some power and spare I/O lines to be brought
out on a convenient internal connector.
Power
-----
I would dismiss having an umbilical power cord as too prone to
entanglement, so the robot will have to have some on-board power
storage and a re-charging mechanism. Ideally it should be independently
self-powered by sunlight, but enough high-efficiency solar cells to
enable continuous running in indirect sunlight would be expensive ($100
at least). Perhaps solar cells could provide a useful top-up to the
battery, but the primary recharger must be coupled to the mains supply.
Running current is likely to be a few tenths of an amp, so a battery with
a capacity of a few ampere-hours will be sufficient for several hours'
operation. Sealed lead-acid batteries are an easy and cheap way to get
plenty of capacity, but they don't react well to temperature change and
have maintenance problems beyond a few hundred charge/discharge cycles.
Nickel cadmium cells are also fussy about charging regimes, and are
comparatively low capacity: 17 UKP buys you 3Ah at 12V from a lead-acid
battery, but the same capacity would cost 44 UKP in NiCd. Nickel
metal-hydride cells are better all round, being happy with haphazard
and repeated charging, but cost even more (67 UKP in this example).
I am rather taken with the idea of the robot abandoning its mowing when
it notices its batteries are running down and going off to look for a
recharging point, which it could find using an infra-red beacon.
It's still early days, and it is difficult to predict where discussions
will lead. However, I should hope that in the next few weeks we can
decide on the fundamentals, do some research on parts and suppliers and
get busy with some prototype subsystems. Since we seem quite widely
spread over the world, it may not be practical to source components from
just one supplier; on the other hand, bulk purchase prices might make
it economic to pay shipping and import charges. That certainly
used to be true of HC11s, for example. We'll just have to see how
things work out.
Robin.
-- R.M.O'Leary <robin nospam at acm.org> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.