Sending data over WiFi between our PC application and the EV3 (part 4)

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.

Continue reading

Testing the NXT and EV3 programs (continued)

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).

PC To Mindstorms Command Hub - Version 2

Continue reading

Sending data over WiFi between our PC application and the EV3 (part 3)

Dead EndIn 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.

 

Continue reading

Sending data over WiFi between our PC application and the EV3 (part 2)

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

Sending data over WiFi between our PC application and the EV3 (part 1)

Bluetooth and WiFiIn 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 Candy Crane, Final version

In the previous post, I mentioned already that the Candy Crane does ‘in principal’ what it has to do, but the movements were not smooth enough and the accuracy was also a problem. In the last weeks, I have improved the movement and positioning. Below you find the final version:

Candy Crane - Final Version

And the LDD version:

Sioux.NET on Track - Candy Crane (Final Version)

This final version of the Candy Crane is controlled by two EV3 bricks:

1. Brick 1 (in the right tower) controls the movement of the complete crane:

  • Two touch sensors are used for the positioning.
  • Due to the weight (~1.5 kg), I have to use two M-motors (which are mechanically connected) to move the crane. One motor didn’t had enough torque. Another problem was the force on the axles when I used one motor. The motor movement had to go ‘all the way’ to the other tower. I was afraid that the axles would break due to the weight they had to move.

2. Brick 2 (in the hoist) controls the movement of the hoist and the grabber:

  • Y-movement of the hoist. The hoist is moved by an M-motor, the positioning is done by a color sensor.
  • Z-movement of the grabber. The grabber is also moved by an M-motor, the positioning is also done by a color sensor.
  • The grabber is controlled by a third M-motor.

The two bricks are connected by a flexible USB cable (Belkin) in Daisy Chain modus. This means that the two bricks are seen as one large brick. Both EV3’s are running on a rechargeable battery (all the motor movements consume lots of energy).