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:
- 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.
- Then, the BC brick sends a message (I will come to the ‘how’ later) to the CRS brick which color needs to be picked.
- The CRS brick makes sure that the right candy is transported to the Crane Pickup location.
- 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:
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.