PLUG

E confirma-se: tanto gamepads como [algumas] webcams funcionam bem no EV3 a correr ev3dev:





No video movo o rover com o joystick analógico direito e uso ainda dois botões do gamepad (START para alternar o estado dos motores STOP/RUN, SQUARE para tirar fotos 640x480). Algumas das vezes em que o rover parece não responder o motivo é eu estar a usar duty cycles proporcionais à amplitude do joystick e com duty cycles baixos os motores não reagem (há formas de contornar isso, tenho de ler documentação) - outras das vezes é mesmo culpa do programador, não percebo nada de eventos PyGame em python.

Não havia nenhuma Logitech C270 na Mediamarkt por isso levei uma C170, mais fraca mas também mais barata. É pena o cabo de 122 cm, por enquanto vai ter de andar enrolado por cima do rover, não me arrisco a cortá-lo e resoldá-lo.

Mais informação há-de ir aparecendo aqui.

Excelente trabalho!

É um bocadinho hipersensível o bicho, mas tenho a certeza que o programador dará conta do assunto!

Espero que vaz partilahando os teus avanços no grupo do EV3 no FB.

Obrigado.

Referes-te a "LEGO Mindstorms EV3 Community" (https://www.facebook.com/LegoMindstormsEv3) ?
Coloquei lá uma nota com video.
Agora só me falta, no que diz respeito a teste de gadgets USB, o adaptador Bluetooth 4.0 para testar emparelhá-lo com um SmartBrick. Mas preciso que os responsáveis do ev3dev actualizem o kernel, com este experimental que tenho não reconhece nenhum device.

Bom trabalho! Esse é o tipo de interface que eu gostaria de usar com o SBrick.

Poderá o duty cycle baixo ser compensado com uma frequência mais alta?

[quote="AVCampos"]
Bom trabalho! Esse é o tipo de interface que eu gostaria de usar com o SBrick.

Poderá o duty cycle baixo ser compensado com uma frequência mais alta?
[/quote]

Obrigado.
Também é o que eu gostaria de usar com o SBrick, mas de início talvez mais com Raspberry Pi ou mais provavelmente BrickPi que com o EV3 (o projecto ev3dev ainda precisa amadurecer um bocadinho e mesmo quando isso acontecer o ARM do EV3 fica sempre uns furos abaixo do ARM do Pi, mesmo sem overclock... e até já há quem use o GPU do Pi para reconhecimento de imagem!).

Nas minhas primeiras experiências com duty cycle baixos nem sequer havia frquência: aplico DC, coloco motor ON e fico a ver o resultado... só que quase nunca há resultado com DC's abaixo dos 40%. A outra alternativa é usar 'regulation_mode' para compensar, e nesse caso em vez de duty cycle controlo com pulsos por segundo:

https://github.com/ev3dev/ev3dev/wiki/U ... un-Forever

Para dar conhecimento dos avanços:

- com um cabo canibalizado e um par de resistências é possível ligar motores e/ou LEDs Power Functions às saídas do EV3 [as resistências implementam um valor de Auto-ID que faz o EV3 acreditar que se trata de um motor EV3] e controlá-los por Duty Cycle. Estou a usar LEDs PF para como "flash" para melhorar as fotografias da webcam em ambientes de pouca luz (sem grande sucesso, vou ter de usar LEDs de alto brilho)

- os motores EV3 "grandes" são bem menos sensíveis a Duty Cycles reduzidos que os "pequenos" (os meus primeiros testes foram com pequenos, o AD4M4ST0R usa grandes) por isso sem grandes artes melhorei imenso o comportamento (um video seguirá dentro de um ou dois dias). Mesmo assim implementei uma «zona morta» em torno da posição neutra do joystick e apliquei um logaritmo para reforçar as amplitudes baixas. O código está publicado no meu blog.

- com um botão do gamepad é possível comutar entre dois modos de comando ("por joystick" e "por teclas cursoras/hat")

Ontem houve um update que repôs o bluetooth mas infelizmente apenas funciona o device interno do EV3 (que me interessa pouco), falta ainda um módulo do kernel para funcionarem devices USB [com especial interesse para os BT 4.0]

Se queres usar os LEDs apenas para fotografias e não para filmagem contínua, eles provavelmente aceitarão sem estrago impulsos de tensão superior à nominal; assim sempre consegues um pouco mais de luz.

Ou então podes seguir ainda menos o caminho purista: compras uma máquina fotográfica descartável com flash (se é que essas coisas ainda existem), e aproveitas o tubo de xénon e respectivo circuito de carregamento/disparo.

Com os LEDs PF não preciso me preocupar, a tensão máxima numa porta de saída do EV3 é compatível com os LEDs, estiveram a noite toda acesos sem qualquer consequência.
Já se substituir os LEDs Power Functions por LEDs de alto brilho, teria de me preocupar com isso se usasse resistências demasiado baixas para puxar pelos LEDs... mas qualquer erro de software e PUF! Muito provavelmente optaria por LED's I2C como o BlinkM).

Mas por agora vou evitar fazer ainda mais cabos e manter-me com o meu cabo adaptador DIY EV3->PF, até porque permite acrescentar mais LEDs sem modificações, é só empilhar quantos pares quisermos [e tivermos, já que são estupidamente caros]



[sem LEDs - com um par de LEDs PF - com dois pares]
As 3 fotos foram tiradas a 15 cm, esta manhã, numa sala com apenas iluminação natural (não muita e indirecta).

Talvez com um Color Sensor EV3 se consiga medir a luminosidade ambiente para definir o duty cycle ideal a aplicar aos LED's antes de tirar a foto?

Por falar em LEDs estupidamente caros, esse I2C não fica a dever nada aos da LEGO...

É verdade, custam mais ou menos o dobro. Mas pelo menos este é controlável individualmente, pode-se escolher a cor e a intensidade e na versão mini pode-se encaixá-lo quase nos mesmos sítios.

Um LED convencional de alto brilho de 3mm e uma resistência custam menos de meio Euro. E se formos às lojas asiáticas compramos um candeeiro de pé a pilhas com LED's de alto brilho por uns 10€, não deve ser difícil fazer um «holofote» (bolas, não posso falar com vocês, surgem sempre ideias malucas)

[quote="CyberX"]
bolas, não posso falar com vocês, surgem sempre ideias malucas
[/quote]
Welcome to our world!

Como referi anteriormente, o controlo do movimento só com 1 joystick está melhor. E como entretanto aumentei as lagartas e passei a usar a bateria do EV3 ficou tb mais pesado e mais lento.