Subject:
|
Re: Gp2D12 Distance Sensor interface to RCX
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 19 Oct 2001 18:58:40 GMT
|
Original-From:
|
Stephen Edwards <edwards@cs.vt./AvoidSpam/edu>
|
Reply-To:
|
edwards@csSTOPSPAMMERS.vt.edu
|
Viewed:
|
673 times
|
| |
|
|
Steven Nickle wrote:
>
> Usage would go like this:
>
> 7 Global variables, a thread checks them on a continous loop and reacts.
>
> Some other thread populates them from the actual sensors. (This should be a
> cpu efficient as possible.)
Sounds like you have a fairly good idea of how you want to use
it, and it all makes sense.
The hardware can be simplified quite a bit if this is the typical
usage pattern, though.
> One solution would be to have the board store the values of each sensor, and
> keep cycling through the sensors. The the RCX just has to ask fo rthe
> information it wants. However, storing analog input would present some
> interesting challenges:-)
Since the RCX is already storing the values for use by the "main" task(s),
and it is already polling the board to update these values, it is much
easier to keep these tasks in the RCX and not in this "smart sensor"
module.
Instead, one can use a module that supports 7 (say) GP2D12's. Only
one is active at any given time. The module has a built-in counter,
triggered from the RCX by toggling the sensor port from passive->active->passive
or something, as well as an analog multiplexer to route the selected
sensor's signal back to the RCX. It would also be nice to only apply
power to the selected sensor, as well.
Now the RCX "sensor monitoring" task simply has to run a loop that
toggles the sensor port to advance to the next GP2D12, sleep for
50ms, read and store the sensor port value, then repeat.
All sensor values (stored in variables on the RCX) could be accessed
at any time by the remainder of the program, and each individual value
would be updated just under 3x each second.
Hardware for this does not seem terribly difficult when the problems
of cycling/remembering are pushed off to the RCX. If external power
were used for the module, it would also be easy to allow jumper-selectable
continuous duty/vs. one-at-a-time power to all 7 GP2D12's. This would
support faster update cycles (by changing the timing of the monitoring
task in the RCX) at the cost of more power consumption.
-- Steve
--
Stephen Edwards 604 McBryde Hall Dept. of Computer Science
e-mail : edwards@cs.vt.edu U.S. mail: Virginia Tech (VPI&SU)
office phone: (540)-231-5723 Blacksburg, VA 24061-0106
-------------------------------------------------------------------------------
|
|
Message has 1 Reply:
 | | Re: Gp2D12 Distance Sensor interface to RCX
|
| about 3 times a second is fine, for most applications. A continous power option would be handy sometimes. If I remember right the 50ms, is the charge time required for the cap to get to power to activate the gp2d12, not for it to actually startup (...) (23 years ago, 19-Oct-01, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Gp2D12 Distance Sensor interface to RCX
|
| They don't need to be all active, just appear that way. I am assuming a dip switch to permanantly deactivate unused, ports. Software control of connected ones would be nice. Usage would go like this: 7 Global variables, a thread checks them on a (...) (23 years ago, 19-Oct-01, to lugnet.robotics)
|
10 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
|
|
|
|
|
|
