PLUG

Tenho a impressão de que o EV3 Basic suporta daisy chaining, mas que o implementa como se os EV3s pendurados não fossem mais que multiplexers de inputs e outputs, não dando para usar a "inteligência" de cada um.

Está aqui um comparativo do EV3 Basic, do Pyhton e do EV3-G: https://sites.google.com/site/ev3basic/ ... -or-python

[quote="CyberX"]
já não tem idade para estas andanças por isso vem chagar os outros [/quote]

[member=6806]CyberX[/member] também podes programar Java no bloco de notas  Mas acredita que se nem com IDE que tem ajuda contextualizada e tudo te safas com bloco de notas é que não vais lá

Esqueçamos por uns momentos o Java...
... o LeJOS é muito interessante!

Eles implementaram um protocolo "RMI" (não encontrei em lado nenhum o significado mas suspeito que seja Remote Management Interface como nos servidores Remote Method Invocation, um género de RPC) sobre TCP/IP.

Este protocolo / API expõe uma série de recursos de um EV3 (http://www.lejos.org/ev3/docs/lejos/rem ... teEV3.html) entre os quais os motores e os sensores mas tb as portas I2C e UART (isto à maioria não deve interessar mas para gadgeteers como eu...).

Mais: este protocolo pode ser utilizado de fora do EV3. É assim que o Eclipse descobre automaticamente o meu EV3 para transferir os programas ou para controlá-lo em modo manual.

O que significa que é possível correr um programa num PC que usa recursos dos EV3. E muito provavelmente será possível fazer o mesmo a partir do ev3dev !!!!

Como isto é tudo TCP/IP (valha-nos o Santo Modelo OSI!) percebi porque é que ao configurar a PAN só consigo clientes (slaves) por Bluetooth ou USB: é que o Wi-Fi já usa TCP/IP nativamente!

Resumindo isto para o [member=68]Conchas[/member] :
- eu não preciso da PAN para nada já que todos os meus EV3 usam Wi-Fi;
- quem tem a mania do purismo 101% e quiser usar USB ou Bluetooth usa PAN e fica limitado a 8 ou 16 EV3 (conforme use USB ou BT)
- quem não usa PAN (ou seja usa Wi-Fi) suspeit que o limite de EV3 que se podem usar com RMI seja a memória interna do master

Já que falo em master/slave, este exemplo mostra um master a enviar uma cópia do seu próprio programa para 3 slaves e depois envia-lhes impulsos para irem todos fazendo o mesmo que o master (apresentar uma imagem em modo banner):



Isto tem muito potencial!!!
Tanto que por momentos me esqueço que detesto Java!

Hum... está a ficar interessante!

[quote="AGarcia"]
Hum... está a ficar interessante!

[/quote]

É pá haja alguém!!!
Temos de fazer uma equipa PLUGstorms ou Hack'nPLUG. Primeiro encontro oficial em São João da Madeira, não dá créditos mas dá  1 minuto de avanço na brickrace!

Como sempre disse!... Ainda vais acabar a adorar Java!...
Há que experimentar e ver benefícios para aderir à causa.

Quando começares a ver que consegues fazer mais e mais fácilmente, não queres outra coisa...

[quote="Conchas"]
Quando começares a ver que consegues fazer mais e mais fácilmente, não queres outra coisa...
[/quote]

Duvido. Há pouco linux nisto

Mas há mais malta com ideias avançadas: o Juan Antonio Breña Moral está a integrar o java no ev3dev, ao ponto de se poder usar o hardware do ev3dev com o mesmo método RMI (que a propósito quer dizer Remote Method Invocation e é um género de RPC).

https://github.com/ev3dev-lang-java/ev3dev-lang-java
EV3Dev-lang-Java is a Java library designed to interact with EV3Dev hardware using the LeJOS way.

[offtopic]
Isto é tudo muito interessante mas só para o pessoal que gosta de programação!
Então e LEGO? Onde é que ele anda?
[/offtopic]

Voltando um pouco atrás, devo estar a ser muito ingénuo mas imagino o robot separador de peças uma coisa relativamente simples... um tapete onde as peças se deslocam, um sensor para ler a cor da peça, um motor para mover o tapete para a posição x de acordo com a cor x, ou y para a cor y, etc, e um motor para empurrar a peça para fora do tapete após chegar à posição correcta.
Não estou a ver é como é que se conseguiria colocar as peças no tapete individualmente e numa posição "legível" para o sensor.
Para uma coisa destas, atenção que eu não tenho nenhum EV3 por isso posso estar só a dizer asneiras, mas parece-me que basta um EV3, para ligar 1 sensor e 2 motores.

[quote="agadoijo"]
[offtopic]
Isto é tudo muito interessante mas só para o pessoal que gosta de programação!
Então e LEGO? Onde é que ele anda?
[/offtopic]

Voltando um pouco atrás, devo estar a ser muito ingénuo mas imagino o robot separador de peças uma coisa relativamente simples... um tapete onde as peças se deslocam, um sensor para ler a cor da peça, um motor para mover o tapete para a posição x de acordo com a cor x, ou y para a cor y, etc, e um motor para empurrar a peça para fora do tapete após chegar à posição correcta.
Não estou a ver é como é que se conseguiria colocar as peças no tapete individualmente e numa posição "legível" para o sensor.
Para uma coisa destas, atenção que eu não tenho nenhum EV3 por isso posso estar só a dizer asneiras, mas parece-me que basta um EV3, para ligar 1 sensor e 2 motores.
[/quote]

Pois isso é uma visão muito simplista da coisa...
São necessários muito mais motores para conseguires ter um sistema fiável e que despache 100K peças, durante a duração típica de um evento. É uma questão de fazer continhas simples.
Mesmo a classificação das cores é um grande berbicacho...

A colocação das peças no tapete é um grande desafio, mas com soluções.

De momento o problema maior é a programamção, mas parece que a solução está à vista.
Parte do protótipo mecÂnico já tenho montado à uns dois anos... até levei uma vez para a garagem.

Sim, são precisos vários motores para empurrar as peças para os respectivos contentores, e imagino que, não sendo o sensor de cores 100% fiável para todos os tons manhosos que a LEGO faz (e nem vou pelas variações de luz ambiente...), seja preciso vários, cada um com um brick transparente colorido à frente para fazer de filtro, e combinar os outputs deles para saber ao certo qual a cor.

---

Com toda esta conversa de programação alternativa, e visto que comecei a dar uns pontapés em Python no trabalho, deu-me vontade de investigar o Python para o EV3...

Pois sem demérito para o trabalho do Conchas, eu estou como o Marco, acho que se fazia a coisa sem computação distribuída (provavelemente à custa do bom e velho método da força bruta).

De qualquer maneira alinho nisto porque:
- computação distribuída interessa-me, sobretudo em ambientes hibridos (PC, Arduino, Raspberry Pi, EV3, Android todos ao barulho)
- se não for assim nem o pai morre nem a gente almoça, estou farto de slavefests a separar plates 2x2, só mesmo por amor à camisola

Ainda a ver umas coisas de RMI mas é um protocolo próprio do Java (e por isso não possível para Android, raios partam as disputas da Oracle com a Google) e apesar de haver tentativas não há nada fora do Java que consiga falar RMI directamente.

Mas há sempre uma alternativa. No caso do ev3dev a malta está a apostar no RPyC(or Remote Python Call, is a transparent python library for symmetrical remote procedure calls, clustering and distributed-computing)

Quando tiver tempo meto-me nisso - no meu PC posso invocar recursos do ev3dev pelo que de um ev3dev para outro também.

Um exemplo simples para usar um motor na porta A de um EV3 por TCP/IP e usar as libraries ev3dev que estão no EV3 (ou seja sem usar libraries localmente):
O Conchas não gosta de ev3dev tanto ou mais que eu de Java mas isto fazia-lhe o mesmo que o LeJOS com RMI.

Sou tipo para pedir-vos para levarem todos os vossos EV3 para São João da Madeira e tentar uma orquestração de EV3 por Wi-Fi.

ideias, ideias...!

Continuo a achar que vocês estão a complicar!
Percebo que sejam precisos vários motores para empurrar as peças se tiveres um motor por cada cor... mas eu pensei numa solução mais bruta... alias duas... empurras tudo o que está no tabuleiro ou viras o tabuleiro, assim só precisas de um motor, claro que isto implica processar uma peça de cada vez... e ai compreendo a questão tempo para processamento de 100k de peças!
A questão dos vários sensores para ler as várias variações também pode ser vista de outra forma... a vossa visão é um ev3 ter a informação dos vários sensores... então e se cada ev3 tiver apenas 1 sensor? E se não conseguir identificar a peça passa para o próximo EV3 tentar identificar? Um pouco à semelhança da linha de montagem de que se falou durante a separação de peças... cada pessoa/EV3 é responsável por uma cor ou neste caso um conjunto de cores.

[quote="Conchas"]
(...) durante a duração típica de um evento (...)
[/quote]
Mas seria para usar isto durante o evento? Ou para ficar a trabalhar na garagem entre eventos?
Teria a sua piada, numa actividade em paralelo com o mosaico, pessoa entrega placa, placa passa pelo "robot saca peças", peças passam pelo "robot separa peças" e a pessoa que teve para ai 15 min a montar a placa via tudo a ser desfeito em 30 segundos!

A minha ideia é mais ou menos como a tua Marco:
resmas de macacos (EV3) a trabalhar em separado, cada um recebe, identifca e xuta para o contentor correspondente. Simples.
A parte mais lixada é fazer chegar a cada EV3 uma peça em condições.

Teria muito mais piada as pessoas verem as peças a serem separadas por cores durante o evento e poupa-nos tempo de trabalho extra na garagem...

Basta um sensor de cores, mas no meu palno tenho um motor por cada duas cores +1 e mais alguns por determinar, no robot que faz o feed das peças para a esteira.

Podia ser mais simples sim, por exemplo num sistema como sugeres, se estivéssemos a separar umas centenas de peças. Não uma centena de milhar...
Tem a ver com velocidade, robustez, tamanho dos recipientes e pesos envolvidos, etc...
Não vamos querer um sócio a correr com uma peça na mão, de cada vez que o robot identifica uma peça.
De pois de veres, vais ver o quão simples e elegante a minha "linha de montagem" é.

[member=6806]CyberX[/member] Isto não tem nada a ver com computação distribuida...
O Master faz o trabalho todo! Trata-se apenas de um multiplexer com 3 ou 4 EV3s.

[quote="CyberX"]
A minha ideia é mais ou menos como a tua Marco:
resmas de macacos (EV3) a trabalhar em separado, cada um recebe, identifca e xuta para o contentor correspondente. Simples.
A parte mais lixada é fazer chegar a cada EV3 uma peça em condições.
[/quote]

Pois... eu acho que vocês têm uma ideia genérica e ainda não pensaram bem no assunto...
Além de que isso implica muito mais hardware...