The first MINDSTORMS programmable bricks, the RCX, had several “incarnation”. Most people remember the yellow brick but there were several others, including the Code Pilot that used light sequences as commands. Those VLL codes could be printed as barcodes:
and the Code Pilot set had a companion sheet with some codes and also key notes that could be used as a barcode piano.
So let’s try a simple set of instructions:
The barcodes are just EAN-13 code generated online from EAN-13 barcode generator. They all start with ‘560’ (the code for Portugal-based companies) and the remaining 12 digits are just 1/2/…/5 left padded with zeros. The last digit is the checksum code and is generated by the tool.
So my first program uses a nested dictionary with the EAN-13 codes paired with an action to be spoken. So the program waits for a barcode to be read, checks for the action to be spoken and execute the action we chose:
Should be finishing my EV3 Alexa program… but not in the mood.
So I got a USB barcode scanner in front of me… hmm, I wonder…?
My Ubuntu linux laptop recognizes. HID device, a keyboard. Great, plug and play!
So does my EV3 running ev3dev:
[ 538.808906] usb 1-1.2: new full-speed USB device number 6 using ohci-da8xx
[ 538.972308] usb 1-1.2: New USB device found, idVendor=04b4, idProduct=0100
[ 538.972383] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 538.972425] usb 1-1.2: Product: USB Virtual PS2 Port
[ 538.972462] usb 1-1.2: Manufacturer: Future
[ 539.040788] input: Future USB Virtual PS2 Port as /devices/platform/soc@1c00000/ohci-da8xx/usb1/1-1/1-1.2/1-1.2:1.0/0003:04B4:0100.0001/input/input2
[ 539.128526] hid-generic 0003:04B4:0100.0001: input,hidraw0: USB HID v1.00 Keyboard [Future USB Virtual PS2 Port ] on usb-ohci-da8xx-1.2/input0
So if this is a keyboard I can read it with input functions:
#! /usr/bin/env python3
# if you are running from ssh session invoke this script with 'brickrun'
from ev3dev2 .sound import Sound
sound = Sound()
ucc = input('Scan a UCC: ')
ucc = ucc.lower().strip().replace('\t','').replace('\n','')
Yes, it works. Just need to disable Brickman interface (first time I ran it the ‘keys’ read from from the scanner disabled my Wi-Fi connection). I can use print but the since the LCD is so small I prefer to use ‘speak’.
Now… what can I do with it?
Of course… identify LEGO sets!
So I found out that there are online databases of barcodes and some even offer webservices API. I asked a free trial key at “https://www.barcodelookup.com/api” and copy&pasted their python demo code… and it just works.
It’s Easter time so I’m considering organizing a workshop with my LUG to show them The Light of Ev3 MicroPython 🙂
I already have a few microSD cards that I can share but will probably need some Wi-Fi dongles (no way I’ll ever teach a bunch of Windows-addicted guys how to use USB or Bluetooth on their first contact with Ev3 MicroPython).
My local robotics store has no more Edimax dongles so I went after another Asus USB Nano, it works fine with ev3dev (I think it even works better than the Edimax but if I want to switch to LeJOS or Ev3-G I prefer to have the Edimax with me as it is officially suported by LEGO).
Didn’t find the Asus but got a TP-Link “Wireless N Nano USB Adapter” (TL-WN725N) and it also seems to work fine.
usbcore: registered new interface driver r8188eu R8188EU: Firmware Version 11, SubVersion 1, Signature 0x88e1
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.
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:
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:
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.