To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 21509
21508  |  21510
Subject: 
Re: More Speed? Re: Mindstorms 3.0 Wish List
Newsgroups: 
lugnet.robotics
Date: 
Wed, 5 Nov 2003 23:52:54 GMT
Original-From: 
T. Alexander Popiel <popiel@wolfskeep^nospam^.com>
Viewed: 
1060 times
  
In message:  <HnwEDB.z5t@lugnet.com>
             "Chris Phillips" <drvegetable@attbi.com> writes:
In lugnet.robotics, "Rob Limbaugh" <RLimbaugh@greenfieldgroup.com> wrote:

Both methods have their place.  There are pro's and con's to each.

For John's purposes, his approach is quick, easy, and requires very
little programming to use.  That would leave him free to focus on other
programming he's more interested in.  The amount of memory needed to use
that approach would be one of the "cons".

Superficially, that seems true... but it falls apart as soon as you
start dealing with dead-reconing errors.  In practice, recovery from
slew errors is significantly more difficult with a location grid-based
mapping instead of an obstacle-based mapping... simply because you end
up with two dissimilar grids (the one you remember and the one you're
sensing) which need to be rotated and scaled to be brought into
congruence.

The simplest compression method I could think of is simply storing the
coordinates of an obstacle.  But, this now requires additional math and
programming when accessing/updating the information, especially when
there is no longer an obstacle.  In John's method above, he could simply
toggle a bit (assuming each bit represented a square inch).

Being able to simply toggle a bit requires that you know which bit
requires toggling... that is, it requires knowing where you are and
which way you're facing.  Just figuring that out takes more significant
math than dealing with an obstacle list instead of a location grid.

A computer screen is drawn the same way John is drawing his obstacle
map.

A computer screen is drawn with a finely tuned electron beam in a closed
environment where it can be relied upon to trace the same path with every
sweep.  That's not the case with any free-roaming physical robot; without
guide rails or line following or some other sensor feedback, minor
differences in voltage or traction or any number of other variables will
cause the robot to drift off of any planned course.

But the issue that is in danger of being trampled here is that many people
tend to underestimate the capabilities of the RCX that they already have.
More horsepower is not always the answer, and sometimes we learn a lot more
by learning to accept some limitations and work around them than we do by
just throwing more hardware at the problem.

Hear, hear.  Often, working around the limitations shows us that the
workarounds are actually simpler than the originally devised approach.

Steve originally asked what programming problems people had found that
were beyond the capabilities of the present-day RCX hardware, and I was
merely trying to point out that John's problem was not necessarily in
that category.

I also tried building a mapper-bot, with a palm pilot piggybacked on top
to provide the larger memory and faster CPU than the RCX.  I found that
memory and CPU were the least of my worries; finding ways to reconcile
the different maps I got on each sweep (even in an environment where the
robot was the only thing moving around) was a far more difficult problem.

- Alex



Message has 1 Reply:
  Re: More Speed? Re: Mindstorms 3.0 Wish List
 
(...) Ah hah! And the reason I don't want to waste time and effort making my memory map (excuse the pun) any harder to code than it has to be is because I am busy building special sensors and other gizmos to solve the short range navigation and (...) (21 years ago, 6-Nov-03, to lugnet.robotics, FTX)

Message is in Reply To:
  Re: More Speed? Re: Mindstorms 3.0 Wish List
 
(...) Again, there is nothing wrong with wanting more memory and a faster CPU on the RCX. And there is nothing wrong with John using any programming technique he wants to in his robots. And even if the RCX is capable of assigning one bit of memory (...) (21 years ago, 5-Nov-03, to lugnet.robotics)

5 Messages in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    
Active threads in Robotics

 
Contact Recovery Nerd for Speedy USDT / BTC Recovery
16 hours ago
Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR