IoT – O Falcão

LEGO IoT Train

This post is part 1 of 3 of LEGO IoT Train

This recente release of LEGO EV3 MicroPyhton using ev3dev keeps amazing me. I think that most people didn’t realize the truly meaning of having a full modern operating system under the hood. And also the great work that David Lechner and all others (sorry, too many to name here) have been doing with and around ev3dev.

A few months ago I’ve been playing with the 4DBrix WiFi Train Controller. I already had bought some 4DBrix custom monorail parts including some small RC Servos that they sell in a LEGO-compatible form factor. When ordering a few more extra parts for my Conveyex project I noticed an interesting thing about their WiFi Train Controller – it used MQTT. Well, well, well… a LEGO-compatible RC controller that uses a non proprietary protocol and even better over WiFi, something I’ve been doing with NodeMCU but ‘out of the box’ and not too expensive.

[long dissertation]

Bluetooth and Bluetooth Low Energy (BLE) are great for gadgets but I’m still not convinced. Yes, been a beta tester of SBrick, had reverse engineered part of WeDo2, BOOST and Powered Up… but still think that BLE is not for robotics or even large IoT.

Bluetooth (standard or BLE) requires “a session”. Once a master device connects to a slave, no additional session can be created to that slave. So it’s great to keep reading data from a sensor but not to so great when you need to ‘time share’ to several masters – you need to release the session, that’s OK with SBrick because it keeps working and waiting for further sessions but it’s not OK with LEGO smart hubs because they shut off after a few seconds to save energy.

BLE beacons like iBeacon and Estimote announce all the needed data so a session isn’t needed but to save energy the frequency of the announcement is kept low. Ideally BLE devices should reduce energy consumption while waiting for a session to be stablished but that would increase latency so not so good for robotics and automation: most of the times, if you need to take a decisiona based on remote data or even worst stop a motor you cannot afford to wait.

Also Bluetooth is ‘point-to-point’, like Infra Red RC. Yes, since it’s radio it works through walls and is resiliant to room light conditions… but you cannot route it. If you have many devices to access/control you will find that there is a limit in the number of simultaneous sessions that you BLE controller can sustain (BLED112 states 8, Cambridge CSR just 5). So if you reach that limit on your smartphone or your limited tablet… you’re done. On a laptop or desktop computer you can add extra BLE dongles but then you start dwelling with your operating system idiosyncrasies (Windows guys, I feel your pain).

Now I am not saying that WiFi is the best solution as there are other very interesting wireless technologies like Zigbee and LoRa… but they are not wide spread as WiFi: my smartphone has WiFi, my laptop has WiFi, my SmartTV has WiFi… even my EV3 has WiFi!

[end of dissertation]

So I ordered one of this little fellows and it worked fine:

But I forgot to talk about it here, only wrote a post on Eurobricks forum about it. So now that I have MQTT working out of the box with this LEGO EV3 MicroPython it’s time to get back to the 4DBrix WiFi Train Controller.

4DBrix has a nice tool nControl to design train/monorail track layouts and also control them with their own controllers. It’s available for free download, you just need to give our e-mail and agree with their terms (essentially some fair use conditions including not redistributing it). There are versions for several platforms including Raspberry Pi’s Raspbian and Ubuntu. This tool is needed to configure the WiFi Controller through the USB port and also to eventually upgrade it’s firmware.

On linux, nControl looks for a connected WiFi Controller on ‘/dev/ttyUSB###’. Last year I had a problem with having more than one of this devices already defined so I needed to remove all before connect it:

sudo rm /dev/ttyUSB*

Not sure if this is still needed (4DBrix keeps upgrading the tool, it’s now in version 2019-0-409) but it doesn’t hurt.

After nControl finds the connected WiFi Train Controller (‘/dev/ttyUSB3’) we can configure it to work with our WiFi network and also chose an Alias and a MQTT Broker:

Alias: 4DB2
 WiFi Network: SSID
 WiFi Password: ****
 MQTT Broker: -> use this system => 192.168.1.87

The Alias is important because the internal MQTT client will subscribe to the topic ‘nControl/Alias’. So in my case ‘nControl/4DB2’ (I also have a 4DB1, the first Controller I received had an internal thermal problem with the power regulator so they sent me a second one).

We can specify any MQTT Broker like ‘test.mosquitto.org’ but there is also a ‘Use this system’ option where it finds the IP address of our computer and use it. That’s also usefull because nControl has its own MQTT Broker (based on ‘hbmqtt’ instead of ‘mosquitto’ and requiring authentication so not useful for open IoT projects

Although nControl as an option to verify that the applied configuration is working properly I found no way to know the IP address that the WiFi Train Controller gets so I had to go to my WiFi router and check for connected devices:

ESP_093471 192.168.1.112

The hostname starts with ‘ESP_’ (the device uses a ESP8266 chipset like the NodeMCU board I’ve been using) and got IP ‘192.168.1.112’… not that I need it’s IP address but might be useful for debugging eventual problems later

So I can now control a LEGO motor with it – disconnect USB cable, connect a LEGO battery and motor, power the device on and test it:

mosquitto_pub -h localhost -t "nControl/4DB2" -m "mot,f,1023"

the motor should spin at maximum speed in one direction. To make it spin in the opposite direction:

mosquitto_pub -h localhost -t "nControl/4DB2" -m "mot,b,1023"

And to stop it:

mosquitto_pub -h localhost -t "nControl/4DB2" -m "mot,f,1023"

or just:

mosquitto_pub -h localhost -t "nControl/4DB2" -m "mot,s"

There are a few other commands available but these are enough for what I want

So controlling a LEGO motor with EV3 through WiFi is just a matter of writing opening Visual Studio Code and write a short MicroPython script that publishes the proper messages to ‘nControl/4DB2’ topic.

Since MQTT is not ‘session’ based like Bluetooth we can use multiple Ev3 to control it. So a LEGO train can run over a long track and place several EV3 pBricks in proper places to control it, like this:

Next post I will explain how to do it and show a slightly more useful demo.

IoT with LEGO EV3 MicroPyhton (2)

This post is part 2 of 2 of EV3 MicroPython and IoT

Wrote a better script to illustrate how can we use MQTT to control multiple EV3 bricks.

On the video bellow I’m using ‘mosquitto’ commands on my Ubuntu laptop but any MQTT client (like Android MQTT Dashboard or even other EV3) can be used:

IoT with LEGO EV3 MicroPyhton

This post is part 1 of 2 of EV3 MicroPython and IoT

Just a few hours with this new image from LEGO and so much awesomeness already!

So this is all based on the MicroPython project. Being ‘v1.9.4’ it’s not the lastest version but it’s also not too old (current official release is 1.10). But it’s not ‘just’ a version customized for the EV3 devices… it seems a full implementation for ARM with ‘micropython-lib’ included.

What does it means?

Well, you can add micropyhton aditional modules if/when they are released, like for instance ‘pystone’ (a benchmarking tool):

micropython -m upip install pystone

There are already a lot of modules available including one HTTP client and other for sockets (so you can make your own MicroPython EV3 web server)… and two for MQTT!

And even better… at least the MQTT modules are already included within the LEGO image.

So let’s use EV3 for IoT:

#!/usr/bin/env pybricks-micropython

from pybricks import ev3brick as brick
from pybricks.ev3devices import (Motor, TouchSensor, ColorSensor,
                                 InfraredSensor, UltrasonicSensor, GyroSensor)
from pybricks.parameters import (Port, Stop, Direction, Button, Color,
                                 SoundFile, ImageFile, Align)
from pybricks.tools import print, wait, StopWatch
from pybricks.robotics import DriveBase

from umqtt.robust import MQTTClient
import time

def getmessages(topic, msg):
    if topic == b'JorgePe/test':
        brick.display.text(msg)

client = MQTTClient('52dc166c-2de7-43c1-88ff-f80211c7a8f6','test.mosquitto.org')
client.connect()

client.publish('JorgePe/test','Listening')
client.set_callback(getmessages)
client.subscribe('JorgePe/test')
brick.display.text('Listening...')

while True:
    client.check_msg()
    time.sleep(0.1)

Just configure Wi-Fi, connect with Visual Studio Code, upload this project… and your EV3 is IoTed!

To be continued…

MQTT on Windows

I needed to use my Windows 10 Virtual Machine to attend a workshop where labs could only be accessed from Windows operating systems (buh-uh-uh!).

So since I’m back to Windows again, let’s see if If how I can use MQTT on it.

There are two builds of mosquitto tools for Windows: one that it’s based on cygwin and another ‘native’ built with Microsoft Visual Studio

I started with the second: mosquitto-1.4.15a-install-win32.exe

Please note that I’m using a Windows 10 (x64) virtual machine, not quite full updated and it’s July 2018… things might/will change a bit after a while.

So this is x86 (win32) build but it works on x64. It just needs 3 aditional libraries (dll’s) to work:

libeay32
ssleay32
pthreadVC2

The install wizard says that the first and second library can be extracted from the light install of OpenSSL for Windows. But recent versions of OpenSSL no longer use this libraries so I had to download an older one: version 1.0.2o

So I installed this build with the option to include the libraries in the local bin folder where I went to copy “libeay32.dll” and “ssleay32.dll”. Both libraries properties had “file version 1.0.2.15, product version 1.0.2o”.

I copied these 2 files to a new folder “C:\mqtt”

Then I went to POSIC Threads for WIndows project and downloaded the 2.9.1 release and extracted “Pre-built.2\dll\x86\pthreadVC2.dll” also to “C:\mqtt”. File properties had “file version 2.9.0.0, product version 2.9.0.0”.

Then I installed mosquitto 1.4.15a on the same “C:\mqtt” folder, extracting files and configuring the service. This created a Windows Service named “Mosquitto Broker” with a “MQTT v3.1 broker” description, configured as “Automatic” but not started.

From command line, changing to “C:\mqtt” and executing “mosquitto_pub.exe” gives an error stating that another library is missing (MSVCR100.dll). This is from “Microsoft Visual C++ 2010 Redistributable Package” so I installed the x86 version.

Now the same command worked and I could also start the service (“Mosquitto Broker”).

The command line argument are the same as for Linux so

mosquitto_pub.exe -h localhost -m "0" -t sfx -r

works and if I open a second command line window I can see this message arriving:

mosquitto_sub.exe -h localhost -t sfx

Nice. Now I can use LEGO MINDSTORMS, Linux, Raspberry Pi, Android, Arduino and Windows systems on my IoT projects. If someone offers me an Apple OSX device, I’ll be a true polyglIoT ! 😀

Rock Concert IoT

This post is part 5 of 5 of LEGO Rock Concert

So last days I’ve been assembling the stage surroundings, a truss-based structure to support the left and right video walls and also the self-powered speakers:

LEGO Rock Concert: good progress with the stage and electronics

I gave up hiding the speakers under/inside the stage. I know, speakers aren’t LEGO but I think they look good enough this way.

Also I have been testing the Raspberry Pi Zero W with the PiTFT and a local USB webcam. I use ‘VLC’ to stream the webcam video to the wireless network and can show a stream on the PiTFT with ‘mplayer’. And since mosquitto-clients package is also available for Raspbian I got a way to control everything with just a bash script with MQTT.

So this is the IoT setup now:

From any mosquitto publisher I can select which stream to show on each video wall and also start a bash script on the EV3 with the sound card and the LEGO Power Function lights so a music plays while the lights blink.

Only problems till now:

‘mplayer’ takes 5 seconds to start playing the stream, doesn’t seem to be a problem with the raspberry nor with the stream, just some kind of warm-up from mplayer, if I can’t fix it will have to find another video player that works with the PiTFT (it’s framebuffer, not X-based)
a small USB endoscope camera I was considering using has some problems to show up on first boot of the Rasberry Pi so I will probably use another webcam, bigger but more reliable

While testing the IoT I used my Ubuntu laptop (‘mosquitto-pub’ and ‘mosquitto-sub’) but found a MQTT Dashboard App that works fine both on my Android 5.0 Phone and my Android 4.0 tablet. But I also wanted to use an EV3 as a controller so I tested a few bash scripts with the local keys but found it too limited… so decided to make a better control panel:

The four medium motors are used as selectors, I divided a whole rotation in 8 intervals (45º each) to have 8 options on each motor. So it works like this:

– one selector for Video Wall #1

– one selector for Video Wall #2

– one selector for Sound and Lights

– one selector for Special Effects

I can choose what stream I want to show on each video wall and start playing a music. Later I will add more options (photo presentation, youtube video…) and use the 4 EV3 touch sensors to adjust parameters for each option (like the brightness, the frequency or the effect of the lights, the volume of the sound, forward/backward while showing some presentation…).

A video explaining this:

I speak in english but my voice is weak and I had an allergic caugh in the middle so I added sub-titles (also in english).