Here is my python script for controlling SBrick with a gamepad from Linux. It uses pygame for reading the gamepad (as long as it’s supported by the kernel, see also my post about using a gamepad with ev3dev) and gatttool from BlueZ 5.x to talk to the SBrick (you need a BT 4.0 USB dongle)
It should work in Ubuntu and other Debian variants including Raspbian (Raspberry Pi) or ev3dev (LEGO Mindstorms EV3)
#!/usr/bin/env python
# sudo apt-get install python-pygame
import sys, traceback, os
os.environ['SDL_VIDEODRIVER'] = 'dummy'
from math import log10
from subprocess import call
from time import sleep
from pygame import joystick, event, display
### buttons ###
B_TRIANG = 0
B_CIRC = 1
B_CROSS = 2
B_SQUARE = 3
B_LTRIG2 = 4
B_RTRIG2 = 5
B_LTRIG = 6
B_RTRIG = 7
B_SELECT = 8
B_LJOY = 10
B_RJOY = 11
B_START = 9
def main():
try:
display.init();
joystick.init();
js=joystick.Joystick(0);
js.init();
DRIVE_A="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=0102"
DRIVE_B="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=0103"
COAST_A="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=01020000"
COAST_B="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=01030000"
BREAK_A="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=0002"
BREAK_B="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=0003"
### starts in Joystick mode ###
control_by_JOYSTICK=True;
num_axes=js.get_numaxes();
num_buttons=js.get_numbuttons();
num_hats=js.get_numhats();
### assuming 4 axes, 13 buttons and 1 hat
flag=False;
while True:
x=y=motor_r=motor_l=0.0;
event.pump();
button_mode=js.get_button(B_SELECT);
button_shot=js.get_button(B_SQUARE);
if button_mode ==1:
if control_by_JOYSTICK==True:
control_by_JOYSTICK=False;
print 'Control Mode=HAT';
else:
control_by_JOYSTICK=True;
print 'Control Mode=JOYSTICK';
### joysticks axis [-1, +1]
### x=axis2 , y=-axis3
### ignore less than 0.2 (dead zone)
### apply log10(100x) (to reforce lower values)
### result is less or equal than 2 = log10(100)
if control_by_JOYSTICK==True:
# Control by Right Joystick, Axis 2 e 3
axis2=js.get_axis(2);
axis3=js.get_axis(3);
if axis2>0:
if axis2<0.2:
x=0;
else:
x=log10(axis2*100);
elif axis2<0:
if axis2>-0.2:
x=0;
else:
x=-log10(-axis2*100);
else:
x=0;
if axis3>0:
if axis3<0.2:
y=0;
else:
y=-log10(axis3*100);
elif axis3<0:
if axis3>-0.2:
y=0;
else:
y=log10(-axis3*100);
else:
y=0;
if y<>0:
if x<0:
motor_r=100*y;
# turn left => slow motor_l
motor_l=y*(100+25*x);
else:
motor_el=100*y;
# turn right => slow motor_r
motor_r=y*(100-25*x);
elif x<>0:
# y=0, just turn
motor_l=100*x;
motor_r=-motor_l;
else:
# Control by HAT keys
hat=js.get_hat(0);
if hat==(0,1):
# print 'FRONT';
motor_r=100;
motor_l=100;
elif hat==(1,0):
# print 'RIGHT';
motor_l=100;
motor_r=-100;
elif hat==(0,-1):
# print 'BACK';
motor_r=-100;
motor_l=-100;
elif hat==(-1,0):
# print 'LEFT';
motor_l=-100;
motor_r=100;
elif hat==(1,1):
# print 'FRONT+RIGHT';
motor_l=100;
motor_r=50;
elif hat==(-1,1):
# print 'FRONT+LEFT';
motor_l=50;
motor_r=100;
elif hat==(-1,-1):
# print 'BACK+LEFT';
motor_l=-100;
motor_r=-50;
elif hat==(1,-1):
# print 'BACK+RIGHT';
motor_l=-50;
motor_r=-100;
# get direction and duty cycle
if (motor_l<0):
dir_l="00"
duty_l=str(hex(int(-motor_l)))
else:
dir_l="01"
duty_l=str(hex(int(motor_l)))
if (motor_r<0):
dir_r="01"
duty_r=str(hex(int(-motor_r)))
else:
dir_r="00"
duty_r=str(hex(int(motor_r)))
# command+direction+dutycyle
command_A=DRIVE_A+dir_r+duty_r[2:]
command_B=DRIVE_B+dir_l+duty_l[2:]
call(command_A, shell=True);
call(command_B, shell=True);
sleep(0.1)
# call(BREAK_A,shell=True);
# call(BREAK_B,shell=True);
call(COAST_A,shell=True);
call(COAST_B,shell=True);
# end while
except (KeyboardInterrupt, SystemExit):
print "Exiting...";
except Exception:
traceback.print_exc(file=sys.stdout);
js.quit();
joystick.quit();
display.quit();
sys.exit(0);
if __name__ == "__main__":
main()
A linguagem Snap! (antes designada BYOB) é uma linguagem de programação visual baseada na experiência “drag-and-drop”, uma reimplementação extendida da linguagem Scratch que tem ganho alguma notoriedade por ter sido incluída no ambiente gráfico dos Raspberry Pi.
Eis um exemplo de um programa muito simples, que faz um rover andar às voltas:
De há um par de anos para cá que alimento a ideia de utilizar Snap! para ensinar à miudagem [e não só] conceitos básicos de robótica. A forma como o Snap! está a ser desenvolvido permite criar «device extensions» para interagir com dispositivos físicos (descobri o Snap! justamente por ter uma extensão para Mindstorms NXT, a Snap-NXT by Technoboy10) e hoje criei a minha primeira extensão, para o Sbrick.
Basicamente editei a extensão para Mindstorms NXT, deitei fora a parte específica do NXT e acrescentei os meus comandos que invocam o comando gatttool do BlueZ (do que resulta a minha extensão apenas funcionar em Linux, lamento).
O primeiro é um programa em Python que corre um servidor http muito básico que aceita comandos http. O segundo é uma definição XML das funcionalidades implementadas (dois comandos apenas: ‘move motor’ e ‘stop motor’, sendo possível controlar 3 «motores»: A = channel#1, B=channel#2 e P = channel#1+channel#2). Estando o programa ‘snap-sbrick.py’ a correr, lançamos o Snap! com a device extension quando acedemos por browser ao endereço:
Ou seja o Snap! em si é carregado da Universidade de Berkeley e apontado para o nosso PC de onde carrega as definições das funcionalidades adicionais. É possível carregar o Snap! a partir do nosso próprio PC para trabalhar em modo offline mas isso já é outra história.
A definição dos comandos pode também ser feita graficamente, sendo depois gerado um ficheiro XML semelhante ao acima referido:
comando ‘move motor’
comando ‘stop motor’
Podemos ver que a definição de ‘move motor’ está bem melhor que a de ‘stop motor’ – é feita uma validação dos parâmetros, se speed não pertencer ao intervalo [-100,100] ou se motor não for A/B/P é gerada uma excepção.
Uma incursão rápida em Python e Tkinter (uma library para aplicações GUI muito fácil de usar no modo Google-Copy-Paste) para poder comunicar com o SBrick a partir do meu laptop Ubuntu sem usar a linha de comando:
Adquiri um módulo USB-RLY16 que permite comandar 8 relés através de uma porta USB. A ideia original é controlar as minifiguras LEGO em palco pelo que com 8 relés poderei controlar 4 micromotores LEGO de forma independente e em ambos os sentidos (os Xutos&Pontapés são 5 pelo que 2 deles terão de partilhar o mesmo motor ou terei de arranjar outra forma para controlar um quinto motor).
O módulo é baseado num circuito FT232RL que emula uma porta série através da ligação USB. Em Linux o suporte a este tipo de devices já vem incluído no kernel sendo associado um device do tipo ‘/dev/ttyUSBn’. No meu PC com Ubuntu 14.04 funcionou à primeira, tal como no EV3 com ev3dev e estou 100% convencido que com Raspberry Pi e Raspbian acontecerá o mesmo.
São necessárias duas alimentações: uma para o accionamento dos relés e outra (ou outras) para os circuitos controlados pelos relés. Teoricamente podem ser as mesmas mas optei por separá-las:
uma pilha PP3 com ficha de 2.1mm para o accionamento dos relés
uma pilha PP3 em caixa LEGO para os motores
Nota: a pseudo-documentação afirma serem necessários pelo menos 12V/500 mA para o accionamento dos relés mas dei-me bem com os 9V de uma pilha alcalina PP3.
Ligando ao EV3:
$ dmesg
(...)
usb 1-1.4: new full-speed USB device number 6 using ohci
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver ftdi_sio
usbserial: USB Serial support registered for FTDI USB Serial Device
ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
usb 1-1.4: Detected FT232RL
usb 1-1.4: Number of endpoints 2
usb 1-1.4: Endpoint 1 MaxPacketSize 64
usb 1-1.4: Endpoint 2 MaxPacketSize 64
usb 1-1.4: Setting MaxPacketSize 64
usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
Para comunicar com a placa é necessário configurar a porta série virtual (/dev/ttyUSB0) para comunicar a 19200 baud, 8 databits, 2 stop bits, sem paridade (19200 8N2) e sem hardware nem software handshaking. No Ubuntu usei o ‘puTTy’ mas como requer ambiente gráfico no ev3dev optei pelo ‘minicom’:
$ apt-get install minicom
O minicom tem um modo de setup:
$ minicom -s
depois de configurado (19200 8N2, no flow control) se carregarmos na tecla ‘d’ accionamos todos os relés e na tecla ‘n’ desactivamos todos (confirmem numa tabela ASCII que correspondem aos códigos decimais 100 e 110). Confirmado o funcionamento podemos sair (‘Control+A’ seguido de ‘Q’), a porta virtual permanece configurada até ao próximo reboot.
Podemos agora enviar comandos directamente da shell:
$ echo d > /dev/ttyUSB0
$ echo n > /dev/ttyUSB0
Em python podemos comunicar directamente com a porta virtual através da biblioteca pyserial (http://pyserial.sourceforge.net/):
$ apt-get install python-serial
import serial
from time import sleep
port = serial.Serial("/dev/ttyUSB0", baudrate=19200, bytesize=8, parity='N', stopbits=2, timeout=None, xonxoff=0, rtscts=0)
port.write("d");
sleep(1);
port.write("n");
sleep(1);
port.close()
O video acima corresponde ao script python abaixo:
import serial
from time import sleep
# da esquerda para a direita:
# motores A, B, C e D
#
# motor A e/f o/p
# motor B g/h q/r
# motor C i/j s/t
# motor D k/l u/v
#
def relays_all_off():
port.write("n");
def relays_all_on():
port.write("d");
### Motor A ###
def motor_A_Right():
port.write("ep");
def motor_A_Left():
port.write("of");
def motor_A_OFF():
port.write("op");
### Motor B ###
def motor_B_Right():
port.write("gr");
def motor_B_Left():
port.write("qh");
def motor_B_OFF():
port.write("qr");
### Motor C ###
def motor_C_Right():
port.write("it");
def motor_C_Left():
port.write("sj");
def motor_C_OFF():
port.write("st");
### Motor D ###
def motor_D_Right():
port.write("kv");
def motor_D_Left():
port.write("ul");
def motor_D_OFF():
port.write("uv");
port = serial.Serial("/dev/ttyUSB0", baudrate=19200, bytesize=8, parity='N', stopbits=2, timeout=None, xonxoff=0, rtscts=0)
motor_A_Left();
motor_B_Left();
motor_C_Left();
motor_D_Left();
sleep(1);
motor_A_OFF();
motor_B_OFF();
motor_C_OFF();
motor_D_OFF();
sleep(1);
motor_A_Right();
motor_B_Right();
motor_C_Right();
motor_D_Right();
sleep(1);
motor_A_OFF();
motor_B_OFF();
motor_C_OFF();
motor_D_OFF();
sleep(2);
motor_A_Left();
sleep(1);
motor_A_OFF();
sleep(1);
motor_B_Left();
sleep(1);
motor_B_OFF();
sleep(1);
motor_C_Left();
sleep(1);
motor_C_OFF();
sleep(1);
motor_D_Left();
sleep(1);
motor_D_OFF();
sleep(1);
port.close();
E agora um primeira experiência com múltiplos DS2413 numa mesma microLAN…
Cada dispositivo 1-wire tem um ID distinto gravado em fábrica:
$sudo ls /mnt/1wire/
3A.4C2B13000000 81.086D33000000 settings structure uncached
3A.B0E216000000 bus.1 statistics system
Vemos que temos 3 dispositivos de 2 classes diferentes. A classe 81 é a do Master Controller (o adaptador USB DS9490R) e a classe 3A é a do DS2413. Temos portanto dois dispositivos DS2413 na rede, cada um com o seu ID:
4C2B13000000
B0E216000000
Na forma como o owfs lida com 1-wire o par “Classe.ID” funciona como um endereço. É possível definir alias mas funcionam apenas localmente (isto é: se movermos a microLAN do meu Ubuntu para o LEGO ev3dev tẽm de ser redefinidos) e na minha primeira experiência com alias perdi o acesso aos dispositivos por isso deixo para outra altura.
Sendo da mesma classe, estes dois dispositivos partilham os mesmos atributos (PIO.A, PIO.B e PIO.ALL por exemplo). Se tiver um LED em cada PIO destes devices podemos por exemplo acender todos os LEDs percorrendo todos os dispositivos da classe 3A e escrevendo “1,1” na subpasta PIO.ALL.
O programa abaixo acende cada LED em sequência, primeiro num sentido depois no outro:
E o programa abaixo acende as luzes aleatoriamente, mais próprio para um concerto ou uma discoteca (com tempo hei-de estudar a forma de usar as rotinas PyAudio para medir a intensidade de uma música e controlar as luzes ao ritmo desta embora duvide que o EV3 tenha CPU para tal).
import sys, traceback
from time import sleep
from subprocess import call
from random import randrange
# B0E216000000/PIO.A = primeiro LED
# B0E216000000/PIO.B = segundo LED
# 4C2B13000000/PIO.A = terceiro LED
# 4C2B13000000/PIO.B = quarto LED
def main():
try:
# apagar tudo ao comecar
call("echo 0,0 > /mnt/1wire/3A.B0E216000000/PIO.ALL", shell=True);
call("echo 0,0 > /mnt/1wire/3A.4C2B13000000/PIO.ALL", shell=True);
while True:
# apaga tudo
call("echo 0,0 > /mnt/1wire/3A.B0E216000000/PIO.ALL", shell=True);
call("echo 0,0 > /mnt/1wire/3A.4C2B13000000/PIO.ALL", shell=True);
if (randrange(2) == 1):
call("echo 1 > /mnt/1wire/3A.B0E216000000/PIO.A", shell=True); # LED1
if (randrange(2) == 1):
call("echo 1 > /mnt/1wire/3A.B0E216000000/PIO.B", shell=True); # LED2
if (randrange(2) == 1):
call("echo 1 > /mnt/1wire/3A.4C2B13000000/PIO.A", shell=True); # LED3
if (randrange(2) == 1):
call("echo 1 > /mnt/1wire/3A.4C2B13000000/PIO.B", shell=True); # LED4
sleep(0.25);
except (KeyboardInterrupt, SystemExit):
print "Exiting...";
except Exception:
traceback.print_exc(file=sys.stdout);
# apagar tudo antes de sair
call("echo 0,0 > /mnt/1wire/3A.B0E216000000/PIO.ALL", shell=True);
call("echo 0,0 > /mnt/1wire/3A.4C2B13000000/PIO.ALL", shell=True);
sys.exit(0);
if __name__ == "__main__":
main()
Estou a reproduzir em LEGO um concerto dos Xutos&Pontapés. A posição dos elementos da banda em palco vai ser controlada por um controlador (ainda não decidi se um Raspberry Pi ou um LEGO EV3) e quero poder controlar também as luzes dos projectores:
Se as luzes acendessem todas em simultâneo as ligações eléctricas seriam simples e seriam necessários passar apenas 2 cabos (positivo e negativo, comuns a todos os LEDs) pela estrutura por cima do palco. Mas eu quero um controlo individual dos projectores e pelo menos 10 deles. Isso significa pelo menos 11 cabos (10 positivos e 1 negativo comum) e apesar de ser possível (consigo passar 4 ou 5 cabos de jumper por entre um furo Technic por isso bem arrumados os cabos até nem dariam muito nas vistas) obriga-me a ter pelo menos 10 portas digitais para o controlo (o que também é possível com circuitos adicionais mas não me cativa). E se quiser aumentar o número de projectores a coisa começa a complicar-se.
Comecei logo a pensar num bus de controlo e pendurar micro-circuitos de controlo ao longo do bus. O ideal mesmo seriam LEDs I2C mas não encontrei nada suficientemente pequeno ou funcional por isso optei por uma microLAN 1-wire.
O termo “1-wire” é enganador: são necessários pelo menos 2 cabos num bus 1-wire (dados e massa) e na maioria das aplicações práticas será necessário um terceiro para alimentar os dispositivos (a norma prevê um modo “parasita” em que os dispositivos retiram alimentação da ligação prevista para dados mas isso apenas se aplica a dispositivos de muito baixo consumo como sensores de temperatura). Mesmo assim 3 cabos é muito bom para controlar quantos LEDs quiser (se decidir mais 2 ou 3 projectores não preciso passar mais 2 ou 3 cabos nem desencantar mais 2 ou 3 portas digitais no controlador).
A Maxim fabrica o DS2413, um circuito extremamente reduzido que implementa 2 portas digitais bidireccionais. É um chip SMD mas a Adafruit fornece um kit com o chip já montado numa placa de circuito impresso sendo só necessário soldar 4 headers e eventualmente uma resistência (tudo fornecido com o kit) para podermos utilizar na nossa microLAN.
Uhmmm… qual microLAN?
É possível implementar uma microLAN com o Raspberry Pi como master utilizando uma porta GPIO e uma resistência de pull-up. Mas é algo específico para o Raspberry, prefiro algo que possa replicar no meu PC ou no LEGO EV3. Por isso encomendei à RS Online um Maxim DS9490R que é um dispositivo USB que funciona como master controller numa microLAN e é suportado pelo Linux.
No meu portátil (Ubuntu 14.04) foi só ligar:
$ dmesg
(...)
[18011.890734] usb 2-1.3: new full-speed USB device number 7 using ehci-pci
[18011.983566] usb 2-1.3: New USB device found, idVendor=04fa, idProduct=2490
[18011.983576] usb 2-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[18012.021996] Driver for 1-wire Dallas network protocol.
[18012.026144] usbcore: registered new interface driver DS9490R
Não fui ver que módulos foram carregados na altura mas penso que foram ‘ds2490’ e ‘wire’ (existe também um módulo ‘ds9490r’ mas não está presente no meu Ubuntu).
Após detectar uma microLAN o kernel cria uma pasta ‘/sys/bus/w1’ para dispositivos 1-wire:
$ ls /sys/bus/w1/devices
81-000000336d08 w1_bus_master1
“81-” identifica o DS9490
A ligação do DS2413 à microLAN é muito simples: o DS9490R tem uma ficha RJ12, idêntica às RJ11 dos telefones mas com 6 contactos. Felizmente dos 6 contactos apenas os 2 centrais são necessários pelo que podemos usar um cabo normal de telefone só com dois condutores:
3 – OW (OW 1-Wire Data)
4 – GND_OW (1-Wire Return)
Wire D
Apesar da datasheet da MAXIM indicar o pinout achei esta foto menos dada a confusões:
Sheepwalk Electronics: Pinout DS9490R
A Sheepwalk Electronics vende alguns produtos 1-wire (inclusive o DS9490R) e publica no seu site alguma informação útil relacionada com 1-wire.
Depois de soldar o header à placa da Adafruit foi só fazer as ligações (com cabos de jumper ou crocodilos, o que houver à mão):
Com 3 baterias AA NiMH (cerca de 3.8V) e um LED branco de alto brilho (cerca de 3.2V) temos 0.6V na resistência por isso se esta for de 1KΩ o consumo do LED será de 0.6 mA de corrente, bastante abaixo dos 20 mA tolerados por cada porta e suficiente para um teste (no palco LEGO irei puxar mais por cada LED, pelo menos 10 mA cada e alimentação será de outro tipo).
NOTA: com o kit da Adafruit vem uma resistência de 4.7KΩ para pull-up da linha ‘1-Wire Data’. Deveria ligar esta resistência ao pino 1 da ficha RJ12 (+5V vindos do bus USB do host onde estiver ligado o controlador, neste caso o PC) mas não me agradou muito a ideia e como suspeito que internamente o controlador já preveja isso optei deliberadamente por não usar o pull-up… aparentemente sem consequências.
Pouco depois de ligar o cabo telefónico ao controlador USB o nosso circuito é imediatamente reconhecido:
Infelizmente diz que a famíla 3A não está registrada – o suporte nativo do kernel a dispositivos 1-wire não se extende [ainda?] ao DS2413. É pena, assim não temos nada útil dentro de ‘/sys/bus/w1/devices/3a-00000012fdf4’. Mas tudo bem, já esperava isso, existe o projecto owfs dedicado especificamente ao 1-wire:
sudo apt-get install owfs
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libow-2.8-15 owfs-common owfs-fuse owftpd owhttpd owserver
Suggested packages:
owfs-doc
The following NEW packages will be installed:
libow-2.8-15 owfs owfs-common owfs-fuse owftpd owhttpd owserver
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 296 kB of archives.
After this operation, 1,364 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Após a instalação descobrimos que temos 3 serviços a correr:
owserver
owhttpd
owftpd
Embora não me pareçam necessários, nesta fase vou deixá-los a correr. Descobrimos também que o owfs impede o kernel de carregar os drivers que referi acima de modo a não ocorrerem conflitos:
Para aceder à microLAN usamos o comando ‘owfs’ mas primeiro é necessário definir um mountpoint onde o owfs vai criar uma estrutura de pastas virtuais que mapeiam cada dispositivo (escolhi ‘/mnt/1wire’):
sudo mkdir /mnt/1wire
sudo owfs -u -m /mnt/1wire
Para confirmar que funciona:
$ sudo ls /mnt/1wire
81.086D33000000 bus.1 settings statistics structure system uncached
temos 1 dispositivo na microLAN (o master controller DS9490R). Vamos agora ligar o DS2413 à microLAN – passadas algumas dezenas de segundos temos:
$ sudo ls /mnt/1wire
3A.F4FD12000000 bus.1 statistics system
81.086D33000000 settings structure uncached
agora já temos algo útil dentro do device ‘3A.F4FD12000000’:
$ sudo ls /mnt/1wire/3A.F4FD12000000
address family PIO.A PIO.BYTE r_locator sensed.B
alias id PIO.ALL r_address sensed.A sensed.BYTE
crc8 locator PIO.B r_id sensed.ALL type
Ligando um LED a PIO.A podemos acendê-lo:
$ sudo sh -c "echo 1 > /mnt/1wire/3A.F4FD12000000/PIO.A"
e voltar a apagá-lo:
$ sudo sh -c "echo 0 > /mnt/1wire/3A.F4FD12000000/PIO.A"
(os comandos são muito feios porque o owfs tem de correr com previlégios de root e eu não sou root no meu Ubuntu; em Raspberry Pi ou ev3dev bastaria:
Com os updates recentes ao kernel do ev3dev e a inclusão do módulo btusb [a meu pedido, modéstia à parte] já é possível utilizar dongles Bluetooth 4.0 com o LEGO EV3.
Enquanto não me chegam às mãos beacons e outros dispositivos BT 4.0 para testar, o único aparelho que tenho é um telemóvel Android que infelizmente apenas “consome” serviços. Bem, demos-lhe qualquer coisa para consumir: um beacon – não posso dizer iBeacon porque é trademark da Apple… mas é a mesma coisa: um «farol» que pode servir para marcar presença, orientação, medição de distâncias, fornecimento personalizado de informação…
Claro que primeiro é necessário um dongle Bluetooth 4.0 como este (qualquer um que funcione num Raspberry Pi a correr Raspbian deverá funcionar também com o EV3 a correr ev3dev).
É necessário também uma versão recente do ev3dev (baseado em Debian jessie, com kernel 3.16.1-1 ou superior, neste momento estou a usar a 3.16.1-2). Quem já tiver instalado a versão pre-release (ev3dev-jessie-2014-07-12) que à data é a mais recente disponível para download, basta
Temos 2 dispositivos Bluetooth: hci1 (UART) que é o nativo (interno) do EV3, ainda 2.0 e que por isso de pouco serve; e hci0 (USB) que é o nosso.
Podemos ver na informação acima que hci0 já está em estado “UP RUNNING” apesar de na maioria dos artigos que encontrei referirem sempre ser necessário activá-lo
hciconfig hci0 up
Inicialmente hci0 não está a anunciar-se em modo Low Energy pelo que é necessário ativar esse modo. Além disso o artigo em que me inspirei refer ser conveniente desactivar a procura de outros dispositivos por poder interferir e apesar de achar isso estranho para este exemplo mal não faz por isso
hciconfig hci0 leadv
hciconfig hci0 noscan
Resta apenas configurar hci0 para funcionar se anunciar como beacon e fingir ser da Apple:
Se no nosso Android instalarmos uma aplicação como a “Bluetooth LE Scan” (e o telemóvel/tablet tiver BT 4.0 e Android 4.3 ou superior) após um SCAN encontramos o nosso Beacon:
A precisão deixa um pouco a desejar: vários SCAN consecutivos deram valores entre 1m [NEAR] e 7m [FAR] quando o telemóvel estava a cerca de 1m40 do dongle.
Podemos ajustar um pouco mudando um valor de referência Tx Power enviado pelo Beacon no penúltimo byte do comando hcitool (“C8” acima) que corresponde ao valor RSSI medido em laboratória a distâncias de um metro, escrito em complemento para 2 (C8 = -56 portanto corresponde a uma medição de RSSI de -56 dB a um metro)
Seguem algures valores próximos de -56 dB:
-54 dB = CA
-55 dB = C9
-56 dB = C8
-57 dB = C7
-58 dB = C6
-59 dB = C5
Portanto se colocarmos o dispositivo Android a exactamente um metro do dongle USB, o valor RSSI medido será o nosso valor ideal de Tx Power.
Infelizmente obtive valores entre -55 e -63 dB (com o EV3 alimentado por carregador para garantir uma alimentação constante) por isso fiquei na mesma. Após algumas experiências com algumas medições a várias distâncias fiquei-me por -57 dB = C7, pareceu-me o menos flutuante.
Quando tiver um Beacon a sério vou poder calibrar melhor este meu EV3 B3AC0N (e até pode ser que a flutuação seja do software, vou procurar outras aplicações semelhantes).
Falta agora o inverso: utilizar hci0 para encontrar outros Beacons. Ou talvez outros B3AC0Ns.
Nota: podemos não fingir ser Apple, substituindo 4C 00 pelo Company ID de outro fabricante (infelizmente a LEGO não aparece) como por exemplo FE 00 (reserved)… só que deixa de ser reconhecido como um Beacon.
Se quiser lançar um programa automaticamente sempre que o EV3 com ev3dev arranca (sem ter que aceder remotamente por ssh nem ter um teclado ligado) a única solução funcional que encontrei foi implementar um serviço:
nano /etc/init.d/startup.sh
conteúdo do ficheiro:
#!/bin/bash
cd /root
python /root/joy6.py &
Dar permissões de execução ao script:
chmod +x /etc/init.d/startup.sh
Instalar o script como serviço:
update-rc.d startup.sh defaults
Se o nosso script não terminar por si e depois o quisermos terminar então temos mesmo de aceder por ssh, procurar o pid do processo e matá-lo:
pgrep pyhton
12345
kill -9 12345
(ou implementar uma forma de parar o serviço mas sou demasiado preguiçoso para investigar isso)
Um efeito secundário deste método é que a minha forma de implementar beeps (um shell script que envia o caracter BELL para a consola) deixou de funcionar. Como os beeps dão-me muito jeito para perceber o que alguns programas estão a fazer optei por arranjar um ficheiro ‘beep.wav’ com um toque curto de campaínha e tocá-lo com o comando ‘aplay’
A ideia é utilizar um sensor de cor para medir a luminosidade de modo a acender os LEDs de iluminação apenas o necessário para garantir uma imagem razoável.
O sensor utilizado é um EV3 Color Sensor (45506). Na wiki do projecto ev3dev há 2 artigos com a informação suficiente:
Infelizmente a gama de valores lida pelo sensor deixa muito a desejar: no mesmo local na minha sala observei de ‘1’ (de noite com luz fraca) a ’17’ (numa tarde típica de Agosto sendo a sala virada a Sul embora não haja incidência directa no sensor). E com uma lanterna a apontar directamente ao sensor obtenho ’68’.
Tirei algumas fotos com vários valores de leitura e vários duty cycles aplicados a 3 pares de LEDs Power Functions para tentar elaborar uma regra (o rover e a minifig sempre no mesmo local com cerca de 15 cm entre a webcam e a minifig, a iluminação dos LEDs nunca alterou o valor medido pelo sensor e todas as fotos foram apenas reduzidas dos 640×480 originais para 160×120)
Brightness
Duty Cycle
(%)
0%
25%
33%
50%
66%
75%
100%
1
–
–
–
–
–
3
4
5
6
13
–
–
–
17
–
–
–
Com esta informação optei pela seguinte função ‘fuzzy logic’:
Com a webcam a funcionar e com tanta coisa em comum com a comunidade Raspberry Pi ocorreu-me experimentar o OpenCV e testar as capacidades do EV3 no campo da Computer Vision.
Em vez de instalar o opencv todo, instalei apenas o módulo para python:
root@ev3dev:~# apt-get install python-opencv
Depois foi só criar o script ‘teste-opencv.py’:
import numpy as np
import cv2
imagePath = "/root/teste-face.jpg"
cascPath = "/root/haarcascade_frontalface_default.xml"
resultPath ="/root/resultado.jpg"
faceCascade = cv2.CascadeClassifier(cascPath)
image = cv2.imread(imagePath)
gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
faces = faceCascade.detectMultiScale(
gray,
scaleFactor=1.1,
minNeighbors=5,
minSize=(30, 30),
flags = cv2.cv.CV_HAAR_SCALE_IMAGE
)
print "Found {0} faces!".format(len(faces))
# Draw a rectangle around the faces
for (x, y, w, h) in faces:
cv2.rectangle(image, (x, y), (x+w, y+h), (0, 255, 0), 2)
cv2.imwrite(resultPath,image)
Como não instalei o opencv não tenho os ficheiros xml com regras de classificação. Para este exemplo o autor do artigo referido disponibiliza também o ficheiro ‘haarcascade_frontalface_default.xml‘.
Para esta foto ‘teste-face.jpg’:
O resultado do script, ao fim de 3 a 5 minutos de CPU a 80% foi este:
