Re: [mowbot] What happened to "keep it simple"

Dave Everett (Deverett nospam at vir.idx.com.au)
Tue, 15 Oct 1996 10:26:52 +1000

KEN_REED nospam at hp-boise-om2.om.hp.com wrote:
>
> Item Subject: cc:Mail Text
> Greetings fellow roboticists,
>
> Having completed the experiment, design stage, and most of the building
> of my LawnBot, I have followed the Mowbot mailings with great interest.

Hey well don't forget to send me photos and lots of details so I can put
it on the Mowbot website:-)
>
> Concern 1: Some requirements imply great navigation ability.
> It is not trivial to navigate an indoor closed area and know where
> you are, let alone outside. Indoors robots typically use odometry
> and beacons to locate themselves. There are probably less than 25 hobby
> robots in the world that know where they are, and can navigate
> from there. Moving things outside makes odometry a greater
> challenge, if not completely unviable. Beacons should still work.

I have found indoor navigation to be almost trivial. I built a robot out
of an old Hero Jr about 5 years ago, it used a ring of 12 IR pairs,
rough odometry and a fluzgate compass to navigate reliably. I don't like
the idea of beacons and such, it makes things easy for the robot, but
hard for the experimenter. THe trick is to toss away ideas like grid
navigation etc and deal with the world in a way that other creatures do,
by using landmarks.

Landmarking in an outdoor environment is going to be harder because you
lack the walls that form the mainstay of landmarks in a typical Mataric
map. This is why I'm so interested in a grass/concrete type sensor. the
G/C sensor would help in the categorisation of landmarks.

I wanted to leave navigation and landmarking issues till much later,
but, here are some ideas I had.

Landmarks could be based on these sensors:
XY - a very rough positional estimate from the wheel encoders
Compass - this info would be used to rotate sensor information
inclinometer - slope is a natural feature so makes a good landmark
feature
G/C sensor - an obvious boundary feature

It is only neccessary for the robot to landmark a boundary around a
grass area to successfully mow that area.

As you can see I don't intend to rely on beacons (except for one special
situation that I will detail in a moment), beacons are hard work
(installation), and protecting them and ensuring they remain operational
is a headache that might quickly rival the mowing we are trying to avoid
in the first place :-(

It's my contention, that if the Mowbot can't work in an unstructured
world, it is not ready to be unleashed on that world.
>
> I know some of the group are thinking about random movement
> till you find grass then do a flood fill. That sounds pretty neat,
> but flood fill implies navigation, knowing where things are. Flood
> fill is great in CAD or PostScript, but I believe flood fill is
> very ambitious given the sensor input proposed and the very
> limited computing power available. How about searching randomly
> until finding grass and then using a harvey-wall-banger approach
> instead. Mow and always keep the mowed grass on one side. Sort of
> spiraling down to a point. Certainly not a flood fill, but much
> less complex, and not any less efficient with respect to total
> distance traveled or number of turns required.

Actually I believe that is what is meant by flood-fill here. I agree it
is not the best term to descibe the action. BTW, flood fill is a very
simple computation, especially in this case as the cut areas become the
boundary.
>
> Finding a battery charger or cleaning station is non-trivial. My
> own personal indoors robot does it fine almost all of the time, but it
> is not an easy task, especially if the robot does not know where he is
> or where the battery charger is. How about a robot with a battery
> that charges with solar. Run about 2 hours, then charge for 8 to
> 10 hours.

As long as the Mowbot can get somewhere near the charging station (this
is where my one and only beacon comes in) I intend to have a beacon on
the charging station. If the Mowbot is close enough it will be able to
see the beacon (say 5 metres), then it is fairly easy to "home in" on
the beacon. At this stage I intend to use inductive charging, so Mowbot
can sense when it is in inductive contact with the charging station and
could even correct it's position to maximise inductive pickup.
>
> Concern 2: Some requirements imply lots of power available.
> Another thing I'm concerned about is power consumption. I believe
> that the Mowbot proposed so far would discharge its batteries much
> before a lawn is mowed.

This is one area that also greatly concerns me. However, all the
calculations in the worl won't give us a true representation of current
consumption. The only way is to try it.

> Some of you are thinking a 386 on board.

I can't imagine why this would need a 386, in fact I think it would
hinder progress as it would kill off all parallelism in sensor
processing.

> Even portables only run an hour or two on their batteries.

Once again I cannot see any value in a 386 (or similar), the processing
is best achieved with cheap (low-current) microcontrollers. The only
place I can see more computation neccessary is to store the landmarks.

> Summary:
> I'd recommend keeping the first robot as simple as possible. I know
> everyone says this, but then goes merrily along, thinking of pooper
> scoopers, or leaves pickup, crushing pine cones, or guard duty, or
> gas powered, or RF this, and IR that, or calling home, or going across
> the street and mowing the neighbors yard, lawn mower gates, detecting
> the police, and so on......

Functionally I agree. The first robot should merely cut grass. I intend
to have this thing absolutely bristling with sensors rather than
features.

Don't forget those photos Ken ;-)

-- 
Dave Everett                                Email: deverett nospam at idx.com.au
(c) 1996 - Copyright remains with the author unless explicitly stated