> The mowbot will have plenty of time to do the work.
> (As long as the cycle time is less than the growing
> time; 1-2 weeks for a 'typical' yard).
See earlier back-of-envelope calculations. With my values I get
time = c/g = 0.01/1E-6 = 10000s = 2.8 hours
Oops. That's absurdly short. So either I've been too pessimistic about
c or I overestimated the growth rate. Almost certainly the latter.
But either way it's good because anything that makes c/g bigger makes
mowbot's job easier.
> "Get it working first; THEN optimize it".
> It's easy to do a lot of talking; especially on the Internet.
> ... Get SOMETHING working (moving whatever) first and add
> advanced concepts (advanced algorithms, advanced sensors etc.)
> later.
This strategy gives quick results, but not the best results. A few hours
spent planning can save many hours of frustration and reworking later.
Given the loose group organisation we have here, there is nothing to stop
anyone from building a prototype at once, and indeed, sooner or later
someone is going to have to do just that. However, if done prematurely,
they run the risk of having their design and what they learn from it
obsoleted by a better idea.
> That's one reason I like the 'Gameboy for brains' concept;
> Emulators are freely available (Linux and Windows) for
> anyone who want to help/experiment with software. And
> the hardware is also cheap and easily available (and mostly
> assembled) vs. starting with 68HC11 or something.
How many I/O lines does it have? Analogue ports? PWM outputs?
I bet that all of these things will need to be added. They
are already built-in to the <insert favourite microcontroller>.
> -Monta "who doesn't want to mow his grass next summer" Elkins
This is a natural deadline! I don't know if we'll manage to
do it in time for the antipodean summer though (sorry Dave:-)
Robin.
-- R.M.O'Leary <robin nospam at acm.org> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.