Ornitóptero [Leonardo da Vinci Flying Machine] - Web Controlled

[CyberX]

Só para se alguém algum dia se perguntar, os parâmetros PID podem-se ajustar de 2 formas:

- directamente pelo comando

Código: Selecionar todos

'motor.control.pid(kp, ki, kd, integral_deadzone, integral_rate)

- indirectamente pelo parâmetro 'profile' na inicialização do motor

Código: Selecionar todos

motor = Motor(Port.A, profile=11)

não especificando o parãmetro profile, ou especificando o valor default que parece ser '11', o pybricks assume os valores

42484, 21242, 5310, 8, 15

aumentando o valor de 'profile' para '360' tem-se um comportamento mais semelhante ao da App da LEGO. Basicamente os valores de kp e ki são diminuídos, não sendo tocados os restantes.

Para 'profile = 1000' kp e ki foram diminuiídos quase 10x:
467, 233, 5310, 8, 15

para o meu caso pouco serve mexer em kp/ki, o motor continua a bloquear algures antes de atingir o deslocamento que eu pretendo e o programa bloqueia à espera que o motor complete o movimento. Aumentar kd significativamente faz o motor produzir uns roncos valentes, deixa lá. Não se sabe, não se mexe.

[CyberX]

Resolve-se um problema de força bruta... metendo mais força bruta

Juntei um segundo motor. E agora consigo puxar o gatilho controlando a velocidade, dizendo a ambos os motores para se moverem a baixa velocidade ATÉ não conseguirem mais. Sem precisar afinar nenhum parâmetro do motor ou do controlador PID.

Código: Selecionar todos

from pybricks.hubs import TechnicHub
from pybricks.parameters import Direction, Port, Stop
from pybricks.pupdevices import Motor
from pybricks.tools import multitask, run_task, wait

# Set up all devices.
technic_hub = TechnicHub()
motorA = Motor(Port.A, Direction.CLOCKWISE)
motorB = Motor(Port.B, Direction.COUNTERCLOCKWISE)

async def subtask():
    await motorB.run_angle(200, -120, Stop.BRAKE)
    await wait(1000)

async def main():
    for count in range(20):
        await wait(0)
        await multitask(motorA.run_until_stalled(180, Stop.HOLD, None), motorB.run_until_stalled(180, Stop.HOLD, None))
        await wait(1000)
        await multitask(motorA.run_angle(200, -120, Stop.BRAKE), subtask())

run_task(main())

Hmm... olhando para o código, está ali uma cena parva, é no que dá usar blocos gráficos para gerar código:

o último comando await multitask devia ser semelhante ao segundo e incluir ambos os motores em vez de incluir apenas um motor directamente e chamar uma subrotina para o outro. Vai dar ao mesmo mas não é coerente.

[AVCampos]

Ena, isso parece uma excelente ideia para engajar (hah, arranjei desculpa para usar essa palavra ) o público!

Concordo com o @Conchas: poderia o movimento ser mais suave se o motor estivesse em rotação contínua, como acontece com os bicharocos do Hewlett-Packard Harry Potter? Não sei é em que medida o elástico influenciaria isso.

Se o problema for especifico do EV3 talvez tenha mesmo de passar para um Raspberry Pi.

Se tiveres de passar, podes usar um 65817, e assim os puristas não podem reclamar (tanto).

[CyberX]

Se tiveres de passar, podes usar um 65817, e assim os puristas não podem reclamar (tanto).

Pfff... essa é uma das peças mais inúteis da LEGO... puseram-na num add-on pack rebuscado e nunca deram sequer um exemplo de utilização.

O "problema" tem a ver com o artíficio que usei para enviar mensagens em formato Pybricks a partir do EV3. Entretanto perdi-me no sentido inverso (receber mensagens) que tem sido bem mais difícil, tenho 2 abordagens diferentes e nenhuma delas satisfatória, nunca mais voltei a olhar para esse problema (mas tenho uma vaga ideia de o ter minimizado).

Entretanto descobri que o chipset do dongle BT tem muita influência na recepção - um 4.0 da ex-Cambridge consegue apanhar 10x mais mensagens por segundo que o BT 5.0 da Asus. Com o mesmo código! Tem a ver com a porcaria das parametrizações internas do chipset e não encontrei em lado nenhum como mudá-las (eventualmente refazendo o firmware que é carregado pelo driver... a muitos anos-luz de me meter numa alhada dessas). Ainda não testei a emissão com outros dongles para ver se muda alguma coisa mas suspeito que poderei ter uma agradável surpresa, quem sabe até descobrir que não existe sequer "problema".

Quando tiver estabilizado isto da recepção pego em tudo e publico um mini-how-to. Entretanto vou estando atento ao valor dos EV3 no bricklink, começam a aproximar-se do valor dos micro-motores de 9V [e têm muito mais utilidade].

[CyberX]

O "problema" tem a ver com o artíficio que usei para enviar mensagens em formato Pybricks a partir do EV3. Entretanto perdi-me no sentido inverso (receber mensagens) que tem sido bem mais difícil, tenho 2 abordagens diferentes e nenhuma delas satisfatória, nunca mais voltei a olhar para esse problema (mas tenho uma vaga ideia de o ter minimizado).

Após 3 semanas a partir pedra acho que consegui resolver a questão de receber mensagens. Das 2 abordagens que estava a estudar na altura passei para umas 5 e no final tenho duas satisfatórias:

- uma 100% MINDSTORMS EV3 que envolve utilizar uma versão do ev3dev aditivada que encontrei numa discussão do projecto, uma família conseguiu criar uma versão mais recente, com um kernel mais recente e inclusive um python mais recente (3.11) que faz toda a diferença, com isso consegui finalmente instalar uma library recente (o Bleak, que curiosamente também tem participação do David Lechner que é só um dos pais do ev3dev e do Pybricks)

- outra com um Raspberry Pi Zero a emular um teclado USB, passando para o EV3 as mensagens que recebe por bluetooth - para o EV3 é como se alguém as estivesse a escrever directamente nele

A primeira opção deu uma trabalheira do caraças e é apenas 99% fiável e ainda assim puxa pelo processador do EV3 que é uma coisa louca. E só funciona com dongles USB BT com chipset da Cambridge (os melhorezinhos que há por aí pelos vistos).

A segunda opção é simples e 100% fiável mas requer um dispositivo externo, o Raspberri Pi Zero 2, que apesar de mais volumoso que o dongle USB BT custa mais ou menos o mesmo e faz offload de todo o processamento pesado pelo que sou capaz de começar a adoptar esta estratégia.

Outra razão para optar pela segunda opção, que estive a discutir hoje com o Laurens (o outro pai do Pybricks) é que a nova versão de Pybricks que estão a desenvolver para o EV3 como não tem linux por baixo não consegue tirar partido de dongles BT ou Wi-Fi.. mas estão a considerar o suporte de HID (coisas como teclados, ratos, joysticks e gamepads) e eu estou justamente a fazer isso o que significa que funcionaria com a versão deles. E permitiria ligar toda uma catrafada de outras coisas ao Pybricks por extensão do que já fiz.

2 ou 3 dias para arrumar notas e descansar o tico e espero apresentar qualquer coisa.

[AVCampos]

Acaba por ser todo esse trabalho para fazer uns bicharocos bater as asas quando se lê um código QR!

[CyberX]

nope, acaba por ser esse trabalho todo para dar uso ao MINDSTORMS EV3 e mantê-lo de certo modo compatível com a família Pybricks.

Se eu só quisesse a parte do bicho a bater as asas por QR Code tinha ficado por um Raspberry Pi.

Dá trabalho mas aprendem-se algumas coisas. Algumas delas poderão dar jeito para outras andanças. Andanças essas que poderão ser úteis para outras e lá vamos nós para outro projecto.

LEGO? Sim, algum. Mas sobretudo como ferramenta para conseguir algo (neste caso uma cena a bater asas por QR Code), não como um fim em si.

Ou não fosse esta a secção "LEGO Technic & MINDSTORMS {Para os mais especializados em mecânica e electrónica em LEGO}"