Skip to main content

Evolution of the DesignSpark Useless Machine 2

tubing01_%282%29_d621cfab91d788a8a1506f5cd645274df6b5545c.png

Titan22_d593517897b399e319bb0fe62544afbd7891c9ac.jpg

Remember DesignSpark‘s Useless Machine 2 (UM2) shown at the UK WNIE show? Maybe you read the UM2 articles first if you have missed them. So what was the UM2 all about? We’ve designed a crossover demonstration of traditional automation combined with Python, openCV, NodeRed and an MQTT cloud connection. When the machine was packed for the embedded world show in Nuremberg in February, we detected cracked acrylic containers. As we wanted to create a fantastic new exhibit for the RS Titan II Truck, we decided to design the Useless Machine 3, getting rid of the problems with UM2 we’ve learned from. So let’s see what is new with the UM3:

 

Containers and tubes

20200715_154924_%283%29_2d669d7144bb0926522ac270f7c561b091c68474.jpg

On the surface, it could seem that a glass container might crack easier than an acrylic container. But the truth is, that acryl glass cylinders suffer from inner tensions. Especially if they have threads like the ones we’ve used in the UM2, overwinding is a high risk for the material and will end up in creeping cracks. But also chemicals like cleansing alcohol can cause hair cracks. The transport of this massive exhibit seems in our case to be the reason for mechanical forces which caused the material's inner tensions to be released in cracks. Having the exhibit in the RS Truck would be a life full of transport. So we modified the tubing and cylinders completely. Borosilicate glass is immune to vibrations and mechanical stress up to a high level. So the big cylinders are now made of this material. The tubing was simplified from its mystic 3D bent form to straight and L-shaped PETG tubes only. PETG tubes are more flexible than borosilicate glass or acrylic tubes. PETG is also resistant against chemicals like alcohol. Using the simple 2D layout and more flexible tubes was our way to get rid of problems with vibrations or shearing forces.

alphacool_2_6d6855c6d30d63afa9c9bd9065bb1377be593a8c.png

I need thank again Alphacool who sponsored pumps, fittings, tubes and other material. Whenever you need to cool your server professionally, have a look at their one of the art equipment.

Ambient light conditions and show lighting

20200715_161200_%282%291_aeee44007d287b0b6c6d2aa8a4169e4f36679ac2.jpg

The UM2 was built to be shown on a trade show booth. We wanted it to be visible from all sides to attract people passing the booth. But the UM3 is inside a truck and thus cannot attract people from outside. So we had the freedom to build it much more resistant to changing ambient light. The UM3 is constructed to be viewed from one side only. The other three sides, as well as the bottom and ceiling, do form a consistent black background. These are perfect conditions for openCV picture analysis. We also placed the blinking and colour changing show lighting in such a way that it no longer interferes with the level detection. Additional lights were placed on several positions to allow a maximum colour contrast of the fluids against the background. We used red oil and green water again, and the water colouring was UV active as the one used in the UM2.

USB Cameras

20200715_161259_%283%29_9c04b5c6886315142779e0c7d289769bd387d909.jpg

We used a low priced USB webcam for the UM2. Although the resolution and overall optical quality was good enough, we had massive problems with the Linux driver. There was no chance to switch off automatic white balancing and to manually adjust the gain although the driver should allow doing so. As the Chinese manufacturer did not offer any reliable support, we ended up with a big problem: switching on the illumination of the tubes and containers changed the camera pictures dramatically. Especially the UV LEDs for the fluorescent green fluid caused the camera colours to go wild. But without reliable and reproducible colour values in the camera frames, we could not reliably detect the fluid levels (which was the main task for the cameras). So we needed to switch off the lights, wait for the camera to relax and then take some frames to detect the fluid levels. Of course, the valves needed to be closed during the waiting periods. So we painfully had to learn that we should better turn to a reliable European manufacturer of industrial-grade cameras.

ids-logo1_1fdba789ad78cc666e723ef2e442395f86f7d964.jpg

IDS from Germany was our choice. Their uEye series combines excellent parameters with reasonable prices. We decided to use two uEye XS cameras. Using two cameras allowed us to reduce the camera to object distance by having separate cameras for the left and right containers. When we explained our project to them, they even sponsored the two cameras! IDS has developed a complete Python library for their uEye cameras. So integrating the cameras into our Python controller gave us the total control over all camera parameters, including an electrical focus setting. And their support was more than helpful.

Two controllers with M2M communication

20200715_154954_560_a34fe96290d9d56ec4f87c7b5eb47faff1da5232.jpg

20200715_155006_560_1665c7bc6e188aaa540419d116f50d1558cda836.jpg

As I have mentioned, we faced problems with both cameras running on a RevPi. From time to time, after some hours of running, the operating system was freezing without any error message or error log. We tried to run the openCV software for the two cameras on an original Raspberry Pi 4 and thought to get rid of the problems. But the higher computing power only stretched the error-free interval by a factor of two. As the errors vanished when we reduced the USB system load by running both cameras with 11 frames/second instead of originally 15 Frames/second, we thought we better stay with two systems and make an attractive feature out of a problem (read this article):

  • The RevPi as a PLC, controlling the pumps and valves and collecting the button states.
  • The Raspberry Pi 4 as a camera-based sensor, sending its picture analysis results to the RevPi process image.

This combination entirely separated the tasks and is an excellent example of M2M communication in automation systems. As with the UM2, we used again Sven Sagers “RevPiModIO” library which, when installed on multiple systems, allow complete virtualisation of the process image. So our openCV application running on the Raspi 4 writes the calculated fluid levels into a process image which resides on the RevPi. It uses Unix sockets to communicate over a local Ethernet network.

At the end of the story, we found out that the problems had been caused by a bug in the original Raspberry USB driver modifications which had also been part of the RevPi Debian system: The system gets trapped in an endless IRQ service routine loop when heavy USB traffic causes massive IRQ load, and an IRQ hits the system in a critical period. Thanks to the Debian kernel expert Lukas Wunner from KUNBUS, this bug could be found and verified. It is no longer existent in the current RevPi image, and the Raspberry foundation also corrected their Debian images.

Light controllers

20200715_155633_%282%29_560_eb0a442b1efa894113c19c0f92cfdc1d615e2f66.jpg

The RevPi IO modules use a 4 ms bus cycle to get their data into the RevPi’s process image. This would be far to slow for beautiful moving light effects with the over 300 digitally controlled RGB LEDs. So we are using three separate Teensy 4.0 controller with Ethernet shields to run the three WS2812 LED stripe busses. These controllers are Arduino based, and you get most of the code from open source libraries. All three Teensy systems are controlled via Modbus TCP from the RevPi PLC. The PLC tells them to start, stop or freeze the light effects for separate locations of the UM3.

But watch our video to get an impression of these light effects.

The video screens

20200715_161124_%284%29_822c31d88327a363a0f8e9df06f90ec6d8b12510.jpg

We have used an 11” monitor to visualise the camera pictures and openCV calculation steps and results. So this monitor is directly connected to the Raspi 4. It also shows some values from the RevPi process image. As I have already explained, the Raspi has complete access to the RevPi process image. The final minute of the video shows this monitor content during the pump-in-phase.

Another 24” monitor on top of the exhibit is used for promotional videos which are looped by another Raspi 3 system.

Want to know more about the construction?

Leave a comment with your questions, and I will provide all the missing information. If you are using DSM, you can also download the complete design file here.

um3_base_1_5243903b02d2a97cf3195c9a6dcb63b735face8f.png

I hope you enjoy this new Useless Machine 3. Due to the COVID-19 pandemic, we are currently unable to give you a schedule of locations where the RS Truck will be during the rest of this year. But we all hope it will be on the road again soon. And hopefully, you will quickly get a chance for a live impression of our UM3.

If you like to book the Titan II for an event or visit, please use this contact: education@rs-components.com

Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and analogue electronics for neuroscience labs (and his MD grade). Later: database engineering, C++, C#, industrial hard- and software developer (transport, automotive, automation). Designed and constructed the open-source PLC / IPC "Revolution Pi". Now offering advanced development and exceptional exhibits.
DesignSpark Electrical Logolinkedin