[Hack] Conversor Powered Up (PF2) para Power Functions

[CyberX]

[quote="CyberX"]
[quote="AVCampos"]
[quote="CyberX"]
Os complexos (como os motores com encoder do BOOST) não deverão dar porque têm um micro-controlador dentro, o mesmo se aplicando aos sensores.[/quote]
Armando-me em perdedor de oportunidades de ficar calado: e que tal um adaptador para esses, mas para NXT/EV3 em vez de PF?
[/quote]

Murphy seja louvado! Um patrono!
Em meu nome e de todo o Open Source agradeço a tua contribuição de 300 euros para um analisador lógico e umas sondas, Alexandre.
Achas que mos fazes chegar antes das minhas férias, assim podia passar umas noites a fazer reverse engeneering ao protocolo em vez de queimar as pestanas com python?
[/quote]

Como eu não sou gajo de esperar sentado quero em meu nome e de todo o Open Source agradecer à minha entidade patronal que mais uma vez cumpriu com o a sua parte do nosso acordo mensal bipartido.



Falta-me agora abrir um crowdfunding para os paracetamols e outro para a clinica psiquátrica, quando eu perceber alguma coisa do que tenho à frente já não devo saber dizer o meu nome.

[CyberX]

Fernando, tu já falaste duas ou três vezes em servos profissionais... ten experiência concreta com algum? Dynamixel, Herculex...?

O servo do BOOST tem um microcontrolador STM8S103F lá dentro.
Alguém no Eurobricks já o abriu e identificou os pinos

Pin 5 = TX do STM8S103F logo RX do hub
Pin 6 = Rx do motor logo TX do hub

Eu estou a capturar ambos os pinos... mas só vejo dados a passar no Pin 6. Tb só estou a usar o comando de comboios e o Hub No.4, nesta configuração o motor funciona como um motor DC convencional, pode ser por isso que não vejo retorno. Mas ocorreu-me que a LEGO poderia não ter inventado a roda e ter encomendado o servo a outros... e alguns da Dynamixel são half duplex.

Vou tentar capturar com o Hub do BOOST a ver se faz diferença.

[CyberX]

Não faz.
O pino 5 praticament só serve para "pings" mais ou menos de 2 em 2 segundos.
Raispartam os designers da LEGO, half duplex em 2018?!?

[AVCampos]

[quote="CyberX"]
Raispartam os designers da LEGO, half duplex em 2018?!?
[/quote]
Temos mesmo de fazer a tal viagem da PLUG a Billund para ires lá dar um par de chapadas a cada um.

[AGarcia]

[quote="AVCampos"]
Temos mesmo de fazer a tal viagem da PLUG a Billund para ires lá dar um par de chapadas a cada um.
[/quote]

[Conchas]

Tenho uns servos RC para brincar.
Dynamixel não tenho nada são caríssimos e a LEGO só pode utilizar coisas muito baratas e barulentas...

Daí provavelmente a tecnologia da pedra...

Em concreto sempre me referi ao formfactor e daisychain, mas isso lá está... é caro!..

[CyberX]

Ainda é cedo para tirar conclusões mas parentemente os servos operam mesmo a half duplex tanto com o Hub No.4 como com BOOST Move Hub, através do pino 6.
Há actividade no pino 5 mas parece ser apenas um pulso a cada 2 segundos, mais ou menos.

O protocolo tá difíicil mas parece ser a 300 bps.

Vou ter de fazer um batch de comandos para tentar apanha algum padrão. Infelizmente o software que faz de Analizador Lógico não permite exportar o resultado o que dá uma trabalheira.

[CyberX]

Primeiro resultado interessante:

a 57200 bps o motor do BOOST envia constantemente 'A0 xx yy zz 0A' em que 'xx yy zz' é a representação 'little endian' da posição em coisos do encoder interno.

1 coiso = 'A0 01 00 00 0A'
2 coisos = 'A0 02 00 00 0A'
and so on

sendo que um coiso coincide com a rotação mínima que consigo do eixo e parece corresponder a qualquer coisa entre 4 a 6 graus já que preciso de enviar 4 a 6 comandos "roda lá o motor um grau" para conseguir um evento de mudança de um coiso.

Isto ainda vai dar uma trabalheira mas pelo menos já apanhei um padrão.

Edit: Afinal não é bem assim e ainda tenho de perceber melhor.

Parado, a mensagem é de 5 bytes e começa em A0 seguida de 4 bytes dos quais os primeiros três parecem ser a posição.
Rodando o eixo à mão, o primeiro byte reflecte o sentido da rotação e aparentemente também a velocidade desta.
O mesmo acontece quando o motor roda devido a um comando.
O último byte permanece um mistério, talvez um check code.

[CyberX]

Esqueçam o post anterior.

a 115200 bps o padrão consiste em 10 bytes:

START B0 B1 B2 B3 B4 B5 B6 B7 END

Sendo que o Start Byte é sempre D8

Quando o motor está parado e ainda na posição inicial:

D8 00 00 00 00 00 00 00 00 27

sendo que o End Byte =27 é o complemento para 1 do Start Byte = D8

Rodando devagar 1 grau:

D8 00 01 00 00 00 00 00 00 26

Rodando mais depressa o B0 também muda. Neste caso mandando rodar para 5 graus:

D8 00 02 00 00 00 00 00 00 25
D8 00 02 00 00 00 00 00 00 25
D8 07 03 00 00 00 00 00 00 23
D8 07 04 00 00 00 00 00 00 24
D8 03 05 00 00 00 00 00 00 21
D8 03 05 00 00 00 00 00 00 21
D8 00 05 00 00 00 00 00 00 22

B0 parece indicar o sentido da rotação e a velocidade.

B1 (e provavelmente B2, B3 e B4) indica a posição.

B5, B6 e B7 até agora sempre 00 e provavelmente não serão usados ou então indicam estados do motor [mas se for isso não a condição de stalled, experimentei]

Um primeiro algoritmo bacoco para o END Byte é calcular o XOR de todos os Bytes do Payload (B0 a B7) e subtrair ao complemento para um do START Byte:

END Byte = ones(STAT Byte) - (B0 XOR B1 XOR B2 ... XOR B7)

Não é muito mas já tenho informação suficiente para poder ligar controlar o motor do BOOST com um Arduino, um Raspberry Pi ou mesmo um EV3, só preciso de um pino de entrada série a 115200 para ler o encoder e dois pinos de saída ligados a uma H-bridge para accionar o motor.

[CyberX]

As férias terminam hoje.
Algumas noitadas sossegadas ajudaram a descobrir alguma coisa.

A síntese:
- o motor fala a 115200 bps 8N1
- o motor precisa de um "aquecimento" antes de começar a comunicar; ainda não percebi se é apenas para acordar o microcontrolador que está lá dentro ou se é também para se sincronizar com o "cliente", o que importa é que enviar-lhe uma carrada de zeros durante quase 1 segundo resulta;
- se perder o pio, repetir o mesmo processo de "aquecimento" resulta
- o motor precisa de um comando de inicialização; se não o receber (ou não o entender) queixa-se o que é óptimo porque assim volto a mandá-lo

Publico um script em python aqui.
O script usa um adaptador USB - Serial FTDI Beefy 3 que expõe as ligações que preciso compatíveis com os níveis do motor:

[img width=500]https://lh3.googleusercontent.com/Lyva0 ... 1920-h1080[/img]

- 3.3 Volt e GND para alimentar o motor
- TX e RX em níveis lógicos 3V3 (onde já vai o TTL de 5V dos meus tempos de liceu e faculdade...) 

Até agora o script tem funcionado sempre. Mas infelizmente não funciona no EV3. 115200 parece ser demasiado para o EV3. Mas talvez funcione num Raspberry Pi ou num Arduino.


Este é o tipo de informação que se obtém:

Código: Selecionar todos

Speed   : 00 (h) =  0 (d)
Position: 00   00   00   00 = 0  degrees
CRC     : 27 (h) =  39 (d)

Speed   : 11 (h) =  17 (d)
Position: 09   00   00   00 = 9  degrees
CRC     : 3F (h) =  63 (d)

Speed   : 1D (h) =  29 (d)
Position: 13   00   00   00 = 19  degrees
CRC     : 29 (h) =  41 (d)

Timeout -> Resync
Speed   : 04 (h) =  4 (d)
Position: 9D   00   00   00 = 157  degrees
CRC     : BE (h) =  190 (d)

Speed   : 00 (h) =  0 (d)
Position: 9D   00   00   00 = 157  degrees
CRC     : BA (h) =  186 (d)

Estava a rodar manualmente o motor cerca de meia volta (na prática 157º) na direção dos ponteiros do relógio.
O script perdeu o contacto com o motor a meio mas pelo menos recuperou a tempo de continuar a medir valores (se demorar demasiado o motor faz reset).

[AVCampos]

Ena, com o calibre de snooping que andas a fazer ao PU, ainda te começam a chamar "Snoopy"!

[AGarcia]

[quote="AVCampos"]
Ena, com o calibre de snooping que andas a fazer ao PU, ainda te começam a chamar "Snoopy"!
[/quote]

SnooPU! 

[CyberX]

Obrigado mas ainda prefiro CyberX, soa menos a DJ ou dealer

[AVCampos]

Ou a aviador da 1ª Guerra Mundial.