Subject:
|
Re: Help me convert this train program to use events (NQC)
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Mon, 28 Nov 2005 14:44:21 GMT
|
Viewed:
|
6261 times
|
| |
|
|
In lugnet.robotics, Jordan Bradford wrote:
| |
the original version works as a prototype, but I don’t have
enough cords to reach the touch sensors I would have put at
each “station” in the full layout.
|
Speaker wire and small alligator clips will make a dandy solution for extending
the basic wires - after all, you really only need one very long wire here (to
the “remote station”), and yoiu have a working set-up.
| |
So now I’m going to power the train motor directly from an RCX
that rides along as one of the cars.
|
Have you built and tested this yet? “Hiding” an RCX on a 6-wide isn’t very easy
(it can be done, it’s just not easy). A bigger problem is the power issue - the
RCX will not be able to run the train for long (the batteries will run down
fairly rapidly, and the weight of the RCX isn’t going to help), and the speed
will change over time. Worse yet, when the power runs low the RCX is likely to
corrupt the firmware unless you put in code to monitor the battery level
(something I’d suggest if you go this route).
| |
I’ll use light sensors on each end of the train to
look for white tiles placed between the track rails
at each “station.”
|
That should work, within the constraints above. As another poster mentioned, you
might need periodic recalibration. Not a big problem, just run a calibration
task every few minutes when you *know* the train is not i na station (like a few
seconds after it pulls out of one). Note that for events, you will need to
redefine the upper or lower limits to recalibrate.
| |
Here’s a new version of main()... Is this going to work?
|
Not yet. For one thing, the sum of two sensors is not a legal source for an
event - a single sensors is. More to the point, if the (single) light sensor is
looking down from the moving train, why do you need two sensors? You’re just
looking for changes in the state of a single light sensor, right? Also, if you
are looking for a event to transition to a “high” state, that implies brighter
the way you’ve defined your sensors. So you need bright tiles under the track -
reflective tape works really well in some of these setups. As mentioned, I would
have the code autocalibrate. The task main() will execute the monitor command
only once - once it falls out of the monitor command, it will execute the catch
code (if the event was tripped), and then fall out of main(), end of program.
Within the monitor() body itself, a single “Wait(32767)” will work - yes, it
will hang there, but it will be immediately pulled out if the event triggers, so
it doesn’t get “stuck in a Wait()”. Those are issue I see immediately.
--
Brian Davis
|
|
Message has 2 Replies:
Message is in Reply To:
16 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
|
|
|
|
