Tag: mindstorms

How to stop the Train at an exact position?

Posted on by Hans Odenthal

The replacement in the train of the color sensor by two touch sensors is finished. In this video, you can see the train stopping exactly at the red bump. The difficulty is the rotation of the speed control on the battery box 8878. The zero speed and maximum speed (= ‘speed 3’) are easy, this is done mechanically. To prevent the construction breaking down by the powerful EV3 motor, we need white clutch gears (76244). But due to this gears, the rotation of the power knob fluctuates a bit.

The maximum speed is too high to have the train stopped at an exact position. We need this exact position (with a tolerance 4 studs) for loading and unloading the train. So we need a speed in between (‘speed 1’). As said, rotating the power knob to this exact ‘slow’ position, is not accurate enough. You end up with a speed of zero (not ok), the desired speed (‘speed 1’, ok) or still too much (‘speed 2, not ok’). Driving always on speed 1 (as maximum speed, mechanically topped) could have been a solution, but it doesn’t look nice to see a train at such a slow speed and the train doesn’t make it through the curves due to the friction (especially when the juice is getting low).

So how did we solve it? As you can see in the video, when the train detects the white bumps, it will make a full stop. Then we rotate the speed knob every 5 seconds with 10 degrees. At a certain point, the power knob reaches the point that the train starts driving at speed 1. It will then detect the red bump within 5 seconds. Destination reached! The 5 seconds delay is enough to reach the red bump before the speed knob is rotated again.

  • Advantage: it will always find the red stop, even with a tolerance of only 1 stud.
  • Disadvantage: it takes around 15 – 20 seconds to find the red stop after it hits the white bump.

Because we need the train to stop at an exact point, we take the disadvantage for granted. Certainty over speed.

split-flap display: almost finished

Posted on by Hans Odenthal

The Split-Flap display to show the three digit number of the ticket is almost finished. Only the topside of the casing needs to be build. I’m waiting for the ordered bricks to finish the construction.

The software is currently only a demo program, generating random numbers between 0 and 999.

a three digit split-flap display

Posted on by Hans Odenthal

I am building a so called split-flap display to show the number that has been read by the TDU (Ticket Dispense Unit). To refresh your memory: the visitor of our layout (at Lego World) retrieves a ticket containing a number. This ticket is used to – after the train has delivered his candy – open the corresponding locker. The progress of the candy being delivered can be viewed on the screen, the ticket number is his tracking number.

In the video below you can see the TDU in action (starts at time frame 0:40).

After the number has been read, we want to show this on a display. Because split-flap displays are often used on train stations, I want to build one from Lego. As far I know, this has not been done before. So I had to invent it completely from scratch.

I had some other proof-of-concepts, but the main problems was that the flaps were to thick. You need thin flaps in order to keep the two flaps as vertical as possible.

I have now a first working proof-of-concept. I am still thinking how I can close the gap between the two flaps a bit more, but I have no ideas how to do this.

You can read more and watch a video about ‘the making of’ at the Eurobricks forum. Next step is to add a (touch) sensor in order to ‘know’ which flap is currently displayed. When I have the first digit complete, a total of three will be build since the ticket have three digit numbers.

The Container Spiral Storage – The making of …

Posted on by Hans Odenthal

The Container Spiral Storage finds it origin during one of the test runs. We ran out of containers at the trebuchet. In the pictures below, you can see the conveyor belt that transports an empty container to the funnel. The funnel catches the candy thrown by the trebuchet and drops it in the empty container.

This conveyor belt is able to store 8 empty containers, you can see below the conveyor belt with a row of six . To the left there is a bit more empty space, but this is where the table ends.

To the right of the conveyor belt (which is the bottom side on the picture), there is some more free space. One of the team members was asking for more container storage. While pointing to the empty space, he asked me to extend the conveyor belt with ‘some sort of spiral’. “Just build something simple”, he said. And I took the challenge.

–ooo—ooo–

I liked the idea of building a spiral. It needed to be something in the same style of the already existing conveyor belts, as can be seen on the previous photos. This was the first prototype of the container spiral.

As you can see in the video, the container runs easily downhill. Even so easy, that I needed to create a rail on the outer side of the spiral to prevent the containers from tumbling. The picture below has been made in Studio 2.0. Not only to create these amazing renderings, but also to count the number of bricks needed to build the spirals.

As you can see in the renders, the colors were matching with the already existing conveyor belts: the rollers black/red, the supporting structure in light bluish gray and the borders also red. The gears are all in light/dark bluish gray.

The spiral would consist of one and a half circles, making the tower +/- 30 cm in height. It would look something like the picture below.

As you can see in this picture, the motors haven’t been designed yet. I planned to insert them in the physical version once the spiral was build. An EV3 brick has 4 motor ports. Every half circle would be driven by one motor, and the fourth motor would drive the straight part that connects to the existing conveyor belt. That was the plan.

The next step: looking for Bricklink sites to buy the needed bricks.

But that was easier said than done ….

–ooo—ooo–

I will come back later on the difficulties I encountered while searching for the needed bricks. First, I want to give you an update about the second part of this build: the elevator.

Besides the spiral, I wanted to create a stack of containers. The stack would contain at least 10 containers, dropping them one by one (on request of the trebuchet conveyor when almost empty) onto the spiral rollers. My plan was to add this elevator to the start of the (extented) conveyor belt as shown in the following sketch:

It took me three prototypes to find a solution that would work, this is shown in the following video.

Because the containers are rotated 90 degrees, the total height would be around 60 – 75 centimeters. That would make the structure not very stable, especially when it needed to be transported. So I decided to look for a way, to revert the movement from a downwards dispenser, to an upwards dispenser.

–ooo—ooo–

Coming soon: the birth of the container spiral storage

Posted on by Hans Odenthal

It has been quite a while that I have posted an article about our large train layout. But that doesn’t mean that there was no activity. For example, we have made some major updates to the software application and all EV3’s are now running on EV3DEV.

With respect to new builds, I have been working on the new Lockers (you can see the result on Youtube) and on the Container Spiral Storage. In the pictures below you can see some pictures of the creation of this new build. I will soon write a longer article about the birth of the container spiral storage and the challenges I have faced during the build.

Stay tuned …

Our EV3DEV / C++ Daisy Chain unlocks additional functionality

Posted on by Hans Odenthal

In our current layout, we have two Lego constructions that require more than 4 motors and we use the daisy chain function for that. In case you don’t know: the daisy chain functionality offers you the possibility to connect up to 4 EV3 bricks, one master and 1, 2 or 3 slave bricks. You program the master brick as usual, but you can also access the motors and sensors as if they were connected to the master brick. So you can access a maximum of 16 motors and the same number of sensors. That is the theory, in practice this is unfortunately not the case. The Lego software is very buggy. Most of the time, the sensors of the slave brick(s) are not seen by the master brick, motors are ok-ish. If you only use motors connected to the slave, it works most of the time. Of course we checked with our Mindstorms friends if there was a solution for this. Their answer: Lego knows about the problem, they are not fixing this. The solution: don’t use daisy chain ….

Anyway, while moving from the standard Mindstorms EV3 programming environment to the EV3DEV / C++ environment, we noticed that EV3DEV doesn’t support the daisy chain option. We searched the internet if somebody else had already implemented the daisy chain functionality in EV3DEV / C++, but that was not the case. So, we had the choice either to split the software and change the PC application (so we don’t need daisy chain), or to implement the daisy chain function in our EV3DEV software. We choose the last option. Of course, it is an additional challenge.

The principle that we want to follow, is basically the same as in the EV3 programming environment: you have one master brick running the application software and one or more slave bricks. The software running on the master brick should be able to access the sensors and motors on the slave brick(s) as if they would be connected to the master.

In order to achieve this, we needed to extend our motor and sensor library with additional methods. For example, you can create a motor like this for the master brick:

// Create a large motor at port C at the local brick (master)
EV3MotorLarge MasterMotorC = EV3MotorLarge(OUTPUT_C);

And we added the option to create a motor for the second, slave brick:

// Create a virtual brick, accessible at the specified IP address
// And create a large motor at port A at the virtual brick (slave)
slaveBrick remoteBrick("192.168.137.4");  
EV3MotorLarge SlaveMotorA = EV3MotorLarge(OUTPUT_A, std::make_shared<RemoteBrick>(slaveBrick));

Once the motors have been created, you can use a master or slave motor in the same way, e.g.

MasterMotorC.OnDegrees(100, 360, Backward);
SlaveMotorA.OnDegrees(100, 360, Forward);

So far, so good and nothing special yet. But as you can see, the creation of the virtual brick is based on an IP address. That implies, that you can also have a slave brick that is not physically connected by an USB cable. If it is connected via WiFi, it also works! And the number of slave bricks is NOT restricted to a total of 4 (1 master + 3 slaves). In theory, you could have an infinite number of slave bricks. Of course, there is a limit and that will have to do with the performance. I don’t have enough free bricks available to test the performance with 4+ bricks. Something for my backlog ;-).

Apart from the extended number of slave bricks, we have also added the option to access (from the master program) the LED lights on the slave bricks, the sound and the LCD display. In fact, everything we can do on the master brick, we can do on the slave brick(s).

How did we manage to do this? When the remoteBrick class is created, a TCP connection is setup between the master brick and the slave brick. On each slave brick, a generic ‘server’ program is running that accepts commands from the master brick. All commands that need to be executed on the slave brick, are send via a simple protocol by serializing the command into a string (e.g. “CreateLargeMotor,Output_A” or “MotorOnDegrees,100,360,OutputA,Forward”). On the slave side, the string is de-serialized and then executed.

In the current implementation, the server program needs to be started on the slave brick(s) manually. This will also be automated: when the remoteBrick class is created, it will start the server program automatically. Just work in progress ;-).