[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
To turn or not to turn
As I was dutifully copying down our scribblings after you left, it
occurred to me that our robot does NOT have to turn. It has to change
direction, yes. But turn? No.
This fact is particularly true since our robot is going to be circular.
For a circle, all directions are equivalent due to symmetry. To say one
is going L or R is equivalent. So suppose our robot is going N and it
hits an obstacle. It does not have to turn to go away from it; it can
just go away from it. I hope I am making sense. To say that we have to
turn implies that there is a front side to this robot, which may not be
necessary if our robot is perfectly symmetrical (in terms of shape and
sensor positioning). I wonder whether this system will make the coding
easier or harder.
Just in case I am not making myself clear, I am going to attempt to make
some ASCII art to explain... (don't laugh Tim)
So our dear robot is going merrily along, only to hit an obstacle.
XXXXXXXXXXXXXX - Obstacle
| -original path of robot
To change direction
The Turning Way - the robot pivots around a wheel and turns around
The Non-turning Way - the robot just goes in a new direction, no need to
| \ New path
Thinking superficially here --
Advantages to the Non-turning way:
-may be easier to build and control
-agility/maneuverability may be compromised
-depends on how "smooth" the motion to be
-but I suppose we can set the wheels to be angled at
whatever angle we want (analog to digital issue)
-harder to determine its own position?
-harder to sort data to make an annotated map?
Whether or not we want to implement this is our choice. But contrary to
previous assumptions, Malone was not screwing with our heads.
On another note, I think we should all think about our own subsystem in
detail and ponder over what each of us will have to do/need to know, and
we should also jot down any ideas that may be useful to another subsystem.