Respostas a este tópico

Permalink Responder até Francesco Artur Perrotti em 11 março 2014 at 18:52

Aqui fotos das versões produzidas do robô.

Esta primeira versão usava um PIC 18F. Mas não era wireless. Motores de passo retirados de impressoras.

Aqui já um pouco mais evoluído. Agora o microcontrolador é o Wixel, que já tem um transceptor RF embutido nele. A câmera é uma webcam wireless.

Aqui o robô já com um chassi mais apropriado, sensor de distancia, laser e leds para uso em conjunto com a camera. O microcontrolador ainda é o Wixel.

Ultimamente tenho trabalhado em uma versão simplificada de baixo custo usando arduíno. Esta versão ainda está em desenvolvimento. Depois posto uma foto aqui.

• ▶ Responder

Permalink Responder até Wilmar Cassiano Degobbi em 13 março 2014 at 13:42

Francesco,

Primeiramente, parabéns pelos robôs, estão bem caprichados, boa montagem.

Eu escolhi construir / evoluir um pequeno robô autônomo para aprendizado de microcontroladores e relembrança de eletrônica e programação. Não sou nenhum expert no assunto, porém como você já pesquisei muuuito.

Quanto a questão que coloca sobre os motores, na minha opinião há dificuldade de obtenção de BOAS informações tanto para os de passo quanto os DC. O que se acha é o básico mesmo. Quanto se pensa em estratégias de locomoção, manobras finas, navegação sofisticada, etc... eu até agora não achei nada muito avançado também. Tem bastante teoria ... o jeito é ralar no desenvolvimento mesmo.

Acredito que a pouca utilização dos motores de passo seja devido fundamentalmente ao custo, pois tanto o motor quanto o driver necessário é normalmente mais caro. Aqui no Brasil então, nem se fala né. Um aspecto negativo nos de passo é a pior relação peso/potência (torque) que demanda drivers ainda mais caros.

Lí ha pouco tempo, que na Asia há uma forte tendência de utilização desses motores em Micromouse´s, obtendo boas marcas de aceleração e velocidade máxima. Tá certo que lá eles devem encontrar com facilidade CI´s avançados. Por aqui o máximo que encontrei e estou começando a utilizar são os L297/L298. Especificamente aqui em Curitiba onde moro, nem esses se encontra.

Por outro lado, a utilização de motores DC é um pouco mais complexa do que aparenta os vídeos que achamos nos youtube´s. Pelo que pesquisei à venda no Brasil, praticamente nenhum kit de chassi/motor/encoder encontrado teria funcionamento minimamente adequado. Para controles mais finos então, esquece. Especificamente os pequenos motores utilizados nesses kits são uma lástima.

Na prática, para a construção de um robô melhorzinho acaba sendo necessário a compra do motoredutor e você que se vire na construção do encoder porque não se encontra nenhum a venda. Embora os princípios de funcionamento dos vários tipos de encoder seja até simples, fazê-los funcionar adequadamente é outra questão, bem mais difìcil.

Tentando desenvolver um encoder para o meu robô acabei tendo sérias dificuldades com um bendito mal contato (que obtive grande ajuda aqui neste fórum) que me tirou a atenção do que era muito crítico (considerando a opção por IR): a impressão do "codewheel" é praticamente impossível quando se deseja uma boa resolução e o diâmetro externo  do bichinho tem de ser pequeno (compatível com o porte do robô). Como a resolução do IR é muito alta, qualquer imperfeição na impressão é detectada e bagunça o controle de rotação do motor. Havia testando antes por efeito Hall, mas vai achar um rotor adequado... Eu tentei construir um com imás de neomídio e acabei desistindo porque os imãs são "muito" diferentes entre sí e acabam tirando a precisão do encoder.

Portanto, se me permite, aconselho que fique nos motores de passo, até porque já obteve sucesso com eles, como diz.

Eu, temporariamente, acabei desistindo dos motores DC devido aos encoders e voltei aos de passo. No momento estou desenvolvendo outro driver com os citados L297/L298 para utilização de chopper e melhoria principalmente do torque, pois quero que o bichinho suba e ande em tapetes, p. ex. (sem falar em rampas, vixê) e os motores/drivers que me fizeram tentar os DC não iam nem com reza braba. Agora adquiri uns NEMA 23 (exagerei um pouco) que têm um torque muito alto. Estou pressentindo que o novo driver nem precisará do chopper, mas terei que utilizá-lo para melhorar a pulsação do torque, mas isso ainda depende de testes reais.

Wilmar

• ▶ Responder

Permalink Responder até Francesco Artur Perrotti em 13 março 2014 at 18:58

Olá Wilmar,

Puxa, obrigado por compartilhar tua experiência, me esclareceu bastante e fico mais aliviado, eu estava considerando partir pra motores DC na próxima versão, mas agora resolvi que vou continuar com motores de passo mesmo.

Informações completas e precisas sobre motores (DC ou de passo) realmente são raras na internet, apanhei muito no início por causa disso especialmente porque inicialmente meu projeto era voltado ao uso de sucata. Descobrir as especificações de motores retirados de sucata foi muito trabalhoso e nem sei se consegui realmente, mas pelo menos consegui que funcionassem. Tambem complicou o fato de eu não ter nenhuma formação na área de eletrônica, sou da área da computação, meu conhecimento de eletrônica veio do meu interesse na área, de leituras, testes, mas ainda apanho bastante sempre que tenho que projetar alguma placa pro robô, por mais simples que seja.

Também por isso, o foco do meu projeto é produzir um sistema que tenha a eletrônica mais simples possível, de preferência usando placas pre-montadas de baixo custo, mas que permita uma programação sofisticada, ou seja, é um robô feito para programadores que não tem muita experiência com eletrônica, mas querem ter um sistema completo e de baixo custo, com recursos suficientes para implementar comportamentos e funções avançadas no robo.

Quanto à questão do custo dos motores de passo, eu acho que aí tem muito marketing envolvido nessa noção que motores de passo são mais caros. Talvez sejam um pouco mas nem tanto assim, se compararmos um motor de passo com um motor DC individualmente isso é verdade, mas motores DC são inúteis sem um sistema de redução decente e uma boa caixa de redução não é barata. Um sistema de redução caseiro usando engrenagens e polias é possível, mas bem trabalhoso e exige alguma experiência em mecânica e ferramentas apropriadas para que seja bem feito, é muito fácil cometer pequenos erros de alinhamento e distância que acabam prejudicando o desempenho. Nos meus robôs os as rodas são instaladas direto no eixo dos motores sem nenhum sistema de redução.

E também tem encoder que o motor DC precisa e o de passo não. Então a comparação de preços devia ser feita levando em conta o motor DC, a caixa de redução e o encoder. E aí a diferença de preços fica bem menor e em alguns casos o de passo sai até mais barato.

Finalmente a questão da sucata, que foi o início deste projeto. Os dois tipos de motores são facilmente encontrados em sucata. Mas não é facil encontrar caixas de redução e encoders facilmente utilizáveis em sucata. Então mesmo encontrando um motor DC apropriado, ainda vai ser necessário providenciar a redução e o encoder.

Além disso, motores de passo não usam escovas, não tem nenhuma parte que sofra desgaste mecânico dentro dele. Voce pode retirar um motor de uma impressora produzida a mais de vinte anos atras e ele funciona perfeitamente. Já com motores DC é bem dificil achar um em boas condições em sucatas mais antigas. Na verdade, os melhores motores de passo que encontrei foi justamente nas impressoras mais antigas. Antes as impressoras usavam motores de 200 passos, agora usam motores de 48 ou 64 passos.

Sobre a placa de controle/potência para os motores, no início usei motores unipolares, então o controle é bem simples, eu mesmo fiz com dois ULN2803. Quando passei pros bipolares, que tem mais torque, aí a coisa complicou e acho que passei pelo que vc está passando agora, só que com muito menos conhecimento de eletronica. Até tentei fazer uma placa de controle usando o L298, mas placa ficou enorme, o resultado não foi bom e no fim ficou muito mais caro do que uma placa já pronta pra isso. Então desisti de fazer isso e partí para as placas prontas. Tem um monte de opções baratas no mercado pra placas com dupla ponte H usando o L298 e que aguentam até 2A por canal. No meu caso isso é suficiente pros motores que uso.

Não entendi a referência ao uso de chopper, achei que isso era pra motores DC, vc quer usar pwm nos pulsos pros motores? Quando quero mais torque, ativo o modo que eu chamo de "turbo" no robô. Nesse modo as duas bobinas são ativadas ao mesmo tempo aumentando bastante o torque e também dobrando o consumo de energia.

Abraço

Francesco

• ▶ Responder

Permalink Responder até Wilmar Cassiano Degobbi em 14 março 2014 at 2:21

Olá Francesco,

Eu também utilizei algumas sucatas no meu robozinho, p.ex. o chassi dele é de madeira (aquele tipo aglomerado do fundo de guarda-roupas).

Mas eu não tinha dois motores iguais!
Acabei comprando dois motores de passo de 12V, que me pareceram apropriados.
Aqui apareceu a primeira dificuldade com informações: qual o torque recomendado para movimentar um robô de 1 Kg ? Quando descobrí que tinham pouco torque à médias rotações (50 rpm) para o que queria
que o robô fizesse, fiquei em uma sinuca de bico, porque como minha alimentação é uma LIPO de 12,4 volts, não tinha como utilizar nenhum recurso para aumentar o torque!. Foi quando partí para os motores DC.

Um dos recursos utilizados para aumentar (ou compensar) o torque à "altas" rotações em um motor de passo é justamente a técnica chopper. Ela é um PWM que atua no chaveamento da corrente para as
bobinas. Através de uma comparação, se necessário, a bobina é desligada quando a corrente se aproxima da nominal do motor.
A altas rotações, principalmente, o chopper compensa a redução da corrente devido ao pouco tempo do passo e com isso não perde-se tanto torque. Só que para compensar a corrente é preciso alimentar o motor com uma tensão muito acima da nominal!. E isso é justamente o que eu não podia fazer por falta de como alimentar o robô.

Agora vou utilizar motores de 5V (não encontrei de tensão menor - a tal da dificuldade do nosso mercado) com a alimentação de 12V. Estou neste momento iniciando os testes com o driver que construí com o L297/L298. É o L297 quem implementa o chopper.

Como deu sorte com seus motores, acho que pode ficar sem isso. Mas se quiser aumentar o torque dos bichinhos é uma saída, se tiver como alimentar o driver com tensão mais elevada.

Um comentário seu sobre utilização de redutores em motores DC: é praticamente proibitivo. Se me lembro, começa em uns R$350 um redutor, além das dificuldades de acoplamento, fixação, etc...

Pelo que já lí, acho que somente em robôs de batalha se utiliza redutores desse tipo, devido as potências envolvidas.

Outro comentário seu é que encontra os melhores motores (passo) nas impressoras mais antigas.

Parece piada: Há duas semanas achei no lixo aqui perto de casa uma HP Deskjet 8xx (acho que não seja tão antiga, mas não sei). Carreguei ela pra casa e a desmontei em busca de sucatas interessantes (talvez uns motores de passo!). E não é que somente um dos três motores era de passo!. E o menor deles, aquele que sobe e desce o mecanismo de limpeza dos cartuchos. Os outros dois maiores são DC e utilizam encoders de acho umas 1000 ou mais faixas (preto/branco) e aparentemente impressos. Não foi dessa vez que arrumei uns motores de passo na faixa, hehe.

É por isso que comentei que um sistema com motor de passo custa mais que um DC. Se a HP agora usa motores DC deve ficar mais barato né!.

Vou dormir que já não estou enxergando o meu protótipo aqui.

Um abraço,

Wilmar

• ▶ Responder

Permalink Responder até Francesco Artur Perrotti em 14 março 2014 at 7:57

Só uma coisa que acabei descobrindo sobre motores de passo. Você até consegue que ele ande mais rápido carregando carga, mas ele precisa ser acelerado gradativamente, precisa ganhar inércia pra andar mais rápido. O programa que implementei no robô faz com que o movimento sempre comece devagar (velocidade de partida) e vai acelerando até atingir a velocidade de cruzeiro. A mesma coisa pra parar, desacelera até a velocidade de partida antes de parar pra garantir que ele realmente pare onde é pra parar, senão o peso do robô empurra o robô pra frente alguns centímetros além. Agora qual deve ser a velocidade de partida e de cruzeiro depende da carga que os motores movem (o peso do robô). Isso precisa ser calibrado de novo sempre que o robô ganha peso. A versão de acrílico pesa pouco mais de 1.3 kg. Com os motores atuais (200 passos) ele parte com pulsos de 30 ms e consegue chegar a pulsos de 7ms, isso dá aproximadamente 43 rpm, é pouco, mas suficiente pro que eu quero. A próxima versão pretendo que seja mais leve, justamente pra poder andar mais rápido.

O robozinho simplificado que estou montando agora, é muito mais leve, então apesar de usar motores muito mais fracos consegue partir a 100 rpm e chega a 170 rpm. O detalhe é que são motores de 48 passos, então precisa de menos pulsos pra completar uma volta.

Uma dica, pra conseguir motores de passo usados, procure por empresas que fazem manutenção de impressoras. Consegui achar um cara que conserta impressoras e ele me vendeu um saco cheio de motores de passo por algo como 2 ou 3 reais cada um. Depois ele até me deu impressoras completas que ele ia descartar como sucata. Ainda tenho algumas sem desmontar aqui.

• ▶ Responder

Permalink Responder até Wilmar Cassiano Degobbi em 14 março 2014 at 10:17

A questão da aceleração/desaceleração acontece também com motores DC. Por terem mais torque de partida, há risco de patinar na partida e na freada, se for brusca, e aí bagunça a navegação!

Dentro da premissa de mínimo custo que também uso, minhas rodas não são totalmente adequadas, visto serem sucata de um caminhãozinho de plástico, hehe. Acabei colocando uma faixa de câmera de moto no entorno delas para aumentar o atrito.

A última vez que conseguí pesar o meu robô ele estava com 1,55 Kg e não estava com toda a parafernália embarcada. Agora os novos motores de passo pesam 420 Gr cada um. Já estou prevendo ter que aumentar o chassi.

Os motores menores (de 200 passos) que utilizei trabalhavam bem entre 25 e 9 mS, embora a partir de aprox.19 mS ficarem com muito baixo torque, mas conseguiam partir o robô até uns 15!.

A mínima poderia ser menor, mas o 25 é função da velocidade mínima que eu precisava e o diâmetro da roda (80 mm). Com os motores maiores que estou começando a testar agora, é aproximadamente isso também, sem utilizar o recurso chopper do driver. Acho que esses valores devem se aplicar a qualquer motor de 200 passos, aproximadamente.

Aliás, essa questão do torque cair muito a rotações maiores nem chega a ser um grave problema, eu acho, desde que se utilize a aceleração / desaceleração. Digo isso porque numa colisão o robô desacelera rápido!. Usando motoredutores DC de certo porte, essa é outra preocupação, porque a pancada é bem mais intensa e o bicho fica pulando, pois os motores aguentam o tranco e conseguem patinar as rodas!.

Valeu pela dica da manutenção de impressoras. Como acho que exagerei um pouco nos novos motores, assim que cruzar com algum local que faça essa manutenção vou dar uma perguntada.

É isso aí, vamos trocando umas idéias...

Wilmar

• ▶ Responder

Permalink Responder até Wilmar Cassiano Degobbi em 14 março 2014 at 10:38

A última edição não deu certo, então vou concluir aqui:

Preciso reescrever todo o meu código de navegação, além agora dos motores em função da lógica diferente do driver com o L297.

Uma coisa que pretendo mudar é o uso da biblioteca Metro.h. Com o aumento do código, acho que ela está muito trabalhosa, ficando o código muito complexo. Estive fuçando um pouco com a Timer.h que me parece mais potente, embora tenha ficado com algumas dúvidas sobre ela, precisando fazer mais testes.

O que você tem usado nessa área para evitar os "delay" ?

Wilmar

• ▶ Responder

Permalink Responder até Francesco Artur Perrotti em 14 março 2014 at 22:11

Não conheço a biblioteca metro.h. O robô mais completo, de acrílico usa o Wixel como microcontrolador, então uso a biblioteca dele que é bem de baixo nível. Pro outro robô, que usa arduíno eu to usando a biblioteca TimerOne.h que dá acesso ao timer 1 (que tem 16 bits). A função ISR do timer é que controla o tempo dos pulsos e envia os sinais pros pinos de saída.

Eu tentei usar as bibliotecas padrão pra uso de motores de passo do arduíno, mas nenhuma resolveu bem o problema, então acabei criando minha própria biblioteca. Ainda está em uma versão bem inicial, o código que fiz pro wixel está muito mais evoluído, mas funciona, pelo menos pra fazer os primeiros testes, depois pretendo incrementar mais essa biblioteca.

Um dos planos pro futuro é acrescentar suporte para a lógica do L297 (clock, enable, direction, se não me engano). Eu também planejo mudar o robô pra esse tipo de lógica, mas não me atrevo a fazer placas pra isso, vou usar uma pronta, na verdade já até comprei algumas, mas ainda não tive disposição pra encarar todas as alterações de hardware e software que precisam ser feitas.

Estou acrescentando a biblioteca aqui, vc pode usar ou fazer teu código baseado nela. A biblioteca implementa uma classe principal, StepperRobot, que cuida de gerar os pulsos já considerando aceleração e desaceleração e sincronizar os dois motores para produzir os movimentos previstos.

No momento só tem os movimentos básicos: linha reta, giro e curva sobre uma roda. Também tem o freio que não é exatamente um movimento mas está na lista. O freio liga a bobina sem mover o motor. As rodas ficam travadas na mesma posição. A intenção desse movimento é preparar o robô pra um impacto eminente, não deve ser usado por mais de um ou dois segundos pq pode queimar as bobinas se elas estiverem ligadas sem algum limitador de corrente, além de acabar com a carga bateria.

O mesmo aviso vale para a curva sobre uma roda. Uma roda fica travada na mesma posição enquanto a outra anda fazendo um circulo. A roda que fica travada está com a bobina ativada, não deve ficar nesse estado por muito tempo. Aliás, você me deu uma ideia pra melhorar esse código, posso usar algo como um pwm pra travar as rodas sem arriscar a queima das bobinas, depois vou pensar como fazer isso.

Abaixo a lista de movimentos implementados:

#define mvAhead  0
#define mvBack   1
#define mvSpinL  2
#define mvSpinR  3
#define mvTurnL  4
#define mvTurnR  5
#define mvBrake  6

Como a classe está ainda muito básica, o uso é bem simples. Já tem uma instancia do robo criada (rob) mas precisa ser inicializada no setup. Também é preciso informar quais pinos serão usados para cada motor:

void setup() {
  // Led de status
  pinMode(statusLed, OUTPUT);    

  rob.init(stepsPerRevolution, startSpeed, cruizeSpeed, pulsesToCruize);
  rob.initRightMotor(4,5,6,7);
  rob.initLeftMotor(9,10,11,12);
  rob.turboOn();
}

No exemplo já to ligando o modo turbo pra dar mais torque, mas pelo jeito vc não vai precisar disso.

Serio mesmo? 420 gr cada motor? Eu uso um par de nema 14 que pesam 180gr cada e funcionam com 2.7 volts. Com esses motores eu acho que vc consegue que o robo te carregue em cima dele :)

Estes são os que eu uso: http://www.pololu.com/product/1209


Voltando à biblioteca, depois pra ativar os movimentos é só chamar o método move informando qual movimento e por quantos pulsos ele deve ser mantido:

rob.move(mvAhead, 100);

Nesta versão ainda não dá pra empilhar movimentos, então esse método ignora chamadas quando o robo está se movendo, mas isso é o que eu pretendo resolver na próxima versão.

Abaixo um programa que fica repetindo todos os movimentos:

#include <TimerOne.h>
#include <StepperMotor.h>
#include <StepperRobot.h>

#define stepsPerRevolution  48  // Passos por volta. Assume-se que os dois motores são iguais
#define startSpeed          90  // velocidade de partida (pulsos por segundo)
#define cruizeSpeed        140  // velocidade de cruzeiro (pulsos por segundo)
#define pulsesToCruize      72  // quantos pulsos para chegar em cruzeiro

#define statusLed           13  // led onboard para status

void setup() {
  // Led de status
  pinMode(statusLed, OUTPUT);    

  rob.init(stepsPerRevolution, startSpeed, cruizeSpeed, pulsesToCruize);
  rob.initRightMotor(4,5,6,7);
  rob.initLeftMotor(9,10,11,12);
  rob.turboOn();
}


int trecho = -1;


#define turnPulses 317
#define spinPulses 155


void loop() {
  // led de status
  unsigned long ms= millis();
  digitalWrite( statusLed, (ms >> 8) & (ms >> 6) & 1); // heart beat
 
  if(!rob.isMoving())
  {
    delay(150); // espera baixar a poeira do movimento anterior

    trecho= (trecho+1) % 7;
    switch(trecho)
    {
      case 0:
        rob.move(mvAhead, stepsPerRevolution*4);
      break;
      case 1:
        rob.move(mvBack, stepsPerRevolution*4);
      break;
      case 2:
        rob.move(mvSpinL, spinPulses);
      break;
      case 3:
        rob.move(mvSpinR, spinPulses);
      break;
      case 4:
        rob.move(mvTurnL, turnPulses);
      break;
      case 5:
        rob.move(mvTurnR, turnPulses);
      break;
      case 6:
        rob.move(mvBrake, startSpeed);
      break;
    }
  }
}

Anexos

• StepperRobot.rar, 3 KB

• ▶ Responder

Permalink Responder até Wilmar Cassiano Degobbi em 15 março 2014 at 19:15

Eu também optei por não utilizar bibliotecas para motores de passo considerando a finalidade de aprendizado.

Fiz minhas próprias funções: execução de um passo dado o tempo (período do pulso) e sentido; andar para frente e para trás em três velocidade (posteriormente implementei uma aceleração entre as velocidades, mas devido a forma que desenvolví as demais rotinas não ficou muito bom), parar, rotacionar e virar para os lados (com as diferentes combinações de rotação por roda). Exceto a aceleração, o restante funciona perfeitamente.

Uma coisa que não fiz, foi a utilização de um timer para controle dos step´s. Implementei na raça mesmo, utilizando micros(), calculando um tempo decorrido e comparando com o desejado. Para não "travar" a rotina, implementei uma comparação de espera somente se o tempo decorrido ficasse uns 80% acima do desejado. Para não haver conflito entre os motores, as rotinas impoem um delta tempo entre os motores, mas de fato sempre acaba ocorrendo conflito com a variação de rotação dos motores (em curvas), embora esse conflito apenas atrase um pouco um step e não é perceptível.

Como você fez um exposição detalhada da sua biblioteca e eu vou ter que modificar as minhas agora, vou dar uma olhada na sua com calma e cuidado, pois posso aproveitá-la para passar a utilizar um timer. Obrigado por disponibilizá-la Francesco.

Quanto à questão com as bibliotecas Metro e Timer, na verdade a pergunta que não deixei bem claro era na lógica de navegação e não no acionamento dos motores.

No meio de minhas dificuldades com os motores DC eu comecei - e depois parei - a alterar meu código para implementar funções "de alto nível" para a navegação, passando a considerar andar para frente, p. ex. "de médio nível". As funções de alto nível seriam algo como, andar para frente e desviar dos obstáculos encontrados com uma determinada tendência (p. ex. sempre para a esquerda) até andar x metros, seguir uma linha, andar paralelo à uma "parede", etc... Essas funções não podem bloquear o processamento porque outras coisa têm de ser feitas em paralelo. Assim elas seriam chamadas pelo principal "loop" (main) a cada scan.

A idéia por trás disso é deixar a programação do robô facilitada para p. ex. programar um sequenciamento de objetivos, tipo algo parecido com as competições da DTU.

Quando se começa a estruturar isso, principalmente utilizando motores DC, aparece a necessidade de utilização de inúmeros "timers" e foi onde a bilioteca Metro que estava usando começou a complicar. Talvez agora voltando aos de passo não seja necessário tantos "timers" e possa manter a Metro mesmo.

Com relação aos motores que você está utilizando agora (referència Polulu) eu não achei nada parecido no mercado nacional. Você os importou ?
Um motor de 2,7 Volts e 1A era tudo que eu queria quando comprei os NEMA 23 de 5V e 0,7A. Só pela corrente dá pra ver que são motores com bom torque. O meu antigo NEMA 17 de 12V é de somente 100 mA em unipolar!!!

Eu não sei com que tensão você está alimentando esses motores, mas pela sua preocupação com manter uma bobina energizada, acredito ser com tensão maior que a nominal do motor. Se for isso, o chopper provido pelo L297 mantém a corrente na bobina dentro do nominal e pode-se, teoricamente mantê-la energizada por algum tempo.

Francesco, mais uma vez obrigado pela biblioteca, valeu!

Vamos trocando idéias, que sempre aparece alguma coisa que a gente ainda não fez!.

Lembrei de uma outra coisa: você comenta sobre empilhar comandos.
Na última versão do meu robô com motores de passo, eu estava utilizando e pretendo continuar com os novos motores e driver, um Arduino Nano para o stepping dos motores eoutras pequenas funções e um Arduino UNO para a lógica de navegação, e passava a rotação e sentido de cada motor por um byte transferido do Uno para o Nano por I2C (TWI). Isso já me permitiria transferir p. ex. dois bytes, antecipando o próximo movimento. Não sei se o seu empilhamento seria para isso, entendí que sim. Acontece que apareceu um problema que tinha como contornar, mas complicaria as rotinas dos dois lados: e se o robô encontra-se um obstáculo entre as duas informações? Precisaria ser descartado o último movimento futuro!. Daí me fez pensar e cheguei a uma conclusão que não teria proveito antecipar um movimento para os motores. Tá certo que é diferente de antecipar um movimento de alto nível, que demande maior processamento.

Wilmar

• ▶ Responder

Permalink Responder até Francesco Artur Perrotti em 15 março 2014 at 19:01

Uma atualização, consegui implementar uma especie de pwm pra travar as rodas na mesma posição, agora nessa situação o tempo do pulso é dividido em 16 partes e "pisca" 8 vezes em vez de ficar ligado direto. O consumo de corrente caiu pela metade sem comprometer a precisão do movimento, além disso a corrente não consegue subir demais mesmo com as rodas travadas por um tempo longo. Muito mais seguro, ficou bem melhor assim.

• ▶ Responder

Permalink Responder até Wilmar Cassiano Degobbi em 15 março 2014 at 19:18

Excelente idéia Francesco.

Fiz um comentário na resposta anterior sobre isso, de que o L297 faz exatamente isso.

Você implementou um PWM sem um hardware específico!.

Wilmar

• ▶ Responder

Permalink Responder até Wilmar Cassiano Degobbi em 15 março 2014 at 19:20

Francesco,

Fui tentar fazer download da sua biblioteca mas parece estar travada, deu sem prermissão de acesso.

Wilmar

• ▶ Responder

• ‹ Anterior
• 1
• 2
• 3
• …
• 5
• Próximo ›
• Página