Projecto colaborativo - Codricks

[CyberX]

É verdade mas atenção que não estou a ver um controlador a ler mais que uma área de código de cada vez - a ideia, se fossem mesas, seria um controlador por mesa, com um programa por mesa e portanto um modelo apenas.

Embora nada impeça um programa de operar mais que um modelo, não vejo vantagem a não ser quando chegarmos a programas muito complexos, não lineares.

Quanto aos modelos serem inteligentes ou não, não tenho prioridade mas para primeiras provas de conceito é muito mais fácil a segunda opção. Pelo menos para mim.

[AVCampos]

[quote="CyberX"]
Embora nada impeça um programa de operar mais que um modelo, não vejo vantagem a não ser quando chegarmos a programas muito complexos, não lineares.[/quote]
Não necessariamente: lá cada pessoa controla um único robot e só lhe dá comandos simples (avançar, virar para um lado ou para outro, usar o lança-chamas, usar o extintor, nada de ifs ou loops), mas esse robot anda na mesma "arena" que outros e o controlador central tem à mesma de recusar comandos que as pessoas dêem que façam com que os robot colidam uns com os outros ou com o cenário.

Se usarmos robots simples com um "bumper" na frente e sem a possibilidade de serem guiados em marcha-atrás, é relativamente simples eles reencaminharem para os motores os comandos recebidos excepto se for detectada colisão. Pensando bem, não sei se o SBrick Plus consegue fazer isto, ou se é mesmo preciso MINDSTORMS.

[CyberX]

Tás a complicar

Isso é muito bonito na versão 2 e nós ainda vamos na 0.1

[AVCampos]

OK, o controlo anti-colisão é então implementado via hand-of-god pelo vigilante da mesa. Mesmo assim, ter um modelo semi-autónomo em que recebe os comandos do controlador e os passa para os motores torna o sistema mais escalável para na tal versão 2.0 ter inteligência para ignorar comandos inválidos.

A questão seguinte é: consegue-se fazer um protocolo que seja igual para modelos "burros" (PF, SBrick, etc.) e "espertos" (MINDSTORMS), mudando só a forma como cada um o interpreta?

[CyberX]

Não sei se percebi a questão.

Vamos supor a Logo Turtle.
Para modelos burros, a minha ideia era enviar comandos ON e OFF com temporizações pelo meio, à semelhança do que faz o Scratch e penso que o ambiente do WeDo / WeDo 2.
Para modelos não-burros a mesma ideia é válida mas podes também enviar comandos MOVE TO e nesse caso cabe ao modelo cumprir de forma intelignete o que lhe foi pedido

Agora como envias os comandos varia com o protocolo. Supondo que tens um controlador universal, digamos um EV3 a correr ev3dev equipado com um dongle USB BT4 BLE e um controlador IR que tanto pode ser um HiTech IRLink como os meus DIY...
- o controlador terá de saber que tipo de modelo tem à disposição, seja SBrick, BOOST, WeDo1, WeDo2, Power Functions IR, Power Functions direct, EV3 por bluetooth/Wi-Fi/USB, NXT por bluetooth/USB, etc...
- o controlador terá de ter rotinas que enviem comandos ON/OFF para os modelos burros pelo protocolo correspondente
- o controlador terá de ter rotinas que enviem comandos ON//OFF para os modelos não burros pelo p.c.
- o controlador terá de ter rotinas que enviem comandos MOVETO para os modelos não burros pelo p.c.

Agora cada modelo é um caso. Uma Logo turtle só tem 2 motores e eventualmente um terceiro para a caneta. O BOOST pode ter 4 motores e tem um LED RGB, etc. E estou só a falar de output.

Não quero complicar a coisa. O WeDo 1.0 parecia-me bem no sentido que limitava as opções a 2 "actuadores" Power Functions (motor ou luz mas com adaptador qualquer coisa LEGO que aceite PWM 9V) e 2 sensores. Isso permite ter blocos de código inequívocos para cada actuador e para cada sensor sem ter que criar classes, objectos, abstrações...

Bla blá blá... vamos ver o caso do Guilherme e da sua catapulta: um motor para accionar, eventualmente outro motor para direccionar. Zero sensores, mas poderá ter um de toque para as posições extremas, mas já é rebuscado.

Outro caso: o portão do castelo DMC: 3 motores (ponte levadiça, grade de ferro e sinos). Zero sensores.

Podemos fazer line followers e cube resolvers? Sim. Queremos? Não. Queremos é uma playzone para os miúdos programarem com peças.

Podemos mais tarde evoluir isto até à perfeição? Sim. Desde que não tire a piada aos miúdos.

[CyberX]

Recebi hoje da LEGO a instrução 55h ("Play button") que podia muito bem ser usada no projecto Codricks:

[gads]

Lol!
Muito bem!