Just a small note: our project was selected from many subscriptions to join Lego World 2014 in Utrecht, The Netherlands.
We are now in the integration phase, the complete layout has been setup in our office so we can test our software against the completed hardware. Below you see the complete layout.
See you all at Lego World.
In the previous article about ‘Sending data over Wifi between our PC application and the EV3, part 3‘, I explained how the workaround works. This part describes the protocol that we are implementing to make sure that all data that is send, is correctly processed.
In an earlier article, I mentioned that I wrote a small test program to send commands to a NXT or EV3 program for testing purposes. I have updated this application with the possibility to send and retrieve data over a WiFi connection. Next, you must enter the name of the Brick name to connect to. Error handling is not implemented. For example, if you switch off the NXT or EV3 while the connection is open, the application crashes. That is the reason that I don’t share this application (yet, don’t know if anyone would be interested).
In the previous post, I wrote that I didn’t manage to get the Direct Commands working that open and read a mailbox. And that I managed to get the workaround working to send data from the EV3 to the PC application. In this part I will tell you more about the other route that I found.
As mentioned in the first part of this article, it is possible to send data from the EV3 to the PC application. In this part, I describe how I try to learn the syntax of Direct Command programming. Continue reading
In our project, we use 4 NXT and 5 EV3 bricks. Two of the EV3’s will be connected in daisy chain mode, so we need a grand total of eight connections to the PC application. In our version of 2013, we noticed that more Bluetooth connections results in less reliability. Because of that, our hardware architecture is now based on the NXT bricks to connect to the PC via Bluetooth and the EV3 bricks via WiFi. As mentioned in the previous article, the communication will be done by sending messages back and forth using the mailbox mechanism. By this means, we can create intelligent ‘hardware pieces’, that can handle complex instructions. For example, by sending the string “Uncouple” to a train, the responsible NXT brick will independently handle this instruction and controls the needed actions to uncouple the wagon from the train. The string is read by the Read Message Block, both available in the NXT and EV3 programming environment.
The PC application is responsible for connecting the various hardware parts (delivery station, PUI receiver, crane, etc) and the overall intelligence between these parts. This architecture makes it easy to test the several parts (see also the previous article about the test program) independently and gives more flexibility.
The Bluetooth communication was already implemented both for the NXT and the EV3. All we need is an extension that the EV3 can also communicate over the WiFi connection. That doesn’t sound to difficult. In this article you can read about the ugly truth. Continue reading
The PC application will connect to the NXT and EV3 bricks by Bluetooth (for the EV3, we are investigating if we can write a block for sending messages over a WiFi connection, but that isn’t easy).