[Robotgroup] Drive a Droid proposal... How to detect the "fence"?

[Marvin Niebuhr]

And the "curb" could be 4" PVC and don't go fast and have a RPG ready  
as a failsafe. That would fit with the fire works. Stop over  
engineering the damn thing!  Prof. Conrad

On Jul 8, 2008, at 2:10 PM, Doug Evans wrote:

> Odometry error is generally more pronounced in the theta value (the
> heading), in my experience. However, I agree that it is not the  
> best method
> for the task as described.
>
> If it were my project, I would place some IR detectors at the front  
> of the
> robot (down low) to detect a "curb" which is painted in such a way  
> that it
> reflects the IR signal (as I believe has already been proposed by  
> another
> member). Probably IR Sharp range finders would be more than  
> sufficient. The
> robot controller would employ an obstacle avoidance behavior at a  
> low level,
> preempting the "controlled" movement.
>
> As a fallback, it might be advisable to also employ an ultrasonic  
> sonar
> sensor at a higher vantage point to avoid bumping into anything (or  
> anyone)
> in the ring (or partially in the ring).
>
> As a failsafe, there needs to be a remote kill signal (aside from  
> the remote
> being utilized by the folks) so that an RG person can avoid  
> personal injury
> to spectators. This might be something as simple as a 38khz remote  
> and a
> corresponding sensor.
>
> Sounds like a fun project, whether or not it gets funded by First  
> Night.
> Just the kind of thing that makes the kids grin.
>
> -de
>
>
>
>
> -----Original Message-----
> From: robotgroup-bounces at puremagic.com
> [mailto:robotgroup-bounces at puremagic.com] On Behalf Of Bryan Bishop
> Sent: Tuesday, July 08, 2008 1:07 PM
> To: The Robot Group Mailing List
> Subject: Re: [Robotgroup] Drive a Droid proposal... How to detect the
> "fence"?
>
> On Tuesday 08 July 2008, Clendon Gibson wrote:
>> If you are good with geometry, then you can put encoders on the
>> wheels and calculate your position by dead reckoning.
>
> We discussed this last time the group gathered, and it became apparent
> that the amount of loss and difference due to the wheels turning (and
> so on) is significant to the extent that the encoders will miss
> information from time to time. The buildup would be too much of an
> offset from actual data.
>
> Though I didn't do any calculations to see if it the buildup would be
> significant within the 30 second period that a user would be  
> driving it
> around -- maybe after 30 seconds the buffers could be purged and it
> could return to home (center) position?
>
> It's not a matter of time, but rather the moves that are made with the
> spinning and the going forward and backwards, some generating more
> error than others, so it's possible to have somebody walk up and make
> it do weird things to make it damage the 'barrier' etc. before  
> those 30
> seconds are up.
>
> So, I don't think dead reckoning is going to work.
>
> - Bryan
> ________________________________________
> http://heybryan.org/
> _______________________________________________
> Robotgroup mailing list
> Robotgroup at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup
>
>
> _______________________________________________
> Robotgroup mailing list
> Robotgroup at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup
>