Loading the train with the 6-axis DOF robot arm

I wrote a small test program for the robot arm to load the train with two containers. Loading the two wagons was done in one minute, so much faster than the candy crane.

Have a look at the video and please share with me what you think of it.


Video impression of our layout at Lego World Utrecht 2016

A video impression of our layout at Lego World Utrecht 2016 has been uploaded to our Youtube channel.

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.

Connecting the NXT to the EV3: use the NXT as remote control for the EV3

In the post of November 11, 2013 (yes, that is quite some time ago) I announced the beta release of the application NXT to EV3 Connection Hub. This application makes it possible to use the NXT as remote control for the EV3.

Continue reading

Successful run of Candy Transporter Mechanism

Hooray! Today I had the first successful run of the Transporter Mechanism. Finally, I succeeded in closing the square (literally) that the candy containers are circling around in the container storage.

Continue reading