The last bits and pieces of the hardware and software integration

Help ...In the last weeks, we have worked hard to integrate the hardware and the software. Just like a real project, we had some unexpected failures. In this article, I will mention a couple of them.

Daisy Chain mode works fine… as long as you don’t use WiFi

When I build the Candy Crane, I used two EV3 bricks for controlling the movements. The EV3 were connected by a USB cable in daisy chain mode. The EV3 program runs on the first brick and is able to control the sensors and motors of the second brick. This is very useful, since the PC application can treat the crane from a functional point of view, as one object. Another advantage is, that some of the movements of the crane can be blocked based on the sensor states without bothering if a sensor is connected to the first or second brick. For example, the crane motors (connected to brick 1) will not run if the grabber position sensor (connected to brick 2) is in the lower position. If this check wouldn’t be done, the grabber would hit the wagons with possible disastrous consequences.

Just after building, I tested the crane at home with a test PC application and a Bluetooth connection. And everything went fine.

Then we went to the integration phase. Since a Bluetooth connection is less reliable then WiFi, all the EV3 bricks would be connected by this protocol. Last week, we started the integration of the Candy Crane. The special designed wireless protocol (see my article about the problems with the WiFi) was added to the EV3 code. The PC application was ready for test. Just one thing was needed: inserting the WiFi dongle to the first Candy Crane brick… Uhm…. I said…. the USB port is already occupied by the cable that connects the second brick. And the firmware is probably not smart enough to use the USB port of the second brick for the WiFi dongle….

Daisy Chain + WiFi, is that working?And, as expected, the sketched solution is not working. The only solution to this problem was (apart from writing our own EV3 firmware ;-)) too split the Candy Crane in two separate bricks.

The second brick had to be turned to make it possible to insert the WiFi dongle, that was the easy part. Splitting the EV3 code in two pieces and rewriting the PC application was more time consuming. And don’t forget, that the intelligence about the crane movements had to move from the EV3 code to the PC application. With a tight deadline, these kind of unforeseen activities are very stressful. But we managed to rewrite everything (most of this coding is done by Dwight Berendse), testing was successful, uploading the code to Git. Another activity done.

Let there be light!

Another ‘stupid’ problem with the Candy Crane. As said in the previous section, I tested the Candy Crane at home. And it worked fine, the hoist stopped at the desired positions using a color sensor and marked positions (white, yellow, blue, green, red). During the integration at our office and after splitting the code in the two bricks, the hoist didn’t stop correctly anymore. Since we had just split the code amongst the two bricks, we had probably done something wrong. And indeed, some problems were caused by the split. For example, it you remove the ‘check’ of the Daisy Chain Mode, the sensors that were previously configured as ‘Sensor 1 of Brick 2’ remain configured although there is no ‘Brick 2’ anymore. You have to reset all the configurations by hand!

But even after this reconfiguration, the hoist wasn’t stopping at the correct positions. When we debugged the code, I noticed that the colors were not correctly seen… one of my colleagues mentioned that it might be the fluorescent tube that we use in our office. And indeed, with a piece of tape we made a simple cover to prevent the incoming light to influence the sensor readings. And yes, that worked fine. Of course, the tape was just a temporary solution. The light cover has now been made by Lego:

Sioux.NET on Track - Candy Crane - Light Sensor CoverClockwise or Counter-Clockwise, that is the question?

The UI team (Matthijs van Bemmelen and Guido Josquin) is writing the component to show on the monitor where the train is running on the layout. Their assumption was that the train runs clockwise. A very logical assumption, if you look at the track layout. You expect the train to run clockwise so it can easily enter the marshaling yard.

Train LayoutDuring the integration, they noticed ‘hey, the train is running in the wrong direction’. Indeed, the train runs counter-clockwise. It will run backwards to pickup the wagon in the marshaling yard. They could have put the monitor in reverse mode. But that would not be a nice solution, not to mention that all characters would be mirrored. And of course, they did the right solution and rewrote the code.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s