Search the Community

Showing results for tags 'nxt'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Frontpage, Forum Information and General LEGO Discussion
    • New Member Section - PLEASE READ BEFORE STARTING!
    • Frontpage News
    • Forum Information and Help
    • General LEGO Discussion
  • Themes
    • LEGO Licensed
    • LEGO Star Wars
    • LEGO Historic Themes
    • LEGO Action and Adventure Themes
    • LEGO Pirates
    • LEGO Sci-Fi
    • LEGO Town
    • LEGO Train Tech
    • LEGO Technic, Model Team and Scale Modeling
    • LEGO Mindstorms and Robotics
    • LEGO Action Figures
    • Special LEGO Themes
  • Special Interests
    • The Military Section
    • Minifig Customisation Workshop
    • LEGO Digital Designer and other digital tools
    • Brick Flicks & Comics
    • LEGO Mafia and Role-Play Games
    • LEGO Media and Gaming
  • Eurobricks Community
    • Hello! My name is...
    • LEGO Events and User Groups
    • Buy, Sell, Trade and Finds
    • Community
    • Culture & Multimedia

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



What is favorite LEGO theme? (we need this info to prevent spam)

Which LEGO set did you recently purchase or build?



Website URL








Special Tags 1

Special Tags 2

Special Tags 3

Special Tags 4

Special Tags 5

Special Tags 6

Country flag

Found 68 results

  1. welcome to the mindstorm section of the Akiyuki project, this topic is for the modules of Akiyuki that have mindstorms in them or use mindstorms in any way. as always I would appreciate any information (pictures/videos) of these modules working or built here's what I know so far: Ball Cleaner EV3( in progress by @Juroen) program by Akiyuki ( file available instructions coming soon) Container Transporter NXT instructions available here by @Courbet program by @9v system available here Fast Ball Sorter EV3 instructions by Courbet, built by Courbet and Mogwai, program also by Courbet and Mogwai, Render by Blakbird(instructions available) building instructions, program for the ev3 any help would be good to get these modules made into instructions (programs will also need to be made) 9v system
  2. One of my NXT servos is exhibiting some odd behavior. I had to replace a servo for a different reason and this might be the replacement, but I'm not entirely sure as I didn't mark it as such. In any case, I'm curious if anyone else has seen this and knows the cause. With two servos that act as expected, I can place a single Move block in the program and use any of the duration settings and both servos will run and stop when programmed or run continuously if "Unlimited" is selected. However, when one servo is replaced with the misbehaving one, regardless of the duration setting, the latter servo will run continuously and the good servo will twitch as if it's about to run, but stops immediately. I have to end the program to get the "bad" servo to stop. If I place the Move block inside a Loop set to "Forever," the above behavior will be identical except for one scenario. If I set the Move block duration to "Unlimited," both servos will run and can be controlled by the Loop's "Control" setting, i.e. they will either run continuously or run and stop as set by the loop control setting. Simply using individual "Motor" blocks to control the servos does not solve the problem. There are good and bad programming scenarios with those as well with regard to the bad servo. The best guess I can come up with is that the bad servo is either not sending or not receiving a feedback signal, maybe both. I did wonder, though, if these servos have any firmware in them that might behave differently depending on when they were made. This isn't a fatal flaw as I can use the servo, but I am curious what might be going on. Thanks, Paul
  3. I wanted to power static Mindstorm builds at shows/events through wall power instead of rechargable AA batteries. I was going to design my own AA battery adapters then I found these on Thingiverse. They came in STL files that can be 3D printed. You only need to print two per Mindstorm unit. They have a nice opening to feed the wires through. AA Battery Eliminator by movotrab: I had to make a small notch on the battery cover for the wires to come out. From here you connect to a 9V DC wall adapter.
  4. I built a new ride on vehicle for Brick 2015 at London Excel. It was super popular and I am so tired now (3 day event, 20,000 + people) Uses 10 NTX's 22 motors, rotacaster 125mm wheels! Made in 5 evenings powered by RedBull
  5. HiTechnic make third party sensors for NXTs. One of their sensor’s, the gyroscope sensor, can be used to create a LEGO NXT Segway. A video of their model is available Additional details and building instructions are available at Having seen how much enjoyment my children had when playing with this model, I decided to build some for a show being run by my LUG. I endeavour to provide the public an opportunity to interact with my displays, on the premise that it is more interesting for them. While testing the models prior to the show, I identified some minor alterations to HiTechnic’s program which appear to improve the stability of the Segway. The remainder of this post describes some observations about running the model and alterations which were made to the original program. But first, Cutting to the Chase If you’re more interested in running the modified program rather than reading the rest of the post, download this zip file and follow the instructions in the readme.txt file to install the program on your NXT. General Observations 1) Having similar motor speeds helps The robot stability seems to improve if the two NXT motors rotate at close to the same speed. An issue of differing motor speeds is described here and includes some techniques you may wish to try to better identify suitable motor pairs. Alternatively, within the zip file identified above, there is a program named rotation_count. You can install it, connect one motor to the A port and one to the C port and run the program. The program will identify the number of rotations each motor makes in 20 seconds. The closer you can get the numbers to match, the closer the motor speeds should be to being the same and the more stable the robot appears to be. 2) Battery charge level matters I tend to run my NXTs with the rechargeable battery pack. It is noticeable that when the robots have been running for a considerable duration (hours), they become more prone to falling. This is resolved instantly by replacing the rechargeable battery pack with a fully charged battery pack. Program Tweaks I made a couple of tweaks to the program. One was to try to improve the stability and the others to enhance the usability. a) Gradual Speed Change The original program treats the command from the Infrared remote as an instant command. The two lever IR controller has three speed values; -7 (backwards), 0 (neutral) and 7 (forwards). If the Segway is travelling backwards and both levers are pushed forward, the Segway responds by changing the motor direction at full throttle i.e. from -7 to +7. The modified program treats a change in the IR remote lever position as a speed delta change. When the Segway is travelling backwards and both levers are pushed forward, the Segway responds by changing the motor speed and direction in single increments i.e. -7, -6, -5, -4, …, 4, 5, 6, 7. This results in a more gradual acceleration/deceleration for the Segway and less “rocking”. b) Prompt for IR Channel The modified program begins by prompting for which IR channel number you want to control the Segway with. This allows multiple Segways to run concurrently using independent IR remote controls. c) Continue After Falling When the Segway falls, the original program displays a message and then exits once the NXT’s “return” key is pressed. The modified program displays the same message but then loops back to the point where the Segway is stood up. This alteration makes it easier to continue running the program when it is under the control of a member of the public e.g. at a display. Demonstration The following video is split into 3 segments. They illustrate; the impact of having a low battery (segment 1) the benefit of a fully charged battery (segment 2) the behavioural difference between the original program (yellow Segway) and the modified program (white and red Segways). The difference is most noticeable toward the end of the segment. The yellow Segway will start and stop turning before the other two Segways. Similarly, the yellow Segway will begin to move forward and backwards sooner than the red and white Segways, which results in it swinging more. If you have any questions about anything above, please post them here and I will do my best to answer them. Regards, David
  6. Hi, At the recent Lego World 2013 in Copenhagen I displayed my model of Islands Brygge Metro Station including NXT controlled sliding platform doors. This model is the fourth in a line of trains with automatic sliding doors, that I have built over the last years (version 1, version 2, version 3). I have compiled a short video to show all the functionality including some "behind the scenes" footage: The NXT controls the following: Output 1: Running the train on the inner loop (9V) Output 2: Running the opening mechanism for the three sets of platform doors and three stes of train doors Output 3: Running the elevator Light sensor: Stopping the train at the platform (accuracy: 1 stud) Distance sensor: Detecting the lower position of the elevator (dynamically calibrating the elevator cycle) Touch sensor: Detecting the outer position of the opening mechanism (dynamically calibrating the cycle) In addition, there is a 9V metro train running on the outer loop and PF lights on the platform wall and over the platform door. Some images of the station, which was part of a bigger display of Islands Brygge, a central neighborhood in Copenhagen: After moderation, more pictures can be found here. The station is modelled very closely after my local metro station, though I have reduced the number of opening doors to three sets. Here are some reference pictures: I am looking forward to your comments. Esben
  7. weight(only Lego parts): 1300g weight(with cutting board and knife): 2000g lenght: 50s width: 45s height:45s The main function of this device i cutting fruits in squares. For the driving part i used 2 motors, one of this motors move a knife. Second motor is responsible for driving. This machine also have a safety system. When you move hand in front of knife, everything will stop. After cutting, the machine pushes the fruit into the bowl. "Agresive mode" - this is my brother's creative idea... All functions can be seen in my movie. Have a nice watch. :)
  8. Hello everybody. Recently i found a segway program on ntx with extension .rbt. I need to convert it into .ev3.I tried, but it didin't work. Who can help me?
  9. I am getting close to the end of this long term build and it's time to share some pictures and a bit of the story. Even before I had finished putting together 10231, I decided I wanted a Crawler to go with it. Being a Technic fan it had to at least drive around and lift the launch platform and shuttle. Those two basic goals spawned a project that has lasted a little over 2 years so far. Some ideas have stuck around since their inception, others were a bit optimistic (like building a peristaltic pump and hoping I could find a way to control the pneumatics hydraulically). February this year marked the 50th anniversary of when the two crawlers went into service, so recently there has been extra motivation to finish. The base equipment; - 16x M-motors (drive) - 4x L-motors (pneumatic jacking and leveling) - 4x IR Receivers (V1 as the V2s do not like driving multiple m-motors on a single channel) - 4x NXT servo motors (steering) - 4x RCX rotation sensors (measuring jacking level between truck and chassis) - 2x NXT bricks (one master and one slave. The master communicates with the Android Tablet and coordinates itself with the slave. Programmed in LeJOS) - 1x PF IR-Link sensor (link between master NXT and all PF motors) - 2x PF Battery boxes (with thermal overload removed) - 1x Android Tablet Future add-ons - Accelerometer (automatically detect the crawler is on a gradient and adjust the leveling to suit) Bricksafe folder is here: Firstly, a couple of my favorite reference pictures; The build itself started with the trucks, thinking that the pneumatics and LAs would dictate the scale. First proof of concept - build a coupling to give height, pitch, roll and yaw to the truck. The pneumatics need to be on their own gimbals too. The reinforced 2x2 rounds slide and rotate in the 4x4 macaroni's. It is on the limit of what will hold together without glue, but it does hold. The two 1x2 technic bricks at the base of the 2x2 column are helped a little by a string (not pictured) which runs up through the 2x2 rounds with the axle. Initial prototype of the drivetrain. I would have liked a higher ratio but there was just no room at this scale. When the gearbox was married with the truck chassis I had to juggle positions, so you will see in later pics the crown gears are facing in not out Best laid plans.... Marry studded and studless they said. It will be easy they said... Showing what will eventually be the steering between chassis and truck. The guide tube and pneumatic cylinders are all on gimbals with the pneumatics coupled together. The average height is preserved during any tilting. With prototypes sorted, it's time to bricklink some parts and quieten down the colour scheme! (thank you 42030 for providing 5L thin liftarms with axle hole in LBG color) You can see the relationship between "guide tube" and cylinders here. The pneumatic system was overhauled too many times to remember but this is what it arrived at. It is all controlled by the direction of the motor. Running forwards drives the pump. When running backwards, the lobes operate the pneumatic valves in series, letting small amounts of air escape each rotation. This lowers the chassis in a slow and controlled manner. The motor can be turned on or off and run in either direction at any time due to the valve timing. Early attempts with PF Servo and NXT servo just couldn't park the valve reliably and after a few operations I would hear a slow leak. I have been trying to keep up with the LDD but it's hard to stay motivated when I know I'm just going to have to suck it up and move over to LDraw if I want to include all the motors, pneumatics and LAs Works so far; (I'll make the files available if anybody would like them). I found LDD essential in the early days to plan ahead and simply find parts, but later on the build overtook it. Original 'box' pump. 1x PF XL motor, 4x 6L pumps running at 90 deg to each other. Very smooth but bulky. Flatter attempt in the same vein. The truck itself. The final design for the height control modules. I hope you enjoy the build so far. More pictures to come of chassis, steering, leveling and interior details. I'll leave it to others to decide what 'theme' it belongs to .
  10. Dear All, there are numerous contributions on electrifying LEGO train switches, including those here on EB. All-LEGO solutions, all-custom solutions and “everything in between” has been presented. One issue for my layout was: How to control about 30 electrified switch points on a fairly large and rather congested layout with many areas not readily accessible – in a purist solution? Using individual cables going from one single “control center” to the switches would result in some considerable cable mess. Alternatively, PF receivers may serve as remote controllers on “PF layouts” – manipulated via IR light from the center. That is a very elegant solution, however, there are only 4 x 2 IR channels (or 8 x 2 in extended mode with a mandatory custom remote control program), which is not enough on my layout, particularly when running several PF controlled trains eating up channels as well. One approach is a fully LEGO based solution using LEGO programmable bricks (PBricks). With such PBricks one can use a variety of motors on the drives and also some fairly flimsy switch drives because of power and timing control of the drive train. Furthermore, with some software development (e.g., NQC, RobotC, NXC, NXT-G …) the controllers may get their own “address” and operation software. However: Cost may become an issue: You need 1 NXT or 1 RCX for each set of 3 switch drives, or 1 Scout for each pair of 2 drives (in case the drive is operated with one additional MicroScout, the Scout can also operate 3 drives) … More recently, LEGO compatible 3rd party switch drive controllers have become available: The 4DBrix ( varieties are extremely nice! What I find particularly intriguing is the control software. The entire product line from switch drive, controller, to full software integration is the best LEGO compatible solution I became aware of. Nevertheless, here is my all-LEGO “solution”: Brick-built switch drive controllers equipped with PBricks. Please don’t take this post too seriously. It was a lot of fun to build these – plus I like to see stuff moving and making noise (in addition to trains that is) on my layout. Since a video says more than 1000 words, here is the “visual summary” of the rather long write-up following below: And here are some more detailed descriptions ... Working principle The idea of this approach is rather old; in 2007 this article in Railbricks Issue #3, page 44 illustrated some details: The controllers serve more than 3 switch drives with only one PBrick by “mechanical address decoding” – or whatever you want to call it. At that time though I did not think about “simple” motorized switch drives; the ones I used then were all equipped with MicroScouts and were designed to run only with these. That limited the applicability of the controllers on my layout significantly: You need to turn on a MicroScout and put it into “P” mode to let it do what is expected from an electrified switch drive. However many of the switches are hard to get to – hiding behind bookshelves and underneath/within furniture. I have thus added mechanical switch drive controllers for operation with NXT, RCX, and Scout PBricks operating most of the LEGO electrical motors, including PF. So far I have electrified all my switches and bunched them up in “groups” using four such switch drive controllers. What are the controllers supposed to do? They serve as “local remote control hubs” for a group of switch drives. There is essentially only a purely mechanical “bricking” limitation on how many switches can be handled by each controller. The controllers have a dedicated address, for simplicity let’s say address 1, 2, 3; the individual switch drive is hooked up to the respective switch drive controller and has a local “address”, let’s say a, b, c, … The last bit of information required is the switch position, let’s call that “straight (s)” or “turn (t)”. The information sent to all the controllers on the layout is then “controller address + local switch address + switch position”, for example “2, d, t” means that switch “d” operated on controller “2” should go into “turn” position. As shown in these posts here and here, all communication on my layout is via the LEGO IR messaging protocol, mostly transported via RF. Figure 1 shows a “bare” Scout operated switch controller without any decorative stuff; Figure 2 a controller with an additional decorative brick structure remotely matching the Toy Story steam engine coaling station, Figure 3 a controller that is residing within a “building” remotely matching (if at all) the appearance the #10027 train shed – however with a rather “transparent” roof (in fact I got hold of 50+ of transparent #41750 pieces for free and all were left handed … what to do with them?). Figure 4 shows a more or less bare controller I built because I needed to serve 12 switch drives in locations under my desk and further away. All four work on the same principle, but use slightly different mechanical operating techniques. The Scout operated controllers in Picture 1 and 2 use the Scout’s Visible Light Link (VLL) terminal (“Output C”) to connect with MicroScout operated switch drives via an optical fiber link. In my opinion, TLC never really exploited the possibilities of the VLL link. They for example never produced optical fibers longer than about 20 cm, as far as I know. Rather cheap plain vanilla optical fibers (1 m for less than 1 €) are good enough. The controller in picture 3 runs with an RCX PBrick and uses PF switches to operate switch drives equipped with PF or 9V motors. It features a moving stage powered by a PF M motor and a Technic mini motor for actuating the lever throwing the PF switches. The controller in Picture 4 operates an almost identical stage. The stage drive is not mounted on the stage itself; the Scout drives the stage via Technic chain links (#3711) with a stationary #47154 motor and again a Technic mini motor (#43362) for switching. Common to all controllers is the “positioning” mechanism of the moving stage: In case of the optical controllers, VLL light from the Scout output needs to go through the corresponding fiber connecting with the MicroScout operating the switch drive. The fibers are simply pushed through Technic bushes into a Technic brick with holes, in other words they are always nicely lined up. So we just need to get the VLL light from the Scout to the corresponding hole. That is accomplished by either moving the entire Scout PBrick (see controller in Picture 2) or by moving the 20 cm long LEGO optical “fibers” (BrickLink ID x400c20). These are more or less plastic tubes that came with the ExoForce sets – finally I found a way to use them …) connected to the VLL terminal to the target hole, see picture 1. The Scout has a built-in light sensor; that one is used to detect when the VLL output diode is in line with a hole or somewhere in between by measuring the light intensity emitted from a LEGO light brick (9V or PF): When the light from that brick goes through a hole, the detector sees it “brightly”, when it is more or less blocked, it only sees a fraction of the “bright” light. When the “hole detection” mechanism is lined up with the fibers, we are done; this is readily the case when stacking Technic bricks with holes. Basically the same approach is used for the RCX controllers; here we need to get in line with the PF switch levers. When lining up PF switches directly next to each other, the levers are 3 holes apart, and we can use a simple optical positioning mechanism again to get to the right switch. The actuator of the moving stage for throwing the PF switches (see Figure 3 + 4 and video) is partly shown in Figure 6. Since the PF switch has three positions (“forward”, “0”, “reverse”) and the switch drive motor is turned on only for less than a second, the PF switch needs to be swiftly turned back to the “0” position. That is tough to do with powering the actuator motor accordingly. Furthermore, the lever needs to be straight up after switching, as the stage/actuator needs to freely pass the switches when moving to a new target. I have used the fairly tight 6.5L shock absorbers (#73129) to push the actuator back into “0” position after the switch was thrown. As mentioned, the switch is thrown with full torque of the Technic mini motor (PBrick output “full forward/reverse”) as the actuator has also always to push against one of the two springs of the shock absorbers. The output of the PBrick is then put into “float” rather than “stop” mode, so that the motor axle turns freely and the compressed spring of the absorber pushes both the PF switch lever as well as the actuator into “0” position. Programming the PBricks The programs running on the PBricks are rather straight forward. NXT, RCX, and Scout PBricks are all capable of multitasking. In my programs, one task is handling incoming messages. The moment an address is recognized by a PBrick as “my ID”, it listens very carefully for the next message(s) to come in; that one contains local switch address and desired position. The routine puts that message onto a stack, sends a “got that” reply and continues to listen for further messages to arrive. A second task watches the stack: Nothing here, nothing to do. Once there are messages on the stack it fetches one, analyzes it and drives the positioning mechanisms to the appropriate output, sends out either VLL light or briefly operates the PF switch by changing the driving Technic mini motor from “float” (off) to “forward” (or “reverse”) and then back to float. After completion it throws the message away and continues with the next one on the stack. How does each controller know, where the moving stage actually is? Upon startup, the stage is driven all the way to the right, until it reaches the “right limit” touch sensor. Then the light brick is turned on and the trolley moves all the way back to the “left limit” touch sensor. On this journey, the light sensor continuously monitors the light intensity. The brightest light value detected is then considered a “hole”; everything else “in between”. Then the trolley moves back all the way to the right touch sensor and on its way, holes are counted and each switch is thrown to get all switches into the “straight” position. Now we know how many switch points are present, we know they are all set to straight, and we know that we are at position “0”. Upon getting a message, let’s say “turn switch 5” it starts to move left and simply counts up holes. Once it arrives at “5” it stops and is automatically aligned with either a corresponding hole for the VLL output of the Scout or the lever of a PF switch. Then it either sends out the VLL forward/reverse command (Scout) for a given amount of time or it throws the PF switch (RCX/NXT), again for a given amount of time. The switch drive motors are turned on within a “hundreds of millisecond” time frame. This time is adjusted to the requirements of the switch drive. That is basically it. The VB6 program (I am old …) running on my laptop is showing my layout with all the track including switches. Basically the program is one database with some graphics and in/output around. Clicking on one of the switch symbols makes the corresponding real switch change its direction. The program searches the database and finds out which controller is assigned to this switch. Furthermore it finds out to which local output (a, b, c …) that switch is connected on the selected controller. Since the program knows the current status of the switch on the layout it composes a message as described above: Controller address + local switch address + new position and sends that out via the IR tower into RF space. There is a little more to it. To ensure rather secure communication between host computer and remote controller, there is a handshake protocol: The controllers acknowledge messages they understood. If there is no reply, the host control program repeatedly sends out the same messages. If there is still no answer for let’s say five consecutive attempts, a warning message tells that something is wrong. The controllers also have some safety routines – should the stage go beyond the end points it stops operating and sends an SOS message, and do on. Seeing this happen is real fun! However the SOS thing hardly happens at all … Another thing to notice is that MicroScouts go to “sleep mode” when not doing anything for about 10 minutes. So every 9 minutes or so, the stage is driven all the way to the left, then right, recalibrates the light sensor, and then back left, stopping at every hole and let each MicroScout play some sound. So they never fall asleep … and there is even more action on the layout. One thing I am somewhat proud of is that all that functionality is possible with 396 LEGO byte codes on the Scout controllers. The RCX PBricks have monstrous 8 kByte of storage space – I believe you could use an RCX to successfully fly to the moon, land there, play soccer, and safely return. These TLC folks are ingenious. And if you don’t want to run a clumsy computer based control program – learning remotes work also very well for easily controlling more than 30 switch drives. This was already discussed in this post. The number keys “1” through “9” correspond to switch drives 1 to 9. I first press one color key (ID), addressing a particular controller and then swiftly a number key. The controller that recognizes the address operates the corresponding switch drive and puts the switch to the “branch” position. Upon pressing the address and then number key twice, it goes to “straight” … Some files The LDraw mpd files for three controller types (Fig 1 – 3) are here along with the NQC programs here running on the PBricks. The controller in Fig. 4 is in the works). Please see readme files in the directories. Note that you need to have the official and unofficial LDraw parts libraries installed. When opening the LDraw files with MLCad, the program tells you that newer versions of some parts are available. Ignore that, otherwise the model may be corrupted. All LDraw files open correctly with LDView 4.2 and MLCad 3.5 Best regards, Thorsten
  11. Dear All, since 2001 I am working on this: LEGO train layout control from one single computer (trains, switch points, light, bridges, …) using as much as possible original LEGO hard- and software. Still WIP but getting close. Most of the LEGO stuff used here is – since long – not officially available anymore. But LEGO is LEGO and lasts forever … and now I am close to getting it all to work. This project has survived Win98, QBASIC, WinXP, VB6 (well not true, still using it, see below …). And as sPy pointed out correctly in his reply on my PF RF hack, all this is building on stone-old electronics hardware. But: All this stuff is still available today. BrickLink is very close to LEGO heaven, I believe. And because nobody really cares anymore about RCX’ or MicroScouts – they have become dead cheap. I recently ordered RCX’ 1.0 with power jack for less than $20 each. These are the best PBricks ever made by TLC … imho, of course. There are many powerful and elegant solutions for controlling PF operated trains as well as track/track side-related functions such as remote switch operation, lighting, train detection, and much more. Most of these are based on home-built (as for example the myriads of wonderful Arduino-based solutions) or third party commercial devices, e.g. SBrick, 4DBrix/nControl, PFx Brick, and increasingly more. And this is wonderful. This post is just another one in this line. The difference is that I tried to use exclusively original LEGO stuff. Based on IR communication, it works perfectly well, but only within a range of about 1 m, which is not that good for train/track control ... So there was “only” one but significant modification required: Changing from IR to RF communication. This post illustrated how to do that. And if you don’t want to break into your PF receiver at all but just an add-on, this works also perfectly well, but is somewhat more elaborate. The ultimate goal of this project is to control diverse LEGO devices (PF, RC-train, RCX, NXT, Scout, MicroScout, Spybotics) from one device. In my case from a program running on my computer. However this could also be any device that can generate LEGO Mindstorms IR messages (which were introduced with the RCX, as far as I know), for example: A computer with one of the LEGO IR Towers attached, running the Bricx Command Center (BricxCC) software, A computer with one of the LEGO IR Towers attached, running any other program, which has access to the LEGO IR Towers; this includes the various programming environments and languages such as NQC, RobotC, or any custom program that has access to either a serial port for the serial tower or the LEGO drivers for the USB tower. (Note that on 64 bit platforms, the USB tower does not work anymore, since TLC never updated the required driver for the tower. In that case the stone old serial tower attached to a RS232-to-USB converter has to be used and accessed via a free COM port, preferentially in the COM1 … COM8 range. Works like a charm. Some people have trouble to get BricxCC or the original RXC 2.0 Mindstorms software communicate with the RCX only caused by the missing driver. Some revert back to 32-bit or even Win98 … not necessary!) Any of the RCX, Scout, or Spybotics, NXT(+IR Link Sensor) PBricks, Any learning remote, that was trained with any of the above means of generating LEGO Mindstorms messages; I am usually using BricxCC for programming. For testing purposes on my train layout, the programmed learning remote is very handsome: On my home-office style train layout (yes, I do work here as well), there are currently running/installed 8 PF trains 1 RC train 2 RCX controlled trains In addition to 2 RCX switch controllers (one serving 7 switch points using PF M motors, the other 12) 2 Scout switch controllers (one serving 3 switch points using 3 MicroScouts, the other 7) 1 Scout train bridge controller, see below 2 RCX light controllers with 3 outputs each, see below Each of the PBricks (RCX, Scout, NXT) have their own "personal" ID they recognize and respond to; the PF and RC trains are handled by the NXT PBrick (equipped with the IR Link sensor from HiTechnic) serving as central “PF/RC-train communications hub”. The NXT recognizes a total of 3 (RC) + 8 (PF) = 11 ID’s and maps these to the 3 RC and 8 PF channels: The NXT is operated with standard LEGO firmware (V1.31) and the LEGO NXT-G software environment is used for programming. Unfortunately the IR Link sensor has a very limited communication range, far less than any other IR light emitting LEGO device. This was one more reason for me – other than wanting no line of sight operation – to switch to RF. I have thus placed one of my IRRF transceivers (big words for not much, this is just what I am calling them) right in front of the IR Link sensor, which sends out every 38kHz modulated IR light it detects into RF space and listens for any 433 MHz signals in half duplex mode on a first come first serve basis: If IR light is detected then RF is sent out – if RF is detected IR is sent out. Both channels are dynamically mutually “blocked”; when an IR message is sent out it will continue to do so until finished, the same holds true for RF. Here is an overall schematic of the RF connectivity and direction of signals. In case of PBricks (NXT, RCX, Scout, Spybot) bi-directional half-duplex communication is possible (but not required), thus the IRRF transceivers come in handy. In other words: The addressed PBrick may reply with “OK”, “Did not recognize the payload”, or “I am busy”. In case of NXT to PF or RC-train, just uni-directional communication without any feedback is possible. The NXT-G program running on the NXT PBrick equipped with the HiTechnic IR Link sensor is is available on my university account. This navigates you to a folder , which contains the entire program. It is divided into the main program “RCPF_Control_14” and several “MyBlocks”. This structure is entirely owing to the limitations of the LEGO NXT-G software GUI. One could readily program (“tie together” is better phrasing) this is one block – but the GUI freaks out when exceeding a couple of nested loops. Putting these into individual MyBlocks circumvents this problem. The compiler readily generates the correct output code – “regardless” (I found no limits) of number of MyBlocks nested or called. This is the workflow on the entire layout: Essentially, one supplies an address byte plus a payload byte consecutively as two LEGO messages within let’s say 2 seconds; that is easily manageable with the programmed remote. When programs send out the two messages, the time between ID and payload byte can be much shorter, in the 100 ms range. The two bytes are each encoded according to the “LEGO Mindstorms IR message” protocol. Prepare 2 messages: Address as LEGO IR message + payload as LEGO IR message: Send these messages consecutively out into RF space: Any “intelligent” device equipped with an RF receiver will recognize its own address, listen for the payload and act appropriately. Example: RCX1 has address 192. We issue the sequence “message 192” + “message 8”. RCX1 will now do what “8” means within its own program running. Another example: NXT1 recognizes all addresses between 194 and 205. Let us say, 194 to 202 are mapped to PF trains 1 to 8, and 203 to 205 to RC train devices 1 to 3. That would cover the regular PF and RC address space. NXT1 senses address 194 and payload “-5”. It then uses the IR Link to send out the PF single pin command “PF channel 1A motor power -5” into RF space. Which lets the corresponding PF train equipped with an RF receiver “go reverse at power level 5”. And “205 + 4” will then get RC train #3 on forward level 4. The device addressed acknowledges the reception of the messages by sending out “OK” or any kind of error message (e.g., “I am busy”) to the caller. When using one-way communication, e.g. the handheld remote control, that acknowledgement goes of course unheard – when running a program with IR tower that could be recognized by the program and acted on (simply resending the message or wait and then resend and so on). Using the PF single pin command lets the PF receiver “jump” to the respective power level; when it was at 0 = stop, sending “7” would bang the motors full forward. This is handled by the NXT program as well: It slowly increases the power level with programmable delays between the steps. This results in a more “realistic” train behavior. The LEGO RC train protocol just allows the commands “increase” (+1), “decrease” (-1), “stop” (0) on a scale of -7 to +7. The PF protocol allows the increase (+1)/decrease (-1) scheme as well, however, a control program may lose “track” when such a command issued was not received properly, since there is no feedback. When all three available RF frequencies 315, 418, and 433 MHz are used, 8 x 3 = 24 PF devices can be controlled with a total of 12 PF receivers. That is not including the change of the “address space”-bit in the PF protocol, which would double this number to 48. Any other track or trackside devices to be remotely controlled with PBricks works of course as well; here is an RCX turning on/off the light in the light house or the diffuse and changing light in a scary tunnel not shown (yet). Or a Scout letting a bridge go up or down and reporting the bridge status to the host control program. Switch drives hooked up to an RCX or Scout based brick-built “switch drive controller” may also recognize the address + payload sequence and act appropriately: “RCX2, put switch #5 in branch position”. See list of my controlled stuff above. In summary: You can control PF, RC, RCX trains and RCX, Scout, Spybot operated switches or other devices with an almost pure LEGO solution. Up next: Build switch drives and controllers solely from LEGO bricks + Scout, RCX or Spybot PBricks and then program them using LEGO software. (Sorry for the long post) Best regards, Thorsten
  12. Hello friends, It is I, elrid from india, and I am of having difficulty sending sounds over bluetooth to a second NXT. I have a master-slave relationship between two of my best NXT specimens, but one of them does not have working speakers (even the startup noise doesn't work my friends!!!). So, I am of trying to get the first NXT to signal one of another NXT with speakers work over bluetooth connect. I use BrickxCC language. Any help is appreciate. Thank you friends! I am see with my eyes there is individual named DR_SPOCK who is very helpful and handsome. Hopefully he can help.
  13. I created this modified Bucket Wheel Excavator some time ago, and I thought I would like to share it on this forum. After building the original BWE, I wanted to try to incorporate some Mindstorms functions into it. I managed to motorise all the active functions, using both an EV3 brick and motors, as well as some PF motors. Functions can be preprogrammed, or can be remotely controlled using an EV3 IR remote. Here is a list of the functions: Bucket wheel rotation and main conveyor belt - PF XL motor Lower conveyor belt - PF medium motor Boom arm elevation - EV3 large motor Lower conveyor swivel - EV3 large motor Superstructure rotation - EV3 medium motor Driving - EV3 medium motor Since I owned an NXT as well, I used it to motorise the small mining truck that was included in the set. There are also some LEDs that illuminate the 'work area', but they don't really do a good job, its just a nice thing to include. Here is a video of the excavator in action, as well as the mining truck (sorry about the poor resolution and bit rate): More info about the machine can be found here: Let me know what you think of it in the comments!
  14. For our Sioux.NET on Track project (see, we not only write a PC application in Microsoft.NET (C#). But we also write quite some code that runs on the EV3 bricks. In this article, you'll find programming tips & tricks for the Lego Mindstorms EV3 programming environment. Is it possible to have two or more EV3’s in Daisy Chain mode and use WiFi to connect to the PC application? Yes, you can. Read the full article how you can achieve this at the blog: You can use two or more threads in parallel to run on an EV3. But how do you synchonize them? Read the article how to do this at the blog: More to come later. Enjoy, Hans (moderator of our Wordpress blog Sioux.NET on Track)
  15. Hi, my NXT Axle Sorter is finished. This machine works with a Lego Mindstorms NXT 2.0 and an IR Link sensor. The little car that you see puts the axles in the right containers. The large 'building' with AXLE measures the length of an axle with the color sensor as you can see in the video. The little car drives over some gear racks. The ultrasone sensor reads the distance and the IR Link sensor sends the signals to the little car. Here you can see the inside of the machine: The machine sorts normal axles. Also the new colors (example: the red 4) If you want to sort your axles you need to do these five steps 1. Put the axles in the machine 2. Press the button on the NXT 3. Have a drink 4. Take the containers with the sorted axles out of the machine 5. Make your next Lego Creation If you want more pictures about some details, let me know. Here is the video:
  16. My first NXT creation! A Lego Mindstorms NXT pinball machine featuring 3 interactive servo motors, 2 touch sensors, and a light sensor! Flippers are activated via Touch Sensors on either side of the machine. Features auxiliary high-speed spinner. Makes for hours of fun and awesome gameplay! Programmed in NXT-G. How was the video style? Was it engaging? Did you enjoy the video? I am also extremely busy with virtually no time whatsoever to build, so unless I am extremely motivated, I won't be able to build anymore for a little while. I am open to suggestions of future builds, though!
  17. At our Flickr page you can view the photos of our visit at Lego World 2016 in Utrecht: A video is also available: Enjoy, Hans
  18. Sioux.NET on Track is a group of enthusiastic colleagues who come together after working hours to get experience with Microsoft.NET. To make learning fun, we develop an application in C# for making a full automated Lego train, using Lego Mindstorms and Lego Power functions. The layout is always shown at Lego World in the Netherlands. Our plans for 2016 have been published at our blog: as well as an article about the new updated crane positioning. You can also view a video at our Youtube channel about the power chain systems: Enjoy, Hans
  19. In this video, I show you what exactly comes in the 9797 Lego Mindstorms NXT Base Set with this stop-motion style unboxing. If you liked this video and would like to see more unboxing videos in this style, please let me know!
  20. I've been testing leJos with my old NXT brick and something seems to be wrong.When I flash the brick with latest leJos firmware, it works fine. After some time, it starts spewing some garbage onscreen: The only thing I can do is press Off button, but then it doesn't boot up again and I need to try multiple leJos/official firmware reflashes to get it to work. Has anyone encountered anything like that? Any help would be greatly appreciated.
  21. The Robot: Model of a Lego Mindstorms NXT Sumo bot. The object of the sumo game: Push the other robot out of the ring. The objectives of our creation was to be low to the ground and still have all of the required functions. Completion date: 29/04/2012 Power: electric (NXT brick) Language: NXT-G Bricks: 1 Motors: 2 x NXT motor Sensors: Ultrasonic, Color Parts: Approx: 297 More reading. https://nxt45.wordpr...ent-sumo-winner
  22. OK, well the American Semi truck is a very recent MOC, but I made the European one quite awhile ago, and just never got around to uploading the pics, so.. they are. European Semi truck specs: Front wheel rack and pinion steering rear 4WD only uses 2 motors, so you could build a trailer and add a/some motorized function(s) Pictures Here is the overall model Here are some pics of the front, and back. And some pics of it without the studded assemblies hiding the NXT brick. And that is it, now for the American style semi truck, and... ... the trailer with grabber Specs of American Semi truck, and trailer (with grabber) [Truck] Rear 2WD (It's on not the back axle, but the axle before it). [Truck] Opening hood. [Truck] Ultrasonic sensor for obstacle avoidance. [Trailer] Motorized grabbing arm controlled by button hidden on either side of the trailer. [Trailer] NXT Brick right, and left buttons control steering for the truck. Now the pictures, truck first. Front view of the truck View of the hood opened revealing the steering motor. Close up on the grille. Back view of the truck (revealing that the NXT brick is in the trailer, to keep the truck smaller so I would have more pieces. And now on to the trailer. Birds eye view. View from the front of the trailer And that it, I'm working on a tower crane now, if anyone wants to geve suggestions one what vehicle to build next I'm fine with I welcome that.
  23. Hello. This is my first MOC I've uploaded, but I've made many. :) So this is my RC, 6wd, LEGO Mindstorms NXT Log Skidder. For It I have one motor for driving the 6 wheels, another for steering, the last motor for lifting up the logs, and then a manually operated claw. EDIT 1, 16/5/01: I only have about 5-6 hundred LEGO Technic pieces so forgive me for any styling, look issues. :) Here are some pics (Click here for the full resolution images). A pic highlighting the re-designed log pulling arm (it can swivel around 360 now) A close the actual grabbing part of the log pulling arm. a closeup on the re-designed cabin. A picture highlighting the gullwing doors on the cabin. A picture highlighting the fact that the cabing tips up, and showing some of the (fake) machinery in the log skidder underneath the cabin. Another picture highlighting the titlting cabin, and showing some of the (fake) machinery in the log skidder underneath the cabin. A back view the the Log Skidder and the "engine" (NXT brick). A picture showing the whole model. One last picture showing the whole model.
  24. Teaser: Introduction The article describes the experience of using the Lego Mindstorms EV3 set for creating a robot prototype with software and manual control via Robot Control Meta Language (RCML). Next, we will discuss the following key points: Assembly of the robot prototype from the Lego Mindstorms EV3 set. Quick RCML installation and configuration for Windows. Robot software control based on EV3 controller. Manual control of the robot peripherals using a keyboard and a gamepad. Jumping a little ahead, I will add that for implementing control over a Lego robot via a keyboard, one will have to create a program containing only 3 lines of code. More information about it is available under the cut. Step 1 First, the Lego Mindstorms EV3 set was used for creating a prototype robot to be used for programming and manual piloting. The robot's design is similar to that of a truck chassis. Two motors installed on the frame have one common rotation axis connected to the rear wheels via a gearbox. The gearbox converts the torque by increasing the angular speed of the rear axle. The steering system is assembled on the base of a bevel gear speed reducer. Step 2 The next step is RCML preparation for working with the Lego Mindstorms EV3 set. Download the archives with executable files and library files and The following describes the quick start procedure for ensuring interaction between RCML and the Lego robot controlled by an EV3 controller. Content directory after extracting the archives Next, one has to create configuration file config.ini to be placed in the same directory. To implement control over the EV3 controller via a keyboard and a gamepad, connect modules lego_ev3, keyboard and gamepad. Listing of configuration file config.ini for RCML [robot_modules] module = lego_ev3 [control_modules] module = keyboard module = gamepad Next, the EV3 controller should be paired to the adapter. The instruction for pairing an EV3 controller to a Bluetooth adapter: The reference guide contains an example of pairing a Lego Ev3 controller to a PC running under Windows 7 operating system. Next, go to the Ev3 controller settings and select menu item "Bluetooth". You should make sure that you have set the configuration settings. “Visibility” and” Bluetooth” should be ticked. Go to "Control Panel", select "Devices and Printers", and "Bluetooth Devices". Click on the "Add device" button. A window with available Bluetooth devices will open. Select "EV3" device and click "Next". Dialog box "Connect?" will be displayed on the EV3's screen. Check as appropriate and confirm by pressing the center key. Next, the "PASSKEY" dialog will be displayed, enter digits "1234", and confirm the key phrase for pairing the devices by pressing the center key at the position with the tick image. In the pairing wizard of the device, a form for devices pairing key will appear. Enter "1234" and press "Next". A window with confirmation of successful device connection will appear. Press the "Close" key. At the PC, return to "Control Panel", select "Devices and Printers", and "Bluetooth Devices". The paired device will be displayed in the list of available devices. By double clicking, go to “EV3” connection properties. Next, go to the "Hardware" tab. By double clicking, go to the connection properties of the "Standard Serial over Bluetooth link". The COM port index specified in the properties should be used in the config.ini configuration file of the lego_ev3 module. The example shows Bluetooth connection properties of a Lego EV3 controller with the use of a standard serial port COM14. Further module configuration is limited to specifying the address of the COM port used for communication with the Lego robot in the configuration file of the lego_ev3 module. Listing of configuration file config.ini for the lego_ev3 module [connections] connection = COM14 [options] dynamic_connection = 0 Now configure the keyboard module. The module is located in the control_modules directory, then keyboard. Create configuration file config.ini next to the keyboard_module.dll file. Before creating a configuration file, specify the actions to be performed by pressing keys. The keyboard module allows using keys with a certain numeric code. The table of virtual key codes is available here. As an example, I will use the following key press events: The up/down buttons are used to rotate the rear wheels motor forward/backward. The left/right arrows turn the wheels left/right The configuration file of the keyboard module describes which axes are available for the programmer to implement interaction with the robot in the manual mode. Thus, in the example we've got two control groups - these are keyboard axes. To add a new axis, stick to the following rules of axes description. Rules for describing axes for the keyboard module. 1. In case of adding a new axis, add axis name property to section [mapped_axis] and set it equal to the value of the keyboard key in HEX format; there may be several keyboard button values for one axis. In general, an entry in the [mapped_axis] section will look as follows: axis_name = keyboard_button_value_in_HEX_format 2. You should set the maximum and the minimum values that the axis may take. To do so, add to the config.ini configuration file a section named as the name of the axis, and set the upper_value and lower_value properties for passing the values of the axis' maximum and minimum. In general, the section looks as follows: [axis_name] upper_value = the_max_axis_value lower_value = the_min_axis_value 3. Next, you should determine what value the axis will have after a previously defined button on the keyboard is pressed. The values are defined by creating a section with the name consisting of the axis name and the value of keyboard button in Hex format, separated by underscores. To set the default (not pressed) and pressed state values, unpressed_value and pressed_value are used, where the values are passed. In general, the section in this case will look as follows: [axis_name_keyboard_button_value_in_HEX_format] pressed_value = axis_value_with_pressed_button unpressed_value = axis_value_with_released_button To implement the control over the robot prototype, a configuration file of the keyboard module has been created, which includes the "go" and "rotate" axes. The "go" axis is used to indicate the direction of robot movement. When the “up arrow” button is pressed, the axis is set to 100, and when the “down arrow” button is pressed, the axis is set to -50. The rotate axis is used for setting the front wheels turn angle. When the "left arrow" button is pressed, the axis is set to -5, and when the "right arrow" button is pressed, the axis is set to 5. Listing of configuration file config.ini for the keyboard module. [mapped_axis] go = 0x26 go = 0x28 rotate = 0x25 rotate = 0x27 [go] upper_value = -100 lower_value = 100 [rotate] upper_value = -100 lower_value = 100 [go_0x26] pressed_value = 100 unpressed_value = 0 [go_0x28] pressed_value = -50 unpressed_value = 0 [rotate_0x25] pressed_value = -5 unpressed_value = 0 [rotate_0x27] pressed_value = 5 unpressed_value = 0 Next, for control implementation using a gamepad, configure the gamepad. Configuring the module includes creating configuration file config.ini next to gamepad_module.dll in the control_modules directory, followed by gamepad. Listing of configuration file config.ini for the gamepad module. [axis] Exit = 9 B1 = 1 B2 = 2 B3 = 3 B4 = 4 L1 = 7 L2 = 5 R1 = 8 R2 = 6 start = 10 T1 = 11 T2 = 12 RTUD = 13 RTLR = 16 LTUD = 15 LTLR = 14 arrowsUD = 17 arrowsLR = 18 [b1] upper_value = 1 lower_value = 0 [b2] upper_value = 1 lower_value = 0 [b3] upper_value = 1 lower_value = 0 [b4] upper_value = 1 lower_value = 0 [L1] upper_value = 1 lower_value = 0 [L2] upper_value = 1 lower_value = 0 [R1] upper_value = 1 lower_value = 0 [R2] upper_value = 1 lower_value = 0 [start] upper_value = 1 lower_value = 0 [T1] upper_value = 1 lower_value = 0 [T2] upper_value = 1 lower_value = 0 [RTUD] upper_value = 0 lower_value = 65535 [RTLR] upper_value = 0 lower_value = 65535 [LTUD] upper_value = 0 lower_value = 65535 [LTLR] upper_value = 0 lower_value = 65535 [arrowsUD] upper_value = 1 lower_value = -1 [arrowsLR] upper_value = 1 lower_value = -1 Step 3 The next step is writing a program in the RCML language. At the root of the created directory, create the program file. The name and extension of the program file may be anything, however, Cyrillic characters are to be avoided. In the example, the filename is hello.rcml. For the lego_ev3 module, the robot redundancy program code looks like: @tr = robot_lego_ev3; The lego_ev3 module connection page contains description of the majority of the features supported by the controller. As a test example, a program for automatic robot drifting has been created. The algorithm of the program is as follows: function main() { @tr = robot_lego_ev3; //Reservation robot @tr->setTrackVehicle("B","C",0,0); //Installing the engine synchronization @tr->motorMoveTo("D",100,0,0); system.sleep(500); @tr->trackVehicleForward(-100); system.sleep(1000); @tr->motorMoveTo("D",50,-50,0); system.sleep(4000); @tr->motorMoveTo("D",50,50,0); system.sleep(4000); @tr->trackVehicleOff(); system.sleep(1000); } After reserving the first available robot, two motors are paired for further operation as one. After that, the robot starts drifting. Program description of robot actions makes it possible to precisely set front wheels turn angles and rear wheels rotation speed. Using this method allows achieving the results that are difficult to replicate by manual piloting from a keyboard or a gamepad. The program is compiled in the windows command line. First, navigate to the new directory with the rcml_compiler.exe and rcml_intepreter.exe executables. Then enter the following commands. The command for compiling the hello.rcml file: rcml_compiler.exe hello.rcml hello.rcml.pc The result of compilation is a new hello.rcml.pc file in the created directory. Now make sure the EV3 controller is enabled, and paired to the Bluetooth adapter. A gamepad should be connected to the PC. After that, run the program file execution command: rcml_intepreter.exe hello.rcml A video showing the robot motion program is located below this article. Step 4 The next step is controlling the robot manually, using a keyboard. The following describes the process of software pairing of robot motors to the keyboard. Keyboard can be used for controlling any motor of the robot. Within the framework of the example, control over the following mechanisms has been implemented: Front wheels turn angle, Direction of rear wheels rotation. The algorithm of the program is as follows: function main() { @tr = robot_lego_ev3; @tr->setTrackVehicle("B","C",0,0); system.hand_control(@tr,"keyboard", "straight","go", "speedMotorD","rotate"); } Then the program should be compiled and executed. The result of manual controlling a Lego robot via a keyboard is shown in the video at the bottom of the page. Step 5 In addition to the keypad module, the gamepad module is available, which makes it possible to manipulate the robot using the gamepad. For implementing control over the robot via a gamepad, one should describe at the program level what axes of the robot will be set to the values of the gamepad axes. The algorithm of the program is as follows: function main() { @tr = robot_lego_ev3; @tr->setTrackVehicle("B","C",0,0); system.hand_control(@tr,"gamepad", "straight"," RTUD", "speedMotorD"," RTLR"); } Then recompile the program and execute it. Below is the result of manual control over a Lego robot via a gamepad, and all previously connected methods: Control Lego Ev3 by using RCML The article briefly shows only certain RCML features. A more detailed description is available in the reference guide.
  25. Hi all. Here's a brief video of the EV3 floor roving robot I've been working on for the past few days. It's pretty crude but can go a long time without getting stuck. It makes use of one distance scanner in three positions by using a clutched IR sensor, has two bumper sensors that are padded by shock absorbing springs to reduce impact on the touch sensors. Behind the bumper is mounted a color sensor on the front that is used to measure near distance and ambient light. It appears to flash because it's rapidly switching between measuring these two things, With this sensor it can detect objects near to the ground that the main sensor peers over, and also back out of shadows so it doesn't get under furniture. Working on the software has been the long part as there is much debugging to do and each test run can take a long time depending on what I'm trying to improve. It makes decisions based on distances to its surroundings on three sides, so if it senses it's coming up on something in front of it, or a bumper strike is detected, it will choose to turn left or right depending on which direction is more open.