MINDSTORMS EV3 observing Pybricks messages

[CyberX]

Como já havia dito noutra thread tenho andado a queimar as pestanas para poder usar o MINDSTORMS EV3 junto com os hubs Powered Up

A parte mais difícil, receber mensagens ("observar" na nomenclatura usada pelo Pybricks) ficou funcionamente funcional embora ainda seja necessário limar algumas arestas.

Mostro aqui Technic Hub, cada um a enviar ("difundir", de "broadcasting") mensagens no seu canal:
- no canal 1 é enviada a string "Ouch!" sempre que é accionado o sensor de toque;
- no canal 2 é enviada uma string com a cor detectada pelo sensor de cor e distãncia ("Red", "White", "Blue" e "Yellow")
- no canal 3 é enviada uma string indicando o número de vezes que o botão do hub já foi primido ("1", "2"...)

Cada mensagem é enviada durante 200 ms, depois disso o hub entre em radio silence até à mensagem seguinte. No protocolo implementado pelo Pybricks a duração de cada mensagem deve ser um múltiplo de 100 ms pelo que na melhor das hipóteses apenas é possível difundir 10 mensagens por segundo.

O protocolo no fundo imita um beacon Bluetooth Low Energy. A norma BT BLE prevê advertisements de mensagens curtas contendo informação específica (como o ID da empresa, no caso da LEGO 919) ou variável (no caso "Manufacturer Data", que pode ser uma temperatura, uma localização ou um URL) e qualquer cliente BLE pode escutar estas mensagens sem ter de estabelecer uma conexão (que é muito mais dispendiosa e complicada embora tenha a vantagem de depois de estabelecida permitir comunicações mais rápidas, supostamente mais seguras, blabla...).

O EV3 executa um script python que activa um "scan" dos dispositivos BLE por perto e se receber um "advertisement" com o ID da LEGO de um dispositivo com o nome começado por "Pybricks" regista a informação "Manufacturer Data" onde deverá estar o ID do canal usado e a string enviada.

Quando chega uma mensagem no canal certo o script limita-se a verbalizar essa mensagem.

Funciona muito bem só com um Hub a difundir, nem sempre bem com 3, provavelmente menos bem ou mal com mais hubs. E além disso o mecanismo de scan faz cache das mensagens recebidas por isso às vezes, ao mudar de canal, tenho a surpresa de receber em catadupa umas quantas mensagens antigas - no caso do vídeo cinco "Ouch!" que deviam ter sido descartados, tenho de descobrir como limpar esta cache.



o código e alguma documentação (ainda muito no início) podem ser consultados aqui:
https://github.com/JorgePe/EV3-Pybricks-Messaging

Daqui a alguns dias conto mostrar como faço a comunicação no sentido inverso (o EV3 a difundir mensagens no formato Pybricks).

[Conchas]

Essa demo está um pouco estranha para se perceber... digo eu!

O slope dark blue está assim tão perto do sensor de toque para o acionar. Na perspectiva do video não parece.

Também parece que só estás à escuta de um canal. Pelo menos numa boa parte do video (a primeira).
Parece que isso é selecionado com o manipulo ligado ao EV3, mas não percebi bem o que está a acontecer.

[CyberX]

pois...
o slope está perto do sensor justamente para o accionar... não me preocupei lá muito com a perspectiva do video

estou sempre à escuta de um canal apenas - de cada vez. Começo pelo canal 1 - o hub do slope, depois passo para o canal 2 - o hub das cores, e finalmente ao canal 3, o que só tem o botão, depois regresso

vou tentar pensar numa forma mais evidente de mostrar o canal que escuto... talvez também algo que não dependa das perspectivas

entretanto passei à transmissão e como funciona bastante melhor estou a implementar grande parte do protocolo - já consigo transmitir variáveis únicas do tipo boolean, integer (signed, 8-bit / 16-bit / 24-bit), string, float e bytes. Só falta preocupar-me com com as variáveis múltiplas.

Não vai haver video por enquanto porque não tenho nenhuma ideia prática de utilização a não ser o que já fiz - por um EV3 a ligar/desligar motores dos Hubs pybricks.

[AVCampos]

não tenho nenhuma ideia prática de utilização a não ser o que já fiz - por um EV3 a ligar/desligar motores dos Hubs pybricks.

Um robot maior que requeira vários hubs? Vários robots simples que precisem duma "inteligência central" para fazer uma tarefa coordenada (agora que penso nisso, um exemplo é um número de dança)? Um robot mais complicado que requeira o poder de processamento adicional do EV3?

[CyberX]

não tenho nenhuma ideia prática de utilização a não ser o que já fiz - por um EV3 a ligar/desligar motores dos Hubs pybricks.

Um robot maior que requeira vários hubs? Vários robots simples que precisem duma "inteligência central" para fazer uma tarefa coordenada (agora que penso nisso, um exemplo é um número de dança)? Um robot mais complicado que requeira o poder de processamento adicional do EV3?

A ideia da dança é engraçada, já me tinha passado pela cabeça uma coisa assim.

A parte do processamento adicional é utópica... o EV3 só é melhor que os hubs na quantidade de memória e na conectabilidade.
Cálculos simples o Technic Hub consegue fazer bastante rápido, inclusive em virgula flutuante (single precision) e alguma trigonometria.

Passar para o EV3 matrizes para cálculo matricial/vectorial? É possível mas o protocolo só permite enviar 24 bytes de cada vez, numa string desse tamanho ou num conjunto ('tuple') de variáveis até essa dimensão (acabei agora mesmo de implementar essa parte, está o protocolo completo no sentido EV3 -> Pybricks) e enviar mensagens de 24 bytes a um máximo de 10 mensagens por segundo dá 240 B/s ou 2400 bps. Eu comecei a navegar na net com ligação à faculdade a essa velocidade mas sejamos realistas, que exemplo concreto de computação distribuída beneficiaria disso?

Além disso isto é Bluetooth, não é TCP/IP. Não há garantia de entrega. Teria de se implementar um mecanismo de confirmação e com isso baixava ainda mais o throughput e queimavam-se ainda mais neurónios.

Sobra a conectabilidade. Por exemplo o leitor de tags NFC do LEGO Dimensions funciona bem com o EV3, tenho uma vaga ideia que o comando da Nintendo (numchuck?) que a LEGO vendeu em tempos também deve funcionar, fora os dispositivos específicos para MINDSTORMS que não existem para Powered Up (sensor de temperatura, sensor magnético, leitor RFID...). Isso e os gadgets USB como o leitor de impressões digitais e o leitor de códigos de barras já são mais a minha praia.

E claro a rede. O EV3 pelos vistos será o único brick inteligente da LEGO a ter suporte TCP/IP pleno, seja Wi-Fi seja Ethernet (é possível usar um adaptador USB-RJ45 e ligar a uma porta de switch). E voltamos à minha ideia do EV3 como gateway ou bridge para o mundo Pybricks.