Lego World Utrecht 2015, an impression

Lego World Utrecht 2015

On day 1, our train has run about 100 complete rounds. Delivering the same amount of candy to the children. Everybody was impressed by the layout and the magic of our fully automated train, card reader, candy rotation stock, candy crane and the delivery station.

Continue reading

Setting up the layout at Lego World Utrecht

Today, three team members of the Sioux.NET on  Track have been setting up the layout at Lego World in Utrecht. The system is fully up and running to welcome the visitors and to demonstrate what we have been doing in the past year.

In the photo below you see the system being setup by Otto Schellekens, Bob Duisters and Michael Beurskens.

Setting Up The Layout Collage

Sioux.NET on Track for Lego World Utrecht 2015

Sioux.NET on Track for Lego World Utrecht 2015

The last weeks were rather hectic. Finalizing our fully automatic train layout was just like a real project: strange errors, unreliable bluetooth, confused light sensors. We had it all. But we made it! Continue reading

Redesigning the Candy Rotation stock

After building the final version of the Candy Rotation Stock (CRS), I transported the object to our office to integrate it with the other parts of the track. I found out that the CRS was not robust enough and it took some time before it worked again. Although the concept works, it was not good enough to run for a couple of minutes without problems. And I needed it to work for four days at Lego World!

So I took the difficult decision to redesign it.

Continue reading

Final version of the Candy Rotation Stock (in test set-up)

At our Youtube channel, I have uploaded the final version of the Candy Rotation Stock (CRS). In the picture below, you see the CRS in the test set-up.

Candy Rotation Stock (final version in test set-up) Continue reading

Video added: Motor Protocol Communication

Motor Protocol - Two Motors

I’ve uploaded a video to Youtube with an example of the motor protocol. It explains how the information is passed from the PC to the “Buffer Control” brick and then – using the Motor Protocol – is passed to the daisy-chained-EV3’s.

Continue reading

Connecting the two daisy-chained EV3 bricks to our PC application…

Candy Rotating StockContext

The new developed Candy Rotation Stock (CRS) is controlled by two EV3 bricks in daisy chain modus. The CRS uses a total of three large EV3 motors for the major movement, one medium motor for the conveyer belt that is part of the conveyer system and two medium motors for the movement of the branch. Four sensor ports are needed, so that could be handled with one brick. The three large motors are always switch on or off simultaneously. If a motor multiplexer would exist, the CRS could be controlled by one EV3 brick.


So, what is the problem? By using the daisy chain modus, you can extend the number of ports by serializing the bricks which makes one  virtuel EV3 with 16 motor ports and 16 sensor ports. True, writing the EV3 program to control the CRS is no problem. In the Youtube video is shown that this works (see the previous article).

The problem that we have, is that the CRS is part of a larger picture. When the visitor chooses a color, this color needs to be  passed to the CRS, the CRS moves a candy in  the chosen color to the crane pickup position, the crane needs to get a signal that the candy is available, etc. So, we need communication with the CRS brick. And here starts the problem: if you connect two EV3 bricks in daisy chain modus, the USB port where you also need to put the WiFi dongle, is now occupied by the USB cable to the second brick. The same problem occurred at the Candy crane, which is also controlled by two EV3’s. The solution that we used there, was to move the intelligence of the crane movement to the PC. We could do this again, but that would mean a change in our software architecture. And next: let’s find another solution since the goal of our group is to learn from these type of problems and find (new) ways to solve these.


The best solution is (of course) the availability of a firmware that supports WiFi and daisy chain modus. See the article about the plans that we had for 2015, among of them was the new firmware. But I don’t think we will have this before Lego World 2015 …

So, another plan was needed and we came up with the following: the CRS bricks will not be connected by WiFi to the PC application. No, the communication is completely done locally:

  1. The chosen color at the PUI is send to the Buffer Control (BC) brick. This EV3 brick is connected by WiFi to the PC application.
  2. Then, the BC brick sends a message (I will come to the ‘how’ later) to the CRS brick which color needs to be picked.
  3. The CRS brick makes sure that the right candy is transported to the Crane Pickup location.
  4. When ready, the CRS brick communicates back to the BC brick that the candy is available for the crane. The BC brick sends a message to the PC, so the rest of the flow can continue (crane movement, etc).

Brick 2 Brick communcation

So, the question is: how do the BC brick and the CRS bricks communicate? The answer is: by using two motors that are physically connected, see the sketch below. An additional advantage is, that it also works between an NXT and EV3, EV3 and EV3 or NXT and NXT. So, if WiFi is not possible (daisy chain, NXT) and bluetooth not possible (NXT to EV3), then this may be do the trick:Lego Motor Protocol

In this example, pressing the button on the Ev3 starts a short rotation of the EV3 motor. Since the EV3 motor is connected to the large EV3 motor, the rotation is the trigger and starts an action. For example, run the medium motor for 20 seconds. When the action is done (= medium motor stops), the large EV3 motor is rotated backwards. This results in a rotation of the NXT motor, and this is the trigger for the NXT program. The basis of this communication protocol is that the large motors (both at the NXT and the EV3) can either be used as activator (motor movement) and as sensor (rotation).

Ok, I admit: the communication protocol is rather slow. But it works. And you don’t need a PC. You can extend the protocol in two triggers: clockwise rotation is trigger 1 and counterclockwise rotation is trigger 2. I am now debugging the NXT and EV3 code. When I have this finished, I will upload a video to our Youtube channel.