Now that more and more people are using ev3dev thanks to LEGO Education’ EV3 MicroPyhton a few might find in need to change their bricks’s names.
Until that feature is available at BrickMan level, this is the a way:
access the ev3dev shell either through SSH (puTTY) or Visual Studio Code – don’t forget that the default user is ‘robot’ and it’s password is ‘maker’
change te hostname with command ‘sudo hostnamectl set-hostname NAME’
restart avahi service with command ‘sudo service avahi-daemon restart’
David Lechner pointed me to the ‘ev3dev-config’ tool having also an option for this purpose:
sudo ev3dev-config
Then choose
4 Advanced Options Configure advanced settings
Followed by
A1 Hostname Set the visible name for this ev3dev device on a network
This can all be done from Visual Studio Code through the EV3DEV Device Browser plugin – I wrote a detailed visual explanation for those less confortable with above explanation.
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.
dmesg:
usbcore: registered new interface driver r8188eu R8188EU: Firmware Version 11, SubVersion 1, Signature 0x88e1
Yesterday LEGO Education quietly released “Python for EV3“:
You can now use your EV3 Brick to unleash the power of Python programming using MicroPython. Simply install the EV3 MicroPython image onto any micro SD card and boot up your EV3 Brick from it to start programming straight away.
What it really is: a full ev3dev image with a micropython environment meant to be used from Visual Studio Code through an EV3 MicroPython extension.
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:
robot@ev3dev:~$ micropython
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
A great milestone has been achieved with ev3dev-browser, an ev3dev extension for Visual Studio Code:
You just need to install Visual Studio Code, press Ctrl+P and past “ext install ev3dev-browser”, install the ev3dev-browser (currently 0.1.0 by David Lechner) and reload the IDE window.
If you have also a python extension installed and you have something running an ev3dev stretch image (2017-07-25 or newer) it will appear on the left-bottom corner pane of the IDE (“EV3DEV-DEVICES”) and you can transfer your python script to it, run them, open an SSH session…
ev3dev based on Debian Stretch is still in development (so not stable yet) but I have great expectations that we all can use it soon.
Os meus primeiros 3 módulos MFL (Módulo Ferrovia LEGO) junto dos restantes módulos da PLUG no Tomar BRInCKa 2015:
O módulo ao centro tem dois desvios motorizados, bem como um «desengatador» no troço de recta entre as duas agulhas. Toda a electrónica está disfarçada por baixo das linhas.
O módulo da direita consiste numa plataforma rotativa motorizada e controlada por um LEGO Mindstorms EV3 correndo ev3dev (uma variante de Debian para o EV3). Sobre o carril um pequeno comboio controlado por SBrick (bluetooth).
O módulo da esquerda, quase 100% da minha marida, começou com uma pequena cascata no nosso presépio do Natal anterior.
A montagem no BRInCKa 2015 não ficou completa por isso todas as demonstrações são manuais, controladas por mim. Neste video gravado em casa é o computador (LEGO Mindstorms EV3) a fazer tudo sozinho:
O que faltou montar e que permite a automação plena? As componentes RFID – por baixo do pequeno comboio há um identificador RFID do tamanho de uma moeda que permite identificá-lo e em certa medida seguir-lhe a posição. Na montagem do video existem dois leitores RFID (USB) por baixo da linha (um no extremo direito e outro junto ao sistema de desengate). O EV3 utiliza esses sensores para perceber se o comboio está nos sítios certos antes de passar à acção seguinte.
Nesta primeira semana de experiências com o ev3dev utilizei sempre o mesmo cartão microSD (um Kingston microSD 2GB penso que classe 4). Os tempos de arranque (desde o carregar no botão de power até ao primeiro ‘ping’) foram sempre de 60 segundos, não é muito mau comparado com o tempo de arranque do EV3 com o firmware LEGO por isso não me preocupei em experimentar outros cartões.
Mas hoje lembrei-me de ter visto alguma utilização de swap e já que as operações de update são longas (mais de 10 minutos só para actualizar o catálogo com ‘apt-get update’) podia ser que a coisa melhorasse com um cartão mais rápido.
Os tempos de arranque desceram de 60 segundos para 50 segundos, nada mau. E a actualização do catálogo (‘apt-get update’) passou para ligeiramente menos de 8 minutos. Não é um ganho espantoso mas se estiver a trabalhar com pilhas ou baterias em vez de regulador DC já é qualquer coisa.
Como o novo cartão é de 4 GB em vez de 2 GB posso aproveitar o novo espaço extendendo o file system. Podia tê-lo feito de dentro do próprio ev3dev mas ainda não domino muito a linha de comando por isso fi-lo em 3 fases:
Colocando o cartão no meu Ubuntu e utilizando o Gparted para criar uma nova partição do tipo ‘lvm2 pv’ com os 1906 MB livres no cartão
Ainda no Ubuntu usando o system-config-lvm para adicionar a nova partição ao Volume Group já existente
Voltando ao ev3dev e extendendo o Logical Volume ‘root’:
A utilização básica do LEGO Mindstorms EV3 com ev3dev fica completa com a utilização de motores.
Ligando um motor (45503 EV3 Medium Servo Motor) na ficha A, o sistema operativo acusa o evento:
root@ev3dev:~# dmesg
(...)
tacho-motor tacho-motor0: Tacho motor registered.
ev3-tacho-motor outA:motor: A Tacho Motor connected to port outA gpio 91 irq 192
Uma vez mais é necessário consultar a wiki do projecto ev3dev para entender como aceder aos motores. Estes também são mapeados pelo sistema operativo, desta vez em “/sys/bus/legoev3/devices/” e em ” /sys/class/tacho-motor/”:
Agora é ‘sensor1’ em vez de ‘sensor0’. Talvez a troca tenha sido demasiado rápida ou talvez o sistema operativo nunca liberte os mapeamentos efectuados [até ao próximo boot].
A informação disponível é semelhante:
root@ev3dev:~# ls /sys/class/msensor/sensor1
bin_data dp num_values subsystem units value2 value5
bin_data_format mode port_name type_id value0 value3 value6
device modes power uevent value1 value4 value7
E a leitura do estado do sensor funciona da mesma maneira através de ‘value0’.
Este forma do sistema operativo mapear todos os dispositivos no file system dá-nos uma enorme flexibilidade – todas as linguagens de programação permitem aceder a ficheiros… até a própria shell! Eis shell script que se limita a esperar que o sensor seja premido:
#!/bin/bash
BOTAO=0
while [ $BOTAO -ne "1" ]; do
BOTAO=$(cat /sys/class/msensor/sensor0/value0)
done
echo "Ouch!" > /dev/tty0
se o ficheiro contendo este script se chamar ’touch.sh’ e tiver permissões de execução podemos invocá-lo directamente da linha de comando:
Nota: usei aqui ‘sensor0’, assumo que há apenas um sensor e excepto na situação acima em que retirei um sensor e adicionei outro que por isso ficou ‘sensor1’, será sempre ‘sensor0’.
Usando o ev3dev há duas formas de aceder ao LCD do LEGO Mindstorms EV3:
modo de texto: terminal via /dev/tty0
modo gráfico: framebuffer via /dev/fb0
Ambos os modos estão ainda a sofrer desenvolvimentos mas o segundo modo é seguramente o mais complexo pelo que fico-me por enquanto só pelo modo de texto.
Assim para escrever qualquer coisa basta por exemplo redireccionar o comando echo para /dev/tty0:
echo "Hello world!" > /dev/tty0
Já é qualquer coisa mas para limpar o ecran sem ter de enviar vários “echo” existem formas melhores. Sendo um terminal tty convencional, a maioria dos comandos para terminal devem funcionar (inclusive algumas sequencias de escape). Experimentei o tput:
Para limpar o ecran:
tput clear > /dev/tty0
Para posicionar o cursor:
tput cup linha coluna > /dev/tty0
(tput cup 0 0 envia para o canto superior esquerdo e já agora com tput cols ficamos a saber que o LCD tem 44 colunas)
Para escrever branco sobre negro:
tput smso > /dev/tty0
Para voltar ao negro sobre branco:
tput rmso > /dev/tty0
Muito bem, já escrevo o que quiser em qualquer lado do ecran… mas a fonte é tão pequena que só com uma lupa é que se lê. Como aumentar o texto?
A primeira hipótese que me ocorreu foi instalar o figlet que usa caracteres ASCII para fingir fontes maiores:
mas é uma forma um bocado coxa. O melhor mesmo é poder trocar o tamanho dos caracteres e para isso existe o comando “setfont” que felizmente já existe no ev3dev e disponibiliza umas quantas fontes em “/usr/share/consolefonts/”, vejamos só quantas há na variante Lat15 (que serve à maioria das linguas ocidentais incluindo a nossa):
Depois de ter Wi-Fi decidi testar mais alguns dispositivos USB que uso com o Raspberry Pi.
Para começar, uma vez que o EV3 apenas tem uma porta USB, imprescindível um hub, de preferência pequeno:
Hub KUNFT 4 Portas USB 2.0 H-088 (na Worten por €6,99)
Com o EV3 ainda desligado liguei-o e a ele o dongle Wi-Fi (ThePiHut).
Da primeira vez não obteve rede, não sei se não esperei tempo suficiente. Retirei o hub, liguei novamente (sem o dongle Wi-Fi) esperei um pouco e depois liguei o dongle e desta vez obtive rede. E a partir daqui cada boot/reboot com tudo ligado funcionou sempre bem.
root@ev3dev:~# lsusb
(...)
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Agora o audio:
[Nota: o EV3 já tem uma placa de audio interna, suportada pelo ALSA, e um altifalante interno também. Mas tanto quanto percebi funciona de modo semelhante ao jack audio do Raspberry Pi, por PWM, consumindo CPU… além de ser mono e não permitir ligação externa a um amplificador]
DIY USB to Audio Module for Raspberry PI / Arduino / MAC / PC + More – Green (SKU 315287 na DX – DealExtreme, US$10.88)
root@ev3dev:~# dmesg
(...)
input: Burr-Brown from TI USB Audio DAC as /devices/platform/ohci.0/usb1/1-1/1-1.4/1-1.4:1.2/0003:08BB:2704.0001/input/input2
hid-generic 0003:08BB:2704.0001: input: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC ] on usb-ohci.0-1.4/input2
(...)
root@ev3dev:~# lsusb
(...)
Bus 001 Device 004: ID 08bb:2704 Texas Instruments Audio Codec
(...)
E para tocar um ficheiro mp3 (previamente trasnferido por ssh):
root@ev3dev:~# apt-get install mpg321
root@ev3dev:~# mpg321 -a hw:1,0 Thunderstruck.mp3
Rock’n Roll!!!
Durante a execução o mpg321 consome entre 22 a 25% de CPU. É um bocado alto (quando se utiliza a rede em simultâneo, por exemplo um update, ocorrem soluços) e como dizem que o SoX consome menos CPU…
Durante a execução o play consome 20 a 22% de CPU, apenas marginalmente melhor.
Mas como SoX permite vários formatos (wav, ogg…) permite o redireccionamento (pipe) de outros comandos como o espeak:
