PLUG

O meu primeiro projecto com Arduino, a pensar em MPL:

Formula LEGO by Jorge Pereira, on Flickr

Formula LEGO #2 by Jorge Pereira, on Flickr

Dimensões: 13 x 8x quase uma minifig

O cérebro é um NodeMCU v2 em modo Arduino com Wi-Fi interna.
A direção é por conta de um servo de 9g de R/C e a tração por conta de um micro-motor de cerca de 400 rpm.  Já consigo rodar a direção com o browser, só usando os exemplos que vêm com o Arduíno. Mais um par de dias e o motor também, depois o problema vai ser a bateria mas lá havemos de chegar.

Se encontrar um servo substancialmente menor para a direção talvez consiga reduzir a altura. Mas é dificil, este é de 9g e os que vi de 4g ocupam mais ou menos o mesmo volume. Há sempre a hipótese de usar um motor DC como o da tração e esquecer a ideia de controlar com precisão a direção.

É bem interessante! Mas, com os componentes e os "skills" de montagem (obtenção dos componentes, soldaduras, etc.) necessários, ficará mais acessível que os carritos 1:67 que mencionei no tópico genérico dos MPL?

Não.

Mas que tem muito mais piada tem

Estou com um problema técnico com o DNS Dinâmico e o meu router wireless por isso agora não posso demonstrar mas a ideia é disponibilizar um endereço de DNS género

http://legoiot.noip.me/

e quem aceder vê uma livecam a apontar para o carro e pode controlar o carro com o browser. Não há por aí muitos carros LEGO com endereço IP, pois não?

[editado mais tarde]

Problema resolvido, não tenho agora tempo para configurar uma webcam mas
"http://legoiot.noip.me/gpio/1" aumenta o pulso enviado ao servo, rodando a direção para a esquerda
"http://legoiot.noip.me/gpio/0" diminui o pulso enviado ao servo, rodando a direção para a direita

(o servo funciona com pulsos entre 1.0 e 2.0 mili-segundos, neste momento uso incrementos de 50 us o que dá 10 passos para cara lado da posição central, 1.5 ms)

Tenho aqui um colega a inundar-me o servo de pedidos por isso de vez em quando não responde mas para estreia nos mundos Arduino e Internet of Things não está mal.

Além disso os DNS da NoIp não sincronizam todos ao mesmo tempo por isso tenho pedidos a ir parar ao endereço errado e por isso rejeitados. Bem vindos ao lado mau da Internet of Things

O motor já funciona, segue o video da praxe com um grand finale imprevisto.



O motor tornou-se uma agradável surpresa, nunca imaginei que alimentado a 3.7V rodasse tão rápido.
Os movimentos do video são todos à custa de pulsos de 20 ms para aproveitar o ciclo do servo (não estou a usar os PWM's internos do NodeMCU).

[member=85]AVCampos[/member] estive a pensar no que disseste e não é assim tão complicado: até agora só soldei duas filas de pinos (headers) na ponte-H que controla o micro-motor e dois fios no próprio motor. O resto é como no LEGO, é só encaixar no sitio certo.

[member=21]gads[/member] tu que percebes de programação no século XXI, tens alguma sugestão para controlo por HTTP? Tenho a ideia que andar a ler pseudo-páginas (no fundo GETs) para controlar dois motores não será a forma mais inteligente de fazer a coisa... vou ter de ler umas coisas nas férias que aí vêm.

Esta noite pus-me a pensar e há aqui potencial para fazer um "SBrick Wi-Fi".  Aguardem pelas cenas dos próximos episódios.

[quote="CyberX"]
há aqui potencial para fazer um "SBrick Wi-Fi".[/quote]
Atenção que nestes casos, em que se quer baixa latência (o carro responder assim que lhe damos um comando), o Wi-Fi pode não ser o mais adequado: pelo menos para drones com transmissão de imagem em directo (FPV, First Person View) via Wi-Fi, é extremamente frequente haver muita latência, baixa taxa de transmissão, e até cortes, a distâncias ainda curtas.

Eu que percebo de programação do século XXI não tenho bem a certeza de ter percebido o queres fazer.

O protocolo HTTP provavelmente seria bastante ineficiente para isto, pois terias de interpretar potencialmente mensagens relativamente grandes. O protocolo HTTP consiste numa mensagem de Request e uma mensagem de Response.
A mensagem de request começa com a linha que descreve o verbo/acção (PUT, GET, DELETE, PUSH, etc.) que queres executar sobre o objecto identificado pelo URL. O Response devolve o resultado dessa operação através de códigos predefinidos (ex.: 200 = OK, 404 = Not found, etc.)

Ambos os tipos de mensagem são constituídos também por um conjunto de Headers standard ou não e cada um com o seu significado (ex.: Content-Type: "plain text"), seguido do corpo (body) da mensagem em si (que numa página Web tipicamente é o conteúdo HTML mas pode transportar qualquer tipo de ficheiro e/ou formato).

Neste caso, provavelmente poderias simplificar a mensagem e usares só a estrutura mínima que precisares. No entanto, isto são mensagens transmitidas em formato texto. Não sei que processadores tens disponíveis para isto mas pelo menos precisarás de fazer o parse da mensagem dos cabeçalhos da mensagem e por exemplo admitir que o corpo já vem com os bytes no formato correcto para ti.

Descrevi muito sucintamente a estrutura da mensagem HTTP que é normalmente usada numa comunicação RESTful, ou seja, o servidor apenas recebe requests dos clientes e devolve as responses. Não há uma comunicação activa por parte do servidor em enviar requests aos clientes (invertendo os papéis). O que não impede de o fazeres caso te dê jeito.

Para implementar webservers o que não faltam são linguagens e frameworks
Posso dizer que neste momento tenho usado muito o NodeJS que usa Javascript como linguagem de programação (na verdade como gosto de linguagens mais tipificadas, uso o Typescript que é convertido para javascript).

Diz-me em que posso ajudar se precisares de mais alguma orientação.

Obrigado pelas respostas.
Antes de mais, eu conheço bem o modelo OSI e mais ou menos a maioria dos protocolos ##TP... o que eu não sei é programar para comunicações
Já nem falo em message queing nem coisas mais avançadas, eu só preciso de uma forma de a partir de um device esperto (um PC ou um Raspberry ou um EV3 a correr linux ou [Murphy nos livre] um Android) dar ordens a um Arduino.

A razão do HTTP é simples: os únicos exemplos que encontro para Arduino Wi-Fi baseiam-se na utilização de uma library que implementa um motor muito simples de HTTP. O Arduino fica à escuta de pedidos GET, filtra o URL e responde conforme a terminação. Por exemplo, neste momento estou a aceitar 4 "comandos":

http://legoiot.noip.me/gpio/1 - incrementa pulso do Servo
http://legoiot.noip.me/gpio/2 - decrementa pulso do Servo
http://legoiot.noip.me/gpio/3 - acciona motor num sentido
http://legoiot.noip.me/gpio/4 - acciona motor no sentido oposto

(sim, o /gpio/ é inútil, não me apeteceu ainda eliminar, foi ficando do exemplo inicial onde me inspirei)

Neste momento, a latência não me preocupa assim tanto (e [member=85]AVCampos[/member] se for para um SBrick Wifi também não seria para carros de corridas ou manipuladores robóticos, seria mais como forma de expandir o número de motores por exemplo do EV3 ou como um substituto wireless do WeDo ou para accionar dispositivos com pouca frequência de utilização como bifurcações de comboio ou iluminações) mas a programabilidade da coisa sim - usar um browser por si só não serve, ninguém vai querer controlar um carro a carregar nos links acima referidos e a fazer BACK num browser.

Não encontrei ainda nenhuma library melhor para Arduino. Algo que usasse UDP em vez de TCP seria porreiro, porque assegurava menor latência.. mas isto nem bem é um Arduíno, caramba! É um ZX Spectrum do tamanho de um selo a tomar anfetaminas!

O Google é o maior!

Existem libraries de UDP para Arduino. E ainda por cima «oficiais». E ainda por cima vem uma referência nas release notes da projecto que eu estou a usar, bastou ler com mais atenção.

E existem APPs para Android que enviam pacotes UDP, deixando-nos associar as strings que queremos a cada uma das teclas.

O carro neste momento responde a mensagens UDP na porta 6000 em vez de HTTP na porta 80 (por agora deixa de funcionar a partir da Internet, não me está a apetecer abrir o meu router assim à maluca). Posso usar o Android para comandá-lo mas a experiẽncia ainda não é perfeita porque a primeira aplicação que eu instalei não faz auto-repeat da tecla, tenho de andar a clicar como se estivesse a jogar Daley Thompson's Decathlon no ZX Spectrum [bolas, estou mesmo vintage].

Se o comportamento do carro é melhor ou não não consigo perceber, mas é promissor ter conseguido descer na camada OSI.

Eu cada vez que venho ler os vossos posts até me assusto. É com cada palavrão  Cruz credo, devo ser mesmo burro. 

Então assim a ligar por UDP conectas o telemóvel directo ao carro? Noutras aplicações que vi, o aparelho cria uma rede Wi-Fi, o telemóvel liga-se a ela pelo procedimento standard de Wi-Fi, e a aplicação no telemóvel depois faz o resto.

Confesso que nunca gostei muito de programação, andei mesmo só a mexer em linguagens básicas como o Basic ou o (turbo)Pascal, isto antes de aparecerem as linguagens por objectos, o que já foi à um bom par de anos...

Mas gosto de ler os vossos posts, vou aprendendo sempre qualquer coisa.

[quote="Nuno Lino"]
Eu cada vez que venho ler os vossos posts até me assusto. É com cada palavrão  Cruz credo, devo ser mesmo burro. 
[/quote]

Está visto que não és do século XXI... 

Sem querer armar-me em arrogante nem desprestigiar ninguém até porque nem toda a gente tem de saber de Sistemas e eu por exemplo não percebo puto de motores nem automóveis (aqui todos me gozam por ter feito 66 mil km com o mesmo óleo no C1... e eu ainda estou convencido que andava mais )

A maior parte das pessoas que navega na Net usa o protocolo TCP. Se um pedido meu para ver uma página (HTTP) tiver algum problema pelo caminho os equipamentos de rede arranjam forma de o repetir, de reconstruir ou reparar. Há garantia de que a comunicação chega ao destino e há confirmação de que chegou. Mas é pesado e inefeciente para coisas mais simples como controlar um botão "Ligado"/"Desligado" ou coisas com muito conteúdo sequencial como transmitir video em tempo real.

UDP é um protocolo mais básico, essencialmente dá-se um berro e confia-se que do lado de lá alguém há-de ter ouvido. Se não ouviram ou ouviram mas não perceberam vão ter de pedir para repetir que entretanto temos mais que fazer do que ficar à espera.

O meu carro está ligado à rede por Wi-Fi. Em principio é mais ou menos o mesmo que usar Bluetooth ou Infravermelhos mas é muito mais abrangente - pode «falar» potencialmente com o mundo inteiro.

No inicio o carro falava por TCP e respondia a pedidos como se fosse um site na Net. Falava HTTP e TCP. Eu tinha de lhe dizer "Olá carro, sou eu, tudo bem? vai-se andando... Se faz favor, anda lá... obrigado"

Agora o carro fala UDP apenas, não há cá salamaleques. Eu dou-lhe um berro "ANDA! e ele anda.

CyberX:

Melhor explicação da coisa não poderia haver! Gostei. 

[quote="CyberX"]
O motor já funciona, segue o video da praxe com um grand finale imprevisto.
[/quote]

E eu a pensar que ia ver faíscas a saltar 

[quote="AGarcia"]
Confesso que nunca gostei muito de programação, andei mesmo só a mexer em linguagens básicas como o Basic ou o (turbo)Pascal, isto antes de aparecerem as linguagens por objectos, o que já foi à um bom par de anos...

Mas gosto de ler os vossos posts, vou aprendendo sempre qualquer coisa.

[quote="Nuno Lino"]
Eu cada vez que venho ler os vossos posts até me assusto. É com cada palavrão  Cruz credo, devo ser mesmo burro. 
[/quote]

Está visto que não és do século XXI... 
[/quote]