O Falcão

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:

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:

colocar o cartão no meu portátil Ubuntu
criar uma imagem do cartão e guardar como backup
tirar o cartão e colocar outro qualquer
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:

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

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:

A 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:

External power supply for NXT®
Getting maximum mechanical power from RCX output (no final de LEGO® 9V Technic Motors compared characteristics)

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

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

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

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

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

ev3dev com USB Hub e USB Audio

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
(...)

O ALSA reconhece de imediato a nova placa de som:

root@ev3dev:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: legoev3 [LEGO Mindstorms EV3 speaker], device 0: LEGO Mindstorms EV3 [LEGO Mindstorms EV3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: DAC [USB Audio DAC], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

root@ev3dev:~# alsamixer
┌───────────────────────────── AlsaMixer v1.0.28 ──────────────────────────────┐
│ Card: LEGO Mindstorms EV3 speaker                    F1:  Help               │
│ Chip:                                                F2:  System information │
│ View: F3:[Playback] F4: Capture  F5: All             F6:  Select sound card  │
│ Item: Playback                                       Esc: Exit               │
│                                                                              │
│                                     ┌──┐                                     │
│                                     │  │                                     │
│                                     │  │                                     │
│                       ┌───────── Sound Card ─────────┐                       │
│                       │-  (default)                  │                       │
│                       │0  LEGO Mindstorms EV3 speaker│                       │
│                       │1  USB Audio DAC              │                       │
│                       │   enter device name...       │                       │
│                       └──────────────────────────────┘                       │
│                                     │▒▒│                                     │
│                                     │▒▒│                                     │
│                                     │▒▒│                                     │
│                                     │▒▒│                                     │
│                                     └──┘                                     │
│                                      75                                      │
│                                  <Playback>                                  │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

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…

root@ev3dev:~# apt-get install sox libsox-fmt-all
root@ev3dev:~# export AUDIODEV=hw:1,0
root@ev3dev:~# play Thunderstruck.mp3

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:

root@ev3dev:~# espeak -v pt-pt “olá” –stdout | play -t wav –

E temos o nosso EV3 a falar português 🙂

EV3 wireless com ev3dev

Depois de instalar a última versão do ev3dev (ev3dev-jessie-2014-07-12) experimentei ligar 2 dos dongles Wi-FI que uso com o Raspberry Pi:

ThePiHut
Wi-Pi

Para o kernel são o mesmo dispositivo:

root@ev3dev:~#lsusb
ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

Mas não foram carregados nenhuns drivers por isso actualizei:

root@ev3dev:~#apt-get update
root@ev3dev:~#apt-get upgrade
root@ev3dev:~#apt-get dist-upgrade
root@ev3dev:~#reboot

Agora o Debian já tem os drivers:

root@ev3dev:~#dmesg
(...)
usbcore: registered new interface driver rt2800usb
(...

mas surge uma outra mensagem sobre não carregar o firmware por isso

root@ev3dev:~#dmesg
apt-get install firmware-ralink

ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 5370 detected
ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29

E para a ligação wireless, à semelhança do Raspbian no Pi, editei o ficheiro ‘interfaces’:

root@ev3dev:~#nano /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

### acrescentar as linhas abaixo ###
auto lo
iface lo inet loopback
allow-hotplug wlan0
iface wlan0 inet dhcp
   wpa-ssid "WI-Fi SID"
   wpa-psk "Wi-Fi Password"

iface default inet dhcp

Confirma-se:

root@ev3dev:~#ifconfig
wlan0     Link encap:Ethernet  HWaddr 00:0f:55:a8:ac:0a  
          inet addr:192.168.1.69  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1447 (1.4 KiB)  TX bytes:1074 (1.0 KiB)

Só não percebo porque motivo só funciona um dos dongles (o ThePiHut) quando aparentam ser iguais. Talvez o firmware não o seja completamente.