 | | Re: train precision
|
|
(...) Daniel, One problem you'll run into with most software is that it switches between power and float to adjust the motor levels. It works much better to switch between power and brake. Using most software, the train will continue to speed up, (...) (19 years ago, 27-Dec-05, to lugnet.robotics.rcx.legos)
|
| |
| | train precision
|
|
A couple of years ago, i used brickOS. Then, i changed to Lejos... I have a moc where i use the RCX to control a train with a lego train motor. It is difficult to control the train with LejOS, because it only has 8 output levels. Two solve the (...) (19 years ago, 27-Dec-05, to lugnet.robotics.rcx.legos)
|
| |
| | Re: color sensor
|
|
(...) Happy Christmas to you too! ... and yes, I have a bench prototype running using that TAOS chip. As per my previous attempts at a color sensor however, it is proving very difficult to make the sensor range and orientation independent. JB (19 years ago, 25-Dec-05, to lugnet.robotics.rcx)
|
| |
| | color sensor
|
|
hi all, first for all a happy christmas to everybody. I just ran into this nice looking color sensor TCS230, which might be useful for detecting Lego colors. (URL) Mientki (19 years ago, 25-Dec-05, to lugnet.robotics.rcx)
|
| |
| | earlier version of binutils?
|
|
Hi, I have been trying to get brickos to compile on my linux machine. I followed the instructions here: (URL) used binutils version 2.16.1, and gcc version 4.0.2. The cross compile seemed to work. However, when I try to compile brickos, I get the (...) (19 years ago, 22-Dec-05, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Memory question
|
|
(...) So what your saying is I should split my program into more functions not less, so that the local ints are destroyed and available for re-use. That's a great idea, it's the complete opposite of my question but fulfills my goal perfectly :-). (...) (19 years ago, 13-Dec-05, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: Memory question
|
|
(...) Most functions in NQC are in-line functions, so in a sense they probably *are* in main(). One thing I do is place all my initalization code (as much as possible) into inline functions. That way, when the compilier runs through, it can allocate (...) (19 years ago, 13-Dec-05, to lugnet.robotics.rcx.nqc)
|
| |
| | Memory question
|
|
Say I had a program that has a very large block of start-up/calibration code that is run once at the top of the program. Does it make any difference if I keep it in the "Main()" task, or put it in a function? I mean from the point of stack space (...) (19 years ago, 13-Dec-05, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: avoid messaging
|
|
(...) I'd agree that a physical block is the easiest, although there is a software solution. The RCX can not recieve a command while it's transmitting - so if you saturate the transmitter with things to do, it will not be able to "look" for any (...) (19 years ago, 5-Dec-05, to lugnet.robotics.rcx.robolab, lugnet.robotics.rcx.legos)
|
| |
| | RE: avoid messaging
|
|
Yes, I indeed have an attachment which will act like blockage, but not a full one though. Sounds like this is the fastest and easiest to do. I fully understand the opcodes concept, as I myself wrote compile code before. However, these kids age only (...) (19 years ago, 5-Dec-05, to lugnet.robotics.rcx.robolab, lugnet.robotics.rcx.legos)
|
| |
| | Re: avoid messaging
|
|
(...) If you have an event waiting for a message, I doubt it will have much impact on the speed of the rest of the program. However, this will not catch the messages you're looking for. You can't use the "mail" function to receive op-code, such as (...) (19 years ago, 5-Dec-05, to lugnet.robotics.rcx.robolab, lugnet.robotics.rcx.legos)
|
| |
| | avoid messaging
|
|
Hi In order to avoid unwanted interruption, such as remote shutdown, from other RCX during execution time, I wonder if the only thing can be done to safe-guard my RCX will be having an independent task dedicated to receive message (mail). This, of (...) (19 years ago, 5-Dec-05, to lugnet.robotics.rcx.robolab, lugnet.robotics.rcx.legos)
|
| |
| | Re: Bluetooth
|
|
Beware of the fact that the outputs on the RCX output PWM. You will probably want rectification, and need smoothing to get a nice constant voltage (some regulator in the LM series) to power the board. Anyway - it sounds like a really good idea - I (...) (19 years ago, 2-Dec-05, to lugnet.robotics.rcx)
|
| |
| | Re: Bluetooth
|
|
(...) Have a look at (URL) Here you reach much higher baud rates Cheers (19 years ago, 2-Dec-05, to lugnet.robotics.rcx)
|
| |
| | Re: Bluetooth
|
|
(...) Great! I'll look forward to its development....any ideas on what you will use it on first? Chris (19 years ago, 2-Dec-05, to lugnet.robotics.rcx)
|
| |
| | Bluetooth
|
|
I’ve just started a little project of building an interface between a RCX and a Bluetooth. For power supply I’m thinking of using one of the outputs on the RCX and for communication I’ll use the IR port(2400-baud), similar to Mindsensors´s RCX to (...) (19 years ago, 1-Dec-05, to lugnet.robotics.rcx)
|
| |
| | Re: Help me convert this train program to use events (NQC)
|
|
(...) (URL) (...) I bought some alligator clips to use with some 24-guage wire. I'll become impure just this once, but I won't resort to willful LEGO destruction. :) (19 years ago, 1-Dec-05, to lugnet.robotics.rcx.nqc, FTX)
|
| |
| | Re: Help me convert this train program to use events (NQC)
|
|
(...) If it were me, I'd destroy one small LEGO 9v wire. Cut the wire in half, and splice in a long segment of speaker wire. That would look better than a short layout, or the battery-powered train. Steve (19 years ago, 30-Nov-05, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: Help me convert this train program to use events (NQC)
|
|
(...) We called LEGO and the Educational division has been shut down since the day after Thanksgiving for inventory. They won't be able to ship the cables to me in time for the Christmas party I was building this for. Grrrr. Bricklink shows some (...) (19 years ago, 30-Nov-05, to lugnet.robotics.rcx.nqc, FTX)
|
| |
| | using rotation sensor
|
|
Most of you are aware of the speed of the robot often causes parity in distance via the feedback of rotation sensors because of inertia. In our experiment, even with a robot with moderate speed. The parity seems to often occur right at the beginning (...) (19 years ago, 30-Nov-05, to lugnet.robotics.rcx.robolab, lugnet.robotics.rcx.legos)
|
