To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.nqcOpen lugnet.robotics.rcx.nqc in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / NQC / 1833
1832  |  1834
Subject: 
Re: Help me convert this train program to use events (NQC)
Newsgroups: 
lugnet.robotics.rcx.nqc
Date: 
Mon, 28 Nov 2005 17:39:46 GMT
Viewed: 
5984 times
  
In lugnet.robotics.rcx.nqc, Brian Davis wrote:
   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.

I wanted the layout to be pure LEGO, but if I run out of time building this I’ll break down and use non-LEGO wire and my original setup.

  
   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 wasn’t worried about hiding the RCX, but I have seen the batteries run down very quickly. In the course of testing just the RCX on a motor I had to adjust the SetPower() function call a couple times because of this. NQC reports the battery level after every upload, and it was down to 8.5V pretty quickly.

I didn’t know that low voltage will corrupt the firmware. That’s good to know for future reference.

  
   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?

That’s a good point. I guess I was thinking of putting the “stations” at the extreme ends of the track, but one of them could be more inward based on the length of the train. As long as the cars don’t run off the end it’s fine. The same would be true of touch sensors -- I’d only need one if it’s mounted on the train.

As for the event setup, thanks for the tip. Most every convenience function in NQC allows combinations of inputs/outputs. But as you pointed out, I only need one sensor, anyway.

   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.

I was wondering about that monitor block and whether it would only execute once. Should I put the monitor block inside a while(true) ?

Thanks for the information.



Message has 1 Reply:
  Re: Help me convert this train program to use events (NQC)
 
(...) For future, LEGO's educational division does sell 3m LEGO wires. (...) A 1.0 RCX that allows you to power the setup from an outlet is ideal for this. If it ends up being battery-based, you will have to adjust the power level as the batteries (...) (19 years ago, 28-Nov-05, to lugnet.robotics.rcx.nqc)

Message is in Reply To:
  Re: Help me convert this train program to use events (NQC)
 
(...) 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. (...) Have you built and (...) (19 years ago, 28-Nov-05, to lugnet.robotics.rcx.nqc, FTX)

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
    

Custom Search

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