Projecto colaborativo - Codricks

[CyberX]

Ando a ver coisas como estas há uns tempos e a pensar... "ei, a gente consegue fazer isto só com LEGO!"

https://www.kickstarter.com/projects/54 ... rning-game


Neste momento estou apenas a lançar a ideia à discussão e sobretudo a fazer um lembrete para mim mesmo, não espero grande adesão mas esclareço já que não estou a pensar num projecto meramente "de programação", se/quando avançar há lugar para MOC'ers apenas.

A ideia é levar a eventos uma "playzone interactiva" onde os miúdos possam fazer o mesmo que numa playzone normal mas com cenas a mexer [e vigilantes a impedir que desapareça tudo num ápice]

Tanto o BOOST como o WeDo metem LEGO a mexer mas depois é preciso um tablet ou um smartphone com um display grande ou mesmo um PC. E depois é preciso correr uma App ou um programa, mexer uns blocos, parametrizá-los... blargh.

A minha ideia é fazermos os nossos próprios blocos em LEGO, como no Algobrix acima, e esses blocos controlarem um MOC.

Por exemplo um programa muito simples:
- um bloco "seta" faria accionar um motor por x tempo
- um bloco "botão verde" para começar
- um bloco "botão vermelho" para parar [opcional]

Os pirralhos pegam em quantas setas quiserem, encaixam umas nas outras, metem um botão verde no princípio, carregam no botão verde e vêm um MOC pré-feito de um caracol a andar um tempo proporcional ao número de setas.

As setas poderiam rodar sobre si mesmas e nesse caso parametrizar a direção de rotação do(s) motor(es).

Claro que "por baixo" ia ser preciso um Raspberry Pi (só com LEGO teria de ser um EV3, sai carote) ou um tablet mas totalmente invísivel. O controlo do MOC poderá ser por infra-vermelhos ou por BT ou por BT BLE ou por USB ou por som, logo se vê o que for mais fácil.

[Conchas]

Muito interessante a acho que posso colaborar uma vez definida a arquitetura da solução.
Mas só se for LEGO. Não me metas cá com Raspberrys...

[CyberX]

[quote="Conchas"]
Muito interessante a acho que posso colaborar uma vez definida a arquitetura da solução.
Mas só se for LEGO. Não me metas cá com Raspberrys...
[/quote]

Para ti apenas... sabes que corre Java, não sabes? 

Bom, se tenho de fazer isto com EV3... se isto for para a frente e fizermos uma prova de conceito que agrade, arranjas um protocolo com algum dos teus conhecimentos para uns quantos EV3 de suporte à coisa? Eu sou pobrezinho e não ganho para mais que 1 ou 2 EV3 por ano.

[AGarcia]

Parece um projecto interessante.
Vou seguir com atenção.

[CyberX]

Um exemplo, 4 blocos de código retirados do Snap! (podia ser do Scratch, é mais ou menos idêntico, ou mesmo do WeDo ou do BOOST, seguem a mesma filosofia):

[VER ANEXO]

cada um destes blocos pode ser um MOC em LEGO convencional, por exemplo sobre plates 16x6 (para começar vamos simplificar que todos os blocos, independentemente da função, têm a mesma dimensão).

O fluxo do programa é "de cima para baixo", este programa é muito simples e não tem loops nem decisões o que é óptimo por agora [num futuro longíquo claro que o fluxo não pode ser meramente linear].

Neste caso os blocos laranja são de controlo, os azuis de movimento e os roxos de som.
Há aqui dois blocos laranja de controlo que "marcam" o início e o fim do programa e dois blocos de output (movimento e som) encadeados uns no outro pela "patilha" de encaixe.

Esta "patilha" é importante para preservar a coerência do programa - não é por isso possível colocar "ínícios" no fim nem "fins" no ínício. Programas baseados em sistemas deste género não têm erros de síntaxe - se o programa não faz o que é devido nunca será por desconhecermos a gramática.

O bloco laranja inicial tem um "when green flag clicked", sendo a bandeira verde um botão do ambiente de trabalho do Snap! e do Scratch. No nosso caso concreto poderia ser outra coisa qualquer mas também poderíamos ter algures sobre a "playzone" uma bandeira verde em LEGO ligada a um sensor de toque de um EV3: quando o nosso infante carregar na bandeira o EV3 percebe que é para começar o programa.

E como é que o EV3 saberia o que fazer de seguida?

Por enquanto vejo duas possíveis implementações:
- um interpretador "real time"
- um pré-compilador

=============================

Interpretador real time:

A criança carregou na bandeira e lá vai o EV3 ter de seguir o fluxo do programa. Como o fluxo é linear um mero sensor de cor que se pode deslocar sobre um carril chegaria para acompanhar o fluxo ainda para mais sabendo que cada bloco tem 6 studs de dimensão.

Próximo bloco é de que cor? Azul? OK, dar um comando "MOVE" ao nosso MOC wireless, algures sobre a playzone (ou o próprio EV3).
Terminada a execução, avança-se o sensor mais 6 studs para o próximo bloco.
É de que cor? Roxo? OK, dar um comando "BEEP" no próprio EV3 ou noutro MOC qualquer.
Avançar mais 6 studs.
É de que cor? Laranja? OK, fim de execução.


======================================

Pré-compilador:

É necessário fazer mais ou menos a mesma coisa ANTES de se começar a execução. Por enquanto não vejo grande vantagem.


=======================================

Variantes ao sensor de cor:
- uma câmara sobre a área de código por forma a poder reconhecer blocos no plano em vez de apenas ao longo de uma linha;
- um braço robótico ou um sistema como o de uma plotter x-y que faça o sensor de cor poder deslocar-se num plano
- um sensor RFID como o Codatec da LEGO, tendo cada bloco uma tag RFID
- um sensor NFC como o LEGO Dimensions, tendo cada bloco uma tag Dimensions


isto ainda não endereça a questão da parametrização. Poderá até nem haver parametrização de todo, fazendo-se blocos diferentes para cada possível parâmetro (por exemplo 2 blocos "ROTATE" diferentes, um para +90º e outro para -90º)

Limitações: fluxos grandes, não lineares (IF-THEN-ELSE) seriam tão lentos quanto a capacidade do sistema de percorrer o "programa".
LOOPS já não uma vez que mantêm a linearidade (é apenas um retrocesso de x blocos)

Vou continuar a pensar melhor nisto mas com isto já se conseguia uma prova de conceito.

[CyberX]

Ocorre-me que o sensor NFC do Dimensions tem capacidade para ler 3 tags distintas de uma só vez.
Isso permitiria uma tag para identificar o bloco e outra tag para identificar o parâmetro, sendo que neste caso o MOC do bloco de código  seria uma união de dois MOCs:
- um MOC código base
- um MOC argumento (por exemplo uma representação do '5' para um parâmetro numerico ou um "cão" para um parãmetro de som)


Ou então, se o fluxo permanecer linear, dois sensores lado a lado, um sensor para a cor do bloco e outro sensor para a cor ou outra propriedade qualquer do parametro.

[AVCampos]

Na LEGO House têm algo parecido.

Cada visitante tem um ecrã táctil (não se se de computador ou um tablet), onde programa sequências de movimentos do seu robot usando blocos como esses. Cada (suponhamos, para simplificar) tablet comunica com um computador central, que dá depois os comandos aos vários robots.

A nuance é que o sistema central controla a posição e orientação de cada robot através de uma câmara por cima do campo, iluminação por IV, e bolas retro-reflectoras em cada robot. Isto evita que os miúdos façam os robots atrirarem-se uns contra os outros ou de encontro ao cenário.

---

Em alternativa, lembro-me que um MCP fez uma versão física gigante do jogo do MINDSTORMS que havia para telemóvel, com o mesmo conceito: o utilizador dispõe os blocos de instruções, e um EV3 lê-as em sequência e transmite-as a um EV3RSTORM no campo. A ver se encontro documentação...

[CyberX]

Primeiro MOCkup, com bricks 16x8 e um sensor de cor EV3 sobre um carril:





A ideia seria motorizar a coisa de modo a que o sensor EV3 se desloque 8 studs de cada vez, tendo um carril tão longo quanto o máximo número de instruções que se prentenda (neste caso o máximo são 6 por cada baseplate 48x48).

Os bricks 16x8 seriam decorados, evidentemente. Ou seja cada "instrução" seria um MOC per se.

[CyberX]

Lembrei-me deste projecto que tem andado no Eurobricks:


Faz lembrar um set LEGO DUPLO Education em que o comboio era controlado por peças coloridas enfiadas nos carris.

A idea é essencialmente a mesma mas não é prática. Embora dispondo os carris de comboio em recta e colocando as cores fora dos carris já fosse mais viável.

[CyberX]

Voltando à ideia inicial, como poderia isto ser colaborativo?

Estive a pensar e podemos partir o projecto em 3 áreas:

1. Interpretador
É o responsável pela identificação dos Codricks e pelo despoletar de ações na Área de Execução.
Teria:
- módulos que de algum modo disponibilizam um carril que percorre a sequência dos Codricks
- um leitor que se desloca sobre o carril para identificar cada Codrick
- um coordenador (um MINDSTORMS EV3)

2. Codricks
São os blocos de código em LEGO puro e que são dispostos numa cadeia lógica correspondente a um "programa"
Poderiam ser complementados com uma área de trabalho bonita mas funcionalmente inútil

3. Área de Execução
É o espaço físico onde se observa o "programa" a ser executado.
Teria:
- vários MOC's controláveis pelo coordenador, como uma Tartaruga ou um Caracol ou simplesmente o Vernie (BOOST), o Milo (WeDo 2.0), um Rover EV3 ou um Technic RC Tracked Racer, pelo que convinha que o controlo fosse multi-media: infra-vermelhos, bluetooth, bluetooth BLE, wi-fi...


Segundo esta ideia haveria 3 áreas onde os participantes podiam colaborar com construções, sem ter que meter código ao barulho:
- os módulos que disponibilizam o "carril" - algum Technic envolvido nisto
- os Codricks - muito pouco Technic envolvido nisto, se é que algum
- os MOC's controláveis

[gads]

Projectos colaborativos é comigo e estou interessado mas acho que preciso de mais informação em concreto para saber se consigo colaborar.

Sei que tem andado a falar nisso noutro tópico e peço desculpa se a pergunta é parva, mas existe já algum tipo de interface definida entre módulos?

[CyberX]

Outro tópico? Não me lembro de ter aberto mais nada.

Não há nada definido, só aquele mockup que fiz em video.

No que diz respeito aos módulos de carril estou mais inclinado para algo semelhante ao do vido - um carril em peças Technic - do que um carril LEGO Train, apesar de o último ser mais fácil de fazer e permitir extensões muito grandes. Os carris Technic (rack gears) permitem maior precisão, como é o caso da Impressora 3D que estou a usar.

No que diz respeito aos Codricks seria escolhermos um sistema qualquer de programação visual e imitar, eu pessoalmente preferia imitar os da LEGO, sobretudo agora que saiu o BOOST em força neste Natal:



No que diz respeito ao interface (media) entre o controlador e os MOC's controláveis, o melhor para mim seria Bluetooth Low Energy por permitir vários modelos (com o SBrick ou o BOOST ou o WeDo 2.0) e não ter problemas de distância, interferência com objectos/pessoas pelo meio ou luz flueorescente do tecto. Mas se quiserem infra-vermelhos também se consegue, tenho o trabalho feito.

Estou a assumir um controlador EV3 a correr ev3dev mas...
... se fizerem questão de um EV3 a correr o firmware nativo (programação EV3-G) ficamos limitados a controlar outros EV3, pelo menos se quisermos wireless. Se não fizermos questão de wireless podemos disfarçar uns cabos do controlador à Área de Execução e fazer uns MOC's controlados por cabo.
... se fizerem questão de um EV3 a correr LeJOS [quem seria capaz de uma barbaridade dessas?] consegue-se usar infra-vermelhos para controlar Power Functions e Bluetooth clássico ou Wi-Fi para controlar outros EV3.

Porquê um controlador EV3? Porque o Conchas quer. Por mim podia ser um laptop ou um Raspberry Pi a coordenar isto tudo.

[AVCampos]

Quanto aos modelos comandados, é capaz de ser melhor restringirmo-nos a pBricks, para terem "inteligência" suficiente para ignorarem comandos inválidos, como é o caso de ir para fora da mesa, chocar com outros modelos, ou mover as articulações para além dos seus limites.

Assim também simplifica o protocolo de comunicação, pois deixa de ser preciso IV (a não ser que haja algum robot com RCX) e BLE.

[CyberX]

[quote="AVCampos"]
Quanto aos modelos comandados, é capaz de ser melhor restringirmo-nos a pBricks, para terem "inteligência" suficiente para ignorarem comandos inválidos, como é o caso de ir para fora da mesa, chocar com outros modelos, ou mover as articulações para além dos seus limites.

Assim também simplifica o protocolo de comunicação, pois deixa de ser preciso IV (a não ser que haja algum robot com RCX) e BLE.
[/quote]

Por mim tudo bem mas se o controlador for esperto o suficiente podes dispensar em grande parte inteligência do lado dos modelos.
Eu estava a pensar por apenas um modelo por "Área de Execução" para não haver confusão. E o espaço físico ser de alguma forma contido (se em mesas, porque pode estar no chão).

Não esquecer que há-de sempre haver um supervisor humano e que, em principio, o público alvo são crianças por isso nem o código há-de ser muito longo nem muito complexo. isto de início, claro. Se sair da versão beta, podemos depois controlar o mundo.

[AVCampos]

Mas, se a segurança estiver do lado do controlador, ele fica com trabalho acrescido para além da descodificação das instruções e do seu envio ao modelo (e multiplicado pelo número de modelos em campo), para além de o protocolo de comunicação passar obrigatoriamente a ser bidireccional. Ter a segurança ao nível do modelo torna o sistema mais escalável, à custa de aumentar a complexidade individual dos modelos.

A solução na LEGO House funciona bem mas requer hardware bem mais sofisticado para manter o "tracking" (posição e orientação) de todos os robots em campo e filtrar os comandos de todos de modo a que não choquem uns contra os outros.