The documentation states that it uses a ‘pybricks-micropython’ environment and new ‘pybrick’ library, not yet available outside of this image but that’s just a matter of time.
Micropython programs tend to use less resources than common python and also start much faster. The ev3dev-lang-python is still included on the image but for simple projects this new micropython environment will be of great use for people starting with EV3 and text-oriented languages.
The image is really a full ev3dev stretch-based image, the ‘robot’ user is still available (password is “maker”) so we can still access through SSH and use it the way we were used:
Kernel is very recent but there is already a newer version available – since LEGO keeped the link to ev3dev repositories so the usual ‘sudo apt update’ and ‘sudo apt upgrade’ works:
The following NEW packages will be installed: linux-image-4.14.111-ev3dev-2.3.3-ev3 rtl8188eu-modules-4.14.111-ev3dev-2.3.3-ev3 rtl8812au-modules-4.14.111-ev3dev-2.3.3-ev3 The following packages will be upgraded: jri-11-ev3 libnss-myhostname libnss-resolve libpam-systemd libsmbclient libsystemd0 libudev1 libwbclient0 linux-image-ev3dev-ev3 samba-libs systemd systemd-sysv udev wget wpasupplicant
By the way, micropython says:
MicroPython v1.9.4 on 2018-05-22; linux version
Use Ctrl-D to exit, Ctrl-E for paste mod
Just a few days after SPIKE anouncement, the future of LEGO robots seems now to be very very linked to linux, python and opensource
Been testing the micro:bit BLE Uart service. It’s a service that uses Nordic chipset features to deliver a simple TX/RX mechanism so we talk with the micro:bit without having to create our own BLE services.
Someone offered me a ultrasonic sensor this week. It’s a HC-SR04, very common with Arduino projects but can also be used with the micro:bit, there’s even a “sonar” extension available in the Makecode editor.
So I added the BLE Uart service and started writing the distance values to the TX characteristic every second:
Nordic nRF Connect App reads them fine but gatttool doesn’t… except when in Interactive mode. Strange!
After a while, I found out a note that explains that the way the TX characteristic works forces us to keep the connection or reset the micro:bit regularly. That’s why Interactive mode works (it keeps the connection). So I have to forget gatttool for a while and use something better like python.
On Ubuntu, my scripts worked fine. Latest version of pygatt (4.0.3) allow me to subscribe to the TX Characterist (in “Indication” mode only – almost the same as notifications but with an extra acknowledge step) and I was getting distance values on my laptop through BLE.
But on the EV3 the scripts failed because “No characteristic found matching”. Why? I’m using same version of pygatt and don’t think that kernel version make much difference now that pybluez has settled.
I was almost giving up when something worked: decided to use the python exception mechanism to retry several times the subscribing step.
Almost 2 and a half years ago I bought a BBC micro:bit, planning to give it as a xmas present to my geek nephew. Unfortunately (for him) I decided that he wasn’t geek enough for this small ARM-based controller as I found out it was too confusing to set it up properly for BLE usage.
At that time I managed to get EV3 working with it but it was very awkward. Most of my problems were related to making a proper connection because the firmware required BT to be paired before accepting BLE commands but I also had problemas with the python BLE library I was using (gattlib).
This weekend I had a long day at work upgrading some Microsoft servers and had the time, between downloads and reboots (argh!) to return to this little fellow. So I found out it is now much, much easier to configure it… thanks to Microsoft! Yes, same Microsoft.
I used Makecode Editor to configure my micro:bit from a browser: just added the Bluetooth extension, included th e Bluetooth blocks that activate the proper BLE services and enabled using BLE without the need to pair BT first.
On the ev3dev side it was also easy to use it with python but with a different library: pygatt.
Interestingly, a new version of pygatt was released this very same weekend.
Today I got a nice note from a guy named Kevin Walters. He used my mindstorms-vll code to control a MINDSTORMS MicroScout droid with a smarphone, using an Adafruit Feather M0 Bluefruit LE running CircuitPython 3.1.1 as a gateway controller:
I like Star Wars but usually don’t care for LEGO Star Wars sets. But when the Conveyex set was released I liked it a lot. Probably because it looked like a monorail train and I was already gathering a few old LEGO monorail pieces. So I ordered one… or so I tought.
When I order from LEGO I take the chance to buy a few MINDSTORMS motors and some Power Function elements like cables or batteries. I had a few items already on my desired list so I didn’t notice exactly how many items I was ordering… and so I received 3 (three!) Conveyex sets.
Oh boy. What I am going to do with all these Conveyex?
Then I realized that the size of the set wagons is simillar to the monorail wagons. After assembling the first set I took off the wheels and with just a few extra bricks I got my first monorail version:
Since I was already trying to use Powered Up as a way to control the monorail motor it seemed natural to extend this first version to a bluetooth controled one:
This way the Conveyex could be controlled not just with the Powered Up train headset but also programmatically. That would allow me to use the Conveyex on a large animated diorama, with MINDSTORMS and other controllable elements:
So this was the beginning. Now I “just” needed to extend the train with a few more wagons. And the rail with a few more tracks. Seemed simple.
But the old LEGO monorail system wasn’t meant for long trains. The system was designed for just 1 engine in the middle and 1 wagon at each side:
The wagons connect to the engine through a custom coupling system. As far as I know, there is no way to connect other LEGO elements to the engine couplings. Extending the length is possible by adding wagons and using some LEGO parts as custom couplers, like in LEGO trains.
Fortunately there is a company named 4DBrix that sell a few custom elements compatible with the monorail system. I ordered them some car extensions that has a “male” tab that connects to the engine and a “female” socket that allow extra wagons to be added. It worked but then the overall weight started to be feel too demanding for the monorail motor. Perhaps a single motor could move a train with 2 or 3 wagons and an engine but I also wanted ramps (of course!) and that seemed too much. So I wondered if it is possible to use more than one monorail motor…
The monorail track is really just a long gear. So the two motors are directly coupled together and just add their force (oh well… after a while I found out that this is not always true).
But the way that the Powered Up Hub was designed it is not the best for such a setup – the 6x AAA batteries would drain too fast and I would have to remove the Hub to replace them. Once in a while it might be acceptable but certainly not every 30 minutes. The good old Power Functions LiPo battery is much better – it allows in place recharging and it also looks like it can supply a few more milliamps than the PUP Hub (not confirmed).
So I picked my LEGO relay idea and built a Powered Up version:
and then applied it to the Conveyex:
So now the Powered Up Hub batteries are only used to keep the Hub ON and sometimes to change the relay state. Need to measure it but I suspect that it would work a few hours. And no custom cable is used, just 100% LEGO electric parts.
So today the Conveyex is already looking good:
The model uses 2 monorail motors, 4 wagons and an engine car:
From left to right:
Powered Up Hub wagon
Power Functions LiPo battery wagon
still no purpose wagon
So the Conveyex is really just 2 monorail trains linked together (in the above drawing, the extra space reflects the custom coupling I had to build, longer than the monorail coupling sustem). The wagons aren’t all of the same size because the wagons length from the LEGO Conveyex are in facto a bit too larger and make the monorail derail at regular curves and ramps – so I built the Relay wagon 4 studs shorter.
The weight is not equally distributed, the front train is lighter than the back train. So sometimes, when the Conveyex is moving on ramps, the two trains move at different speeds – like when the front train already reached the top and the back train is still moving up in the ramp:
On the video above the LiPo was adjusted for 4/7 of output power. The front train gained too much speed and the monorail coupling couldn’t handle and disconnected. Now I’m running the Conveyex with the LiPo at 5/7 of output power and this never happened again but probably will need to add more weight to the “still no purpose wagon”… crazy ideas welcome 🙂
I needed a way to turn a LEGO motor ON and OFF using a Powered Up hub but keeping power supplies independent. This way I can control a large current demanding motor without draining out the Hub batteries (and also without the need to use a custom cable).
So I used a Power Functions switch as a relay:
Also took the chance to try LDCad on linux. Not so easy to use as LEGO Digital Designer (I am a zero with CAD) but after a while I got a pretty close model. To create a PDF with the instructions I then used LPub3D – I couldn’t install the ‘.deb’ file because of missing dependencies no longer available for my Ubuntu laptop but found out that the ‘.AppImage’ works fine.
The instructions on this PDF file also have a list of the parts that I needed to get from LDView (LPub3D generates a nice image with all the parts but without describing those parts). I also couldn’t install the ‘.deb’ version so I used the ‘.exe’ for Windows, it runs fine with Wine.
The model uses a Powered Up / WeDo 2 motor but it can also use a Power Function M motor or a MINDSTORMS medium motor so this relay may use with different technologies (IR, Bluetooth, Wi-Fi, USB) as long as you just need an ON/OFF control of the motor.
Using a Power Functions LiPo battery you can still regulate the output power
A video of the relay working:
And another showing how I use it in my LEGO Imperial Conveyex Transport based on the old LEGO monorail system:
Big thanks to Roland Melkert, Trevor Sandy, Travis Cobbs who designed these great open source tools (and probably many others who contributed).
BT works, just needed to edit ‘/sys/module/bluetooth/parameters/disable_ertm’.
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: HIDP socket layer initialized
hid-generic 0005:045E:0B0C.0002: unknown main item tag 0x0
Bluetooth: received HCILL_WAKE_UP_IND in state 2
input: Xbox Adaptive Controller as /devices/platform/soc@1c00000/serial8250.2/tty/ttyS2/hci0/hci0:1/0005:045E:0B0C.0002/input/input3
hid-generic 0005:045E:0B0C.0002: input,hidraw1: BLUETOOTH HID v9.03 Gamepad [Xbox Adaptive Controller] on a0:e6:f8:60:16:60
I don’t have a ‘/dev/input/js0’ because ev3dev ‘joydev’ has been deprecated.
But I can still read it with ‘cat /dev/input/event3’ but since it looks like garbage its better to use ‘evtest’:
Event: time 1538574732.484613, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1538574732.484613, type 1 (EV_KEY), code 304 (BTN_SOUTH), value 1
Event: time 1538574732.484613, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90010
Event: time 1538574732.484613, type 1 (EV_KEY), code 319 (?), value 1
Event: time 1538574732.484613, -------------- SYN_REPORT ------------
Event: time 1538574732.574441, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1538574732.574441, type 1 (EV_KEY), code 304 (BTN_SOUTH), value 0
Event: time 1538574732.574441, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90010
Event: time 1538574732.574441, type 1 (EV_KEY), code 319 (?), value 0
Event: time 1538574732.574441, -------------- SYN_REPORT ------------
So it is a bit less easy than with Ubuntu but we’ll get somewhere.
XAC working with bluetooth on my Ubuntu 18.04 laptop.
Only needed to edit ‘sys/module/bluetooth/parameters/disable_ertm’ replacing ‘N’ with ‘1’ or ‘Y’
After a few attempts of pairing my connection kept stable.
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: HIDP socket layer initialized
hid-generic 0005:045E:0B0C.0006: unknown main item tag 0x0
input: Xbox Adaptive Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/bluetooth/hci0/hci0:256/0005:045E:0B0C.0006/input/input23
hid-generic 0005:045E:0B0C.0006: input,hidraw3: BLUETOOTH HID v9.03 Gamepad [Xbox Adaptive Controller] on 34:f3:9a:88:60:7a
Bluetooth: hci0: last event is not cmd complete (0x0f)
a lot more of those hci 0x0f errors will keep appearing but connection holds.
Also got a ‘/dev/input/js0’ device but with much more Axles (15) and Buttons (31). But buttons seem duplicated – for instance the big round button ‘A’ is both Button 0 and Button 15 (previously it was only Button 0).
Note 1: this workaround is not permanent.
Note 2: according to wikipedia, ERPM stands for ‘enhanced retransmission mode‘ and is ‘an improved version of retransmission and flow control modes’. Several posts related to using Xbox bluetooth controllers in linux suggest disabling it.