Powered Up + Power Functions

[CyberX]

A LEGO lançou a versão 3.1.0 da App "Powered Up".
O @jetro notou que nas release notes dizia ser possível controlar sistemas LPF1 (ou seja os bons e velhos amigos Power Functions) e dizia também que era um bocado "techy" e que dava mais informações no website.

Pois... não dava.

Eu suspeitei que fosse recorrendo ao sensor de cor (algo já demonstrado por outros como nos teasers do projecto PyBricks mas nunca explicado como). Outros descobriram dois novos blocos na aplicação. Alguém do PyBricks sugeriu as specs do PF IR e que o sensor se encarregava da parte do checksum... foi só uma questão de tempo até juntarmos tudo:

Um dos blocos selecciona a cor (ou possivelmente a frequencia) do emissor, o outro envia comandos na forma Simple Output Mode em que se pode especicifar o Canal (0..3) e a Porta (4 = vermelho, 5 = azul) e o comando (0 = float, 1..7 = velocidade crescente, 8 = break and float, 9..F = velocidade descrescente rodando no sentido inverso):





Por enquanto é necessária a App mas assim que alguém snifar as mensagens BLE podemos fazê-lo directamente com o nosso software geek favorito (assumindo que com o firmware que veio com esta nova versão os hubs conseguem fazê-lo sozinhos, não vejo porque não).

O que significa que é agora possível controlar 8 motores PF com um único hub Powered Up (o Control+ que tem 4 portas) e mais até se usarmos vários e mantivermos os emissores/receptores afastados da vista uns dos outros.

[Conchas]

Vi o teu video hoje de manhã no YT e achei interessante. Fiquei curioso sobre o como, mas já vi que tens aqui tudo explicadinho!

[CyberX]

Para terminar a explicação, uma estreia mundial:
os códigos BLE dos comandos são:

para inicializar o sensor no modo/cor/frequẽncia/fase da lua pŕoprios:

Código: Selecionar todos

0a004100070100000001

para enviar a velocidade x para a porta vermelha no canal y:

Código: Selecionar todos

090081001151074x0y

para enviar a velocidade x para a porta azul no canal y:

Código: Selecionar todos

090081001151075x0y

em que x pode ser 0..F e y pode ser 0..3

Isto no meu caso com o sensor na porta A de um hub Powered Up No.4 (comboios)

[CyberX]

A implementação das specs parece estar completa e o "payload" do segundo bloco gráfico é simplesmente os 3 nibbles relevantes definidos no protocolo:

https://github.com/jurriaan/Arduino-Pow ... C_v120.pdf

Por exemplo no modo Combo PWM mode:

a 1 C C | B B B B | A A A A

'a' é usualmente zero (nunca vi nenhuma implementação com endereçamento alargado)
C C é o canal: 00 = canal 1, 01 = canal 2, 10 = canal 3 e 11 = canal 4
BBBB é o valor da saída B (azul) e varia entre 0 a 7 ou entre 9 e F cnsoante o sentido da rotação
AAAA é o valor da saída A (vermelha) e tem a mesma varição

de onde que por o motor vermelho a rodar num sentido ao máximo e o azul no outro sentido ao máximo, no canal 1 é:
0100 | 0111 | 1001 = 4 7 9

o bloco que o envia retém o comando por isso não é preciso metê-lo dentro de um loop para manter a transmissão

[Conchas]

Então agora explica lá a relação entre os dois posts anteriores, que eu percebo mais do segundo do que do primeiro!...
Dado que o segundo é o protocolo RC do PF1 e esse está bem documento e num único sítio.
O primeiro é a desgraça que sabe e espalhado por todo o lado.

[CyberX]

O primeiro diz o payload BLE para enviar os comandos a um hub Powered Up.

Em BLE podes fazer escritas em handlers ou leituras desses handlers. Um handler é um género de serviço, um disposito BLE tem vários - uns obrigatórios da norma que identificam o dispositivo e algumas propriedades deste (o nome por exemplo, a versão) e ainda enunciam que restantes handlers existem (os opcionais, que servem para efectivamente fazer alguma coisa).
O firmware dos hubs Powered Up da LEGO tem um handler opcional apenas. Os do WeDo 2.0 tinham mais, assim como o SBrick - basicamente um handler para cada funcionalidade, o que facilitava imenso a vida aos hackers e programadores juniores.

Como o Powered Up tem apenas um handler, tem de haver uma forma de dizer ao Hub o que queremos fazer. Ou seja, ele tem um género de interpretador interno e para fazer certas coisas é preciso enviar vários comandos - de inicialização, de pedidos de informação, de ações concretas....

Para colocar o sensor de cor em modo "Emissor IR LPF1" é preciso escrever nesse handler um dado payload:

0a004100070100000001

Isso na pseudo-documentação da LEGO é em parte conhecido: o primeiro byte (0A) é o comprimento do payload (10 bytes) funcionando de certa forma como um CRC simples. Os bytes seguintes têm os seus significados, um deles especifica o tipo de operação que queres fazer, etc...

Inicializado o sensor, ele passa a aceitar comandos LPF1. O payload desses comandos é do género:

090081001151074x0y

Mais uma vez o primeiro byte (09) é o tamanho do payload, outro byte ali diz que é uma operção LPF1 e os últimos 3 bytes são o payload que tu já conheces do protolocolo IR:

4x0y

como em quase tudo que mete comunicações digitais, os bytes estão revertidos: 0y4x ou seja o primeiro nibble é sempre 0 e os outros 3 nibbles são os do PF IR que compreendeste no outro post.

[CyberX]

esta parte críptica do payload BLE claro que só interessa se vais fazer a tua própria aplicação ou programa.

No meu caso já estive a ensaiar com o MINDSTORMS EV3 e consigo accionar os motores Power Functions directamente a partir da linha de comando ou, com uns scripts básicos, do python.

Como a comunicação é uni-direccional isto até pode ter alguma aplicacão prática no EV3. É muito complicado ler sensores Powered Up (ou controlar motores que reportam informação) porque tenho de estar sempre a escutar o que vem do Hub mas neste caso não tenho de escutar nada, só preciso de assegurar que a sessão não cai, como no SBrick, e para isso basta-me enviar um comando qualquer a cada 0.3 segundos e pode ser o próprio comando LPF1.

[CyberX]

Quanto àquela parte do ser possível controlar 8 motores ao mesmo tempo com um só sensor de cor... bem, possível é, útil é que não sei.

Fiz um "programa" (custa-me chamar programa a esta coisa dos blocos mas não me ocorre melhor) que invoca os comandos para 8 motores dispostos por 4 canais:



não há loop aqui, o programa envia em sequência os comandos e o Hub encarrega-se de manter o controlo de cada motor.
só que não o faz à primeira, no video apenas 3 motores arrancam à primeira (e não de seguida) e tenho que repetir o programa várias vezes até conseguir que todos fiquem activos (e no video desisti, acertar na porcaria do "play" com dedinhos de elefante é tramado)



por isso acrescentei um loop:



E vemos que ao fim de algumas iterações os motores efectivamente arrancam todos:



Portanto se queremos puramente ligar e desligar motores, é possível. Se queremos fazê-lo com alguma precisão temporal... esqueçam.

Mais: o Hub consegue ter os 8 motores a funcionar. Porque é que não o faz sequencialmente e à primeira? Aqui hesito entre:
- a aplicação LEGO Powered Up ser uma treta (que o é)
- o Hub ser lento a lidar com comandos de rajada (que de certo modo também o é mas aí a aplicação devia saber lidar com isso)
- o Sensor em si ser lento a lidar com o comando LPF1 (mas nesse caso o Hub devia saber lidar com isso e a aplicação também)

Aqui só tentei com um Sensor. Talvez com 2 sensores e distribuindo os comandos alternadamente por ambos a coisa funcione melhor (e nesse casso ficaria confirmada a terceira hipótese acima).

[CyberX]

Pois, parece ser a terceira hipótese.
Com 2 sensores, distribuindo os comandos pelos 2 alternadamente por vezes (mas só por vezes) consigo activar os motores todos à primeira. Não consegui registrar isso em video, os único video que tenho nem consigo sequer activar todos ao fim de uma dezena de retries.

Mas juntando um delay de 0.1 segundos já dá:




Isto é um bocadinho parvo e provavelmente depreciativo para os programadores que trabalham para a LEGO - se sabem que o hub demora 0.1 segundos (provavelmente menos, mas mais que os 0.01 segundos que tentei primeiro) deviam ter implementado um mecanismo qualquer de contenção. A parte do depreciativo é que tenho quase a certeza que implementaram - o BLE passa o tempo a mandar notificações (fiz isto, acotneceu aquilo) pelo que me cheira que envia também uma notificação quando o comando LPF1 é processado e está em condições de receber novo pedido... e nesse caso foi a malta da Aplicação que cheios de pressa de por isto na rua ignoram a notificação.

Deve sair uma versão 3.1.1 em breve... eu já tive problemas com um tablet não se conseguir reconectar e acabar o Hub por livre iniciativa em modo de upgrade de firmware que só consegui contornar indo para o telemóvel. E há um italiano no Facebook a queixar-se que não consegue conexão nenhuma mas consegue com a versão 3.0.0.

Saudades do tempo em que os gadgets LEGO só tinham firmware, devidamente testado antes de sair para a rua...

[Conchas]

Era exactamente o que te ia sugerir depois de ver o primeiro post... introduzir um pequeno delay entre comandos. Tipico!...

[CyberX]

Era exactamente o que te ia sugerir depois de ver o primeiro post... introduzir um pequeno delay entre comandos. Tipico!...

no no no... até eu que sou copy&paster de segunda sei que basta/convém/é necessário esperar pela notificação de que o comando BLE completou antes de enviar outro porque esta ªº??/ do BLE tem latência e não foi feita para grandes larguras de banda.

se é "típico" então devem ter vindo buscar os programadores e o s gestores de projecto a uma das empresas de consultoria que trabalha aqui prá empresa onde sysadmino.

[CyberX]

olha que giro, o fórum tem um filtro que censura as merdas que escrevemos?
nop, só algumas