AD4M4ST0R – um rover LEGO

This post is part 1 of 9 of  AD4M4ST0R - um rover LEGO

Na continuação das experiências com o ev3dev, dois dispositivos USB um pouco mais complicados:

  • wireless gamepad
  • webcam

Desta vez mostro primeiro o resultado e preocupo-me depois com as explicações 🙂

ad4m4st0r-01

O gamepad é um gamepad genérico para Sony Playstation 3 e PC, penso que a maioria dos gamepads USB serão igualmente reconhecidos. Já com as webcams não será bem assim, será necessário compatibilidade com v4l2 (webcams) ou gPhoto2 (máquinas fotográficas). Neste exemplo estou a usar uma webcam Logitech C170 que funciona com o v4l2 através do uvcvideo. Também utilizei com sucesso uma Canon Digital IXUS 500 com o gPhoto2. E também tentei com 3 webcams antigas sem sucesso (apesar de 2 delas funcionarem no meu Ubuntu… pelos vistos funcionam em modo de compatibilidade v4l1 que não parece existir no ev3dev).

A foto abaixo (não tocada) foi tirada pelo AD4M4ST0R durante o decorrer do video anterior:19-08-14_09h53m54s

[Actualizado a 20 de Agosto]

Para quem estiver interessado, publiquei em artigos distintos os detalhes quanto:

ev3dev – automatic login

Depois do ev3dev terminar a sequência de boot, a consola do EV3 saúda-nos com uma janela de login. Quando queremos utilizar em pleno a consola é necessário “desbloqueá-la” e para isso tive de descobrir como implementar autologin.

Encontrei várias referências a usar o ‘/etc/inittab’ mas não consegui resultados práticos. Encontrei contudo outra abordagem que resultou:

mkdir /etc/systemd/system/getty@tty1.service.d/
nano /etc/systemd/system/getty@tty1.service.d/autologin.conf

No ficheiro autologin.conf bastou colocar estas 3 linhas:

[Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin root --noclear %I 38400 linux

Após reboot o ev3dev fez o login automático com o user root, como pretendido.

ev3dev – keypad USB

Ter o LEGO Mindstorms EV3 a correr uma versão quase standard de Debian Linux começa agora a revelar as suas vantagens: podemos atirar-lhe com quase tudo o que tivermos na nossa gaveta de sucata… como por exemplo um teclado numérico USB:

USB Keypad (roline)

O sistema operativo reconhece-o como um teclado convencional:

root@ev3dev:~# dmesg
usb 1-1.4.1: new low-speed USB device number 7 using ohci
input: USB-compliant keyboard as /devices/platform/ohci.0/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/0003:0B38:0003.0001/input/input2
hid-generic 0003:0B38:0003.0001: input: USB HID v1.10 Keyboard [USB-compliant keyboard] on usb-ohci.0-1.4.1/input0
input: USB-compliant keyboard as /devices/platform/ohci.0/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.1/0003:0B38:0003.0002/input/input3
hid-generic 0003:0B38:0003.0002: input: USB HID v1.10 Mouse [USB-compliant keyboard] on usb-ohci.0-1.4.1/input1
root@ev3dev:~# lsusb
Bus 001 Device 007: ID 0b38:0003 Gear Head Keyboard
Bus 001 Device 006: ID 058f:9254 Alcor Micro Corp. Hub

(o teclado tem embutido um hub USB de 2 portas daí o segundo device USB reportado)

O sistema operativo cria entradas do tipo ‘event#’ em ‘/dev/input’ assim como apontadores com descritivos mais legíveis:

ls /dev/input/by-id/ -la
lrwxrwxrwx 1 root root  10 Aug 13 23:38 usb-0b38_USB-compliant_keyboard-event-if01 -> ../event2
lrwxrwxrwx 1 root root  10 Aug 13 23:38 usb-0b38_USB-compliant_keyboard-event-kbd -> ../event1

De modo que o teclado pode ser referido por um destes dois ficheiros:

  • /dev/input/event1
  • /dev/input/usb-0b38_USB-compliant_keyboard-event-kbd

Enquanto que o sufixo “event1” é variável, o descritivo “by-id” não é – no meu laptop Ubuntu o mesmo comando retorna:

~$ ls /dev/input/by-id/ -la
lrwxrwxrwx 1 root root  10 Aug 13 23:38 usb-0b38_USB-compliant_keyboard-event-if01 -> ../event19
lrwxrwxrwx 1 root root  10 Aug 13 23:38 usb-0b38_USB-compliant_keyboard-event-kbd -> ../event18

por isso é preferível utilizar o descritivo “by-id”.

Não é suficiente ler os valores deste ficheiro – o primir de uma tecla gera gera um código de vários caracteres aparentemente ininteligiveis:

~$ cat /dev/input/event1
w��S�VSw��S�VEw��S�Vw��S�Ww��S�Ww��S��Sw��S��Ew��S��^C

A solução é usar o comando ‘showkey -s’ para descodificar. Por exemplo premindo a tecla ‘4’ com e sem ‘NumLock’ activo resulta:

cat /dev/input/by-id/usb-0b38_USB-compliant_keyboard-event-kbd > showkey -s
  • Sem Numlock: “^[[D”
  • Com NumLock: “4”

Felizmente isto só é necessário se quisermos ler directamente o teclado. Em situações normais, quando os nossos programas estão a correr, o próprio sistema operativo pode fazer esse trabalho por nós. No caso do ev3dev podemos ler uma única tecla a partir da consola com o seguinte comando bash:

read -s -n 1 Tecla < /dev/tty1

O parâmetro ‘-s’ serve para correr em modo silencioso (i.e. a tecla não é simultâneamente escrita na consola) e o parâmetro ‘-n 1’ força a leitura de um único caracter (quanto ao pipe ‘< /dev/tty1’ descobri entretanto que tanto faz referir /dev/tty0 como /dev/tty1 portanto a partir daqui refiro a consola do ev3dev como /dev/tty1… porque sim)

O script abaixo junta esta informação com a obtida anterior a respeito dos motores e permite controlar a rotação do motor com as teclas ‘4’ (LEFT) e ‘6’ (RIGHT), terminado com a tecla ‘ENTER’.

#!/bin/bash

#chmod +x controlkey.sh

tput clear > /dev/tty1
setfont /usr/share/consolefonts/Lat15-TerminusBold32x16.psf.gz
echo -n "Prima tecla" > /dev/tty1

while true; do

  read -s -n 1 char < /dev/tty1
  if [[ "$char" = "" ]]; then
    break
  fi

  case "$char" in

  4) echo "LEFT" > /dev/tty1

     echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
     echo   1 > /sys/class/tacho-motor/tacho-motor0/run
     echo   50 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
     sleep 1s
     echo   0 > /sys/class/tacho-motor/tacho-motor0/run
     echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp

    ;;

  6) echo "RIGHT" > /dev/tty1

     echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
     echo   1 > /sys/class/tacho-motor/tacho-motor0/run
     echo   -50 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
     sleep 1s
     echo   0 > /sys/class/tacho-motor/tacho-motor0/run
     echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp

    ;;
   esac

done

echo "Bye!" > /dev/tty1

 

 

ev3dev – backup e boot time

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.

Trocar de cartão é simples e faz-se em 5 minutos:

  1. colocar o cartão no meu portátil Ubuntu
  2. criar uma imagem do cartão e guardar como backup
  3. tirar o cartão e colocar outro qualquer
  4. repor a imagem anterior neste novo cartão

Como novo cartão utilizei um SanDisk Ultra de 4 GB (microSDHC classe UHS-I).

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:

  1. 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
  2. Ainda no Ubuntu usando o system-config-lvm para adicionar a nova partição ao Volume Group já existente
  3. Voltando ao ev3dev e extendendo o Logical Volume ‘root’:
root@ev3dev:~# lvextend --extents +100%FREE /dev/ev3devVG/root
  Extending logical volume root to 3.59 GiB
  Logical volume root successfully resized

[editado posteriormente]

faltou indicar como expandir o file system:

resize2fs  /dev/ev3devVG/root

[se não der  no EV3 pode-se fazer no Ubuntu, precedendo o comando com ‘sudo’]

 

EV3 – orelha para micro-SD

Esta é uma das dicas mais simples e contudo mais úteis que vi nos últimos tempos:

EV3: Adding a pull-tab to your micro-SD card

Felizmente tenho um canivete-suiço de carteira com uma pinça que me permitiu desenrascar-me da primeira vez que precisei retirar o cartão (“que raio… mas isto não sai?”). Mas não torna a acontecer:

ev3-microsd-orelha01ev3-microsd-orelha02A LEGO só deve ter dado EV3 experimentais a malta com unhas muito grandes…

 

DIY: Power Adapter para NXT/EV3

As experiências com o ev3dev saíram-me caras em pilhas. Como a porta USB é 1.1 e o processador é cerca de 4x mais lento que o do Raspberry Pi, uma operação simples de actualização como

apt-get update
apt-get dist-upgrade

pode demorar uma hora (a primeira vez demorou bem mais, tantos foram os pacotes actualizados). E mesmo com as melhores pilhas já é uma sorte se conseguir que durem 4 horas.

O Philo (Philippe “Philo”Hurbain) tem no seu site duas soluções diferentes:

A primeira solução, mais “limpa”, consiste em refazer uma tampa para o brick Mindstorms com uma ficha para um regulador DC externo. A segunda solução, mais fácil, consiste em criar duas pilhas falsas por onde se estabelece a ligação ao regulador DC externo.

Optei por fazer algo semelhante às pilhas falsas mas sem enveredar pelo método do Philo de destruir uma pilha para aproveitar os contactos (demasiados químicos envolvidos e poucas ferramentas disponíveis). Além disso uma outra pesquisa fez-me concluir poder subsitituir uma das pilha falsas por uma simples garra:

Dexter Industries User Manual Wiki: dSolar
Dexter Industries User Manual Wiki: dSolar

O Philo usa um bastão de cola (para pistolas de colagem a quente) mas eu preferi usar do Polymorph que tenho à disposição. E depois de uma expedição de reconhecimento a um armazém chinês optei por usar um rebite para o contacto positivo da pilha (€0,75 um pacote de 6). Uma ficha para o regulador DC, uma garra e fio eléctrico completam a lista de material:

Com um alicate puxei para fora a cabeça do rebite:

Montei a cabeça ao contrário, ligeiramente saída:

Soldei a cabeça em ambos os extremos e dobrei o rebite:

Depois envolvi o rebite em Polyflex moldando mais ou menos da dimensão de uma pilha e tendo o cuidado de não tapar a cabeça do rebite que fará de contacto:

Depois foi só soldar os fios e a garra (falta isolar com fita isoladora ou manga termoretráctil, fica para depois)

Antes de arriscar queimar um Mindstorms testei o funcionamento «em vazio» com um regulador DC da Hama comprado na Mediamarkt:

É um valor um pouco baixo (6 pilhas AA em vazio fornecem entre 9.0 e 10.0 Volt) mas ainda assim superior aos 7.2 V de uma bateria Li-Ion. Talvez o EV3 aceite o valor acima do regulador (12.0 V) mas é um risco parvo que não vou correr [talvez mais tarde, com 3 díodos em série para abater 2.1 V como fiz na caixa de música LEGO]

A pilha falsa encaixa bem, assim como a garra:

Agora é só ligar:

It works!

Estas e algumas fotos mais no meu espaço Brickshelf.

ev3dev – controlando motores

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/”:

root@ev3dev:~# ls /sys/bus/legoev3/devices/
in2  in3  in4  outA  outA:motor  outB  outC  outD
root@ev3dev:~# ls /sys/class/tacho-motor/
tacho-motor0
root@ev3dev:~# ls /sys/class/tacho-motor/tacho-motor0
device           port_name      pulses_per_second     reset        speed_regulation_K  subsystem
duty_cycle     position       pulses_per_second_sp  run            speed_regulation_P  time_sp
duty_cycle_sp  position_mode  ramp_down_sp        run_mode        state            type
estop           position_sp    ramp_up_sp        speed_regulation_D    stop_mode        uevent
polarity_mode  power          regulation_mode        speed_regulation_I    stop_modes

Muito informação para processar mas para começar podemos confirmar apenas o tipo de motor:

root@ev3dev:~# cat /sys/class/tacho-motor/tacho-motor0/type
minitacho

Os motores Mindstorms são inicializados no modo “run forever”, podemos também confirmar isso:

root@ev3dev:~# cat /sys/class/tacho-motor/tacho-motor0/run_mode
forever

Neste modo podemos controlar o motor controlando 2 parâmetros:

  • /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
  • /sys/class/tacho-motor/tacho-motor0/run

o shell script abaixo faz o motor rodar 5 segundos num sentido e 5 segundos no sentido inverso, com um duty factor de 50%:

 #!/bin/bash
 echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 echo   1 > /sys/class/tacho-motor/tacho-motor0/run
 echo   50 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 sleep 5s
 echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 sleep 1s
 echo   -50 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 sleep 5s
 echo   0 > /sys/class/tacho-motor/tacho-motor0/duty_cycle_sp
 echo   0 > /sys/class/tacho-motor/tacho-motor0/run

 

 

ev3dev – lendo sensores

Começar a trabalhar com sensores Mindstorms, mais concretamente Touch Sensores. Tenho duas versões: NXT e EV3.

Adicionei touch sensor (NXT) no porto #2. O sistema operativo detecta o acontecimento:

root@ev3dev:~# dmesg
...
msensor sensor0: Mindstorms sensor registered.
touch-sensor in2:nxt-analog-sensor: Touch sensor connected to port in2

Alguma informação útil na wiki do projecto ev3dev:

De acordo com a wiki, os sensores Mindstorms são mapeados em “/sys/class/msensor”:

root@ev3dev:~# ls /sys/class/msensor
 sensor0

Confirma-se a presença de um sensor “sensor0”. Que podemos saber acerca dele?

root@ev3dev:~# ls /sys/class/msensor/sensor0
 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

Muita informação, alguma apenas genérica. Fiquemos por “mode” e “value0”:

root@ev3dev:~# cat /sys/class/msensor/sensor0/mode
 TOUCH

Sim, é um Touch Sensor. E como saber o estado?

root@ev3dev:~# cat /sys/class/msensor/sensor0/value0
 0

O sensor estava em repouso. Vamos repetir enquanto premimos o sensor:

root@ev3dev:~# cat /sys/class/msensor/sensor0/value0
 1

Então e se trocarmos por um sensor EV3?

root@ev3dev:~# dmesg
 ...
 msensor sensor0: Mindstorms sensor unregistered.
 msensor sensor1: Mindstorms sensor registered.
 touch-sensor in2:ev3-analog-sensor: Touch sensor connected to port in2

E qual é o device?

root@ev3dev:~# ls /sys/class/msensor/
 sensor1

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
root@ev3dev:~# cat /sys/class/msensor/sensor1/mode
 TOUCH

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:

root@ev3dev:~# chmod +x touch.sh
root@ev3dev:~# ./touch.sh

ou de dentro de outros scripts.

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’.

ev3dev – usando o LCD do EV3

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:

apt-get install figlet
figlet -f banner "Teste" > /dev/tty0
figlet -f big "Teste" > /dev/tty0

teste01mas é 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):

root@ev3dev:~# ls /usr/share/consolefonts/Lat15*
/usr/share/consolefonts/Lat15-Fixed13.psf.gz
/usr/share/consolefonts/Lat15-Fixed14.psf.gz
/usr/share/consolefonts/Lat15-Fixed15.psf.gz
/usr/share/consolefonts/Lat15-Fixed16.psf.gz
/usr/share/consolefonts/Lat15-Fixed18.psf.gz
/usr/share/consolefonts/Lat15-Terminus12x6.psf.gz
/usr/share/consolefonts/Lat15-Terminus14.psf.gz
/usr/share/consolefonts/Lat15-Terminus16.psf.gz
/usr/share/consolefonts/Lat15-Terminus20x10.psf.gz
/usr/share/consolefonts/Lat15-Terminus22x11.psf.gz
/usr/share/consolefonts/Lat15-Terminus24x12.psf.gz
/usr/share/consolefonts/Lat15-Terminus28x14.psf.gz
/usr/share/consolefonts/Lat15-Terminus32x16.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold14.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold16.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold20x10.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold22x11.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold24x12.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold28x14.psf.gz
/usr/share/consolefonts/Lat15-TerminusBold32x16.psf.gz
/usr/share/consolefonts/Lat15-TerminusBoldVGA14.psf.gz
/usr/share/consolefonts/Lat15-TerminusBoldVGA16.psf.gz
/usr/share/consolefonts/Lat15-TomThumb4x6.psf.gz
/usr/share/consolefonts/Lat15-VGA14.psf.gz
/usr/share/consolefonts/Lat15-VGA16.psf.gz
/usr/share/consolefonts/Lat15-VGA28x16.psf.gz
/usr/share/consolefonts/Lat15-VGA32x16.psf.gz
/usr/share/consolefonts/Lat15-VGA8.psf.gz

Bold e 32×16 parece-me bem por isso:

tput clear > /dev/tty0
setfont /usr/share/consolefonts/Lat7-TerminusBold32x16.psf.gz
echo "Hello World" > /dev/tty0

helloworldOs 11 caracteres de “Hello World” encheram uma linha (onde antes, com a fonte default, cabiam 44). Pelo menos já não é precisa a lupa.