-
Boas.
Estou a iniciar um mino projecto que têm como objectivo regular a velocidade de um motor através dum potenciometro,
estou a utilizar um potenciometro dos grandes (com carapuça :P) e estou alimentá-lo normalmente e sair para o -, o pino do meio ligo a uma entrada analogica do arduino,
e a minha questão é: à medida que vou rodando o potenciometro ele nao deveria variar um valor de 0 a 1023?, o que me está acontecer é que sem mecher nele ele dá me valores mesmo de 0 a 1023..
estou a utilizar o seguinte código:
int pot_pin = 0;
int valor = 0;
void setup(){
Serial.begin (9699);
}
void loop(){
valor = analogRead(pot_pin);
Serial.println(valor);
delay(500);
}
-
correcção do código:
int pot_pin = 0;
int valor = 0;
void setup(){
Serial.begin (9600);
}
void loop(){
valor = analogRead(pot_pin);
Serial.println(valor);
delay(500);
}
-
Boas.
Primeiro, para fazeres correcções, podes editar o post, não precisas de postar uma resposta a ti mesmo.
estou a utilizar um potenciometro dos grandes (com carapuça :P) e estou alimentá-lo normalmente e sair para o -, o pino do meio ligo a uma entrada analogica do arduino,
Então e a 3ª perna? Não devias ligá-la ao 5v?
Resumindo:
Potênciometro -> Arduino
pin 1 -> GND
pin 2 -> Analog X
pin 3 -> 5v
É isto que tens?
-
sim é isso.
-
ja resolvi o problema, não me estava a chegar alimentação á placa onde tenho o potenciometro, os fios estavam a fazer mau contacto...
obeigado por responderes microbyte, eu vou dando novidades da evolução do projecto:)
-
Esqueceste-te do "Editar" outra vez... :P
BTW, ainda bem que já está resolvido...
Mais uma vez, uma situação em que a solução era desligar tudo e montar outra vez...
-
Boas...
Aqui deixo um video do regulador de velocidade concluido com a respectiva programação,
Regulação de velocidade de um motor DC!!.MPG (http://www.youtube.com/watch?v=rYqCRmFwb8A#)
int switch1_pin =2;
int switch2_pin = 4;
int pot_pin = 0;
int pin1 = 3;
int pin2 = 10;
int botao1_antes = 0; //valor do botão1 antes de ser premido!
int botao2_antes = 0; // " " botão2 antes de ser premido!
int val_pot = 0;
void setup(){
pinMode(switch1_pin, INPUT);
pinMode(switch2_pin, INPUT);
Serial.begin(9600);
}
void loop(){
val_pot = map(analogRead(pot_pin), 0,1023,50,255);
Serial.println(val_pot);
delay(200);
if((digitalRead(switch1_pin) == LOW) && (botao1_antes == 0)){
analogWrite(pin1, 0);
analogWrite(pin2, val_pot);
botao1_antes = 1;
}
else{
if((digitalRead(switch1_pin) == LOW) && (botao1_antes == 1)){
analogWrite(pin1, val_pot);
analogWrite(pin2, 0);
botao1_antes = 0;
}
if((digitalRead(switch2_pin) == LOW) && (botao2_antes == 0)){
analogWrite(pin1,0);
analogWrite(pin2, 0);
botao2_antes = 1;
}
if ((digitalRead (switch2_pin) ==LOW) && (botao2_antes == 1)){
analogWrite (pin1, 0);
analogWrite (pin2, 0);
botao2_antes = 0;
}
}
}
espero que tenham gostado e, claro, com que este tutorial venha a ser útil a alguém.. ;)
-
se o que queres fazer com o teu motor é clicar no botão da direita e ele rodar para a direita e só parar quando voltares a carregar novamente, e o mesmo no botão da esquerda, só que em sentido contrário é fácil.
O que tu estas a fazer neste monto é dizer ao arduino que enquanto o botão estiver a ser clicado ele anda.
o que tens que fazer é:
clicas no botao e a variável 'a' fica a '1'
voltas a clicar no botao a variável 'a' fica a '0'
depois testas:
se a variável 'a' for '1' entao o motor anda
se a variável 'a' for '0' o motor para
qualquer duvida vai postando!!
-
se poderes posta uma foto dos motores que estas a utilizar e das rodas, gostava de visiona-las melhor!!
-
Também achei as rodas muito interessantes :P Mostra lá isso ;)
-
Boas nuno.. obrigado responderes.. eu daqui a pouco ou amanha tento da forma que disseste, estou agora de volta do seguidor de linhas e não me dá muito geito retirar-lhe o arduino agora,.
Boas msaleiro, as rodas são de alumínio (não fui eu que as fiz, foi o meu pai lá na fábrica)...o revestimento à volta delas que vês são dumas correias velhas , colei para aumentar a aderência ao solo das rodas e também para ficarem com um melhor aspecto, só que a colagem como ves não ficou perfeita, estava mais preocupado em não ficar com os dedos agarrados à cola 3 do que em colar aquilo como deve ser :P, as rodas de lado tem um furo e um parafuso là dentro, ao colocar as rodas nos motores coloco com a parte do parafuso virada para a "ranhura " que os motores têm e aperto com uma chave de um buraco para fixar as rodas...
http://img85.imageshack.us/i/dsc08189.jpg/ (http://img85.imageshack.us/i/dsc08189.jpg/)
http://img693.imageshack.us/i/dsc08190m.jpg/ (http://img693.imageshack.us/i/dsc08190m.jpg/)
-
Parecem estar mt boas! Pelo menos têm bom aspecto! Obrigado pelas fotos e pela explicação :) Boa sorte com o resto do projecto
-
Olá pessoal.
O controlo que aqui temos é "open-loop" o que para uma grande parte das coisas funciona, mas se quisermos fazer correctamente por exemplo um robô com locomoção diferencial, precisamos que ambos os motores tenham exactamente a mesma velocidade de forma a andar em linha recta!
Para isso seria melhor usar um controlador do tipo "closed-loop" e implementar um mais que conhecido controlador PID para o controlo da velocidade.
Já fiz qq coisa deste estilo para uma cadeira na universidade e funcionava, mas estava longe dos resultados que gostaria de obter, alguém aqui tem experiência em implementar este tipo de controladores num micro controlador?!
Entretanto deixo um documento que encontrei e que gostei bastante, relata a concepção de um controlador PID analógico e faz o confronto dos resultados obtidos por simulação (matlab/simulink) com a tão esquecida dos professores universitarios REALIDADE.
http://asl.epfl.ch/research/projects/VtolIndoorFlying/rapports/rapportSemStauffer.pdf (http://asl.epfl.ch/research/projects/VtolIndoorFlying/rapports/rapportSemStauffer.pdf) (em inglês)
Cumprimentos, Mauro.
-
Um controlador PID é algo que quero bastante fazer um dia. Dei uma vista de olhos nesse pdf e parece realmente estar muito interessante, vou ter que ler melhor.
Pensei num controlador PID quando tive vontade de fazer um "self balancing robot" mas essa de por dois motores à mesma velocidade é capaz de ser um melhor ponto de partida (ou manter a velocidade independentemente da inclinação do chão). Acho que a maior dificuldade é arranjar um modelo matemático para o sistema e a partir daí sacar as constantes.
-
Pelo que já andei a ver, e dos (pcos) conhecimentos :D que tenho de controlo.
Podemos conseguir o modelo matemático do sistema através do conhecimento da resposta a degrau do sistema.
Agora falando mais terra a terra, a ideia é ter o motor parado e mando-lo andar(entrada em degrau) e verificar a evolução da velocidade em ordem ao tempo. Vamos ficar com algo deste género:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.scielo.br%2Fimg%2Frevistas%2Fcta%2Fv24n3%2F21946f1.gif&hash=3fc7bef6efbd53e8d188b52589c0f3a8fae7857f)
Em que o Y(t) do gráfico pode ser por exemplo RPMs ou m/s.....
Depois conhecendo os valores assinalados na figura por Td, Z e o podem ser calculados os primeiros ganhos para o termo P,I e D pelo método de Ziegler–Nichols através das equações:
http://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method (http://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method)
Estes valores são aceitáveis mas não são a solução óptima.
Uma das minhas maiores dificuldades prende-se com relacionar a saída dos cálculos PID com o duty cycle do sinal PWM que temos de fornecer ao motor, talvez alguém saiba explicar-me isto.
Cumprimentos, Mauro.
-
Sim em geral nas simulações usam-se "escalões" (step) na entrada. O significado prático dessa entrada é uma "variação brusca" que em geral é o que temos na realidade (motor parado -> motor em movimento com velocidade constante). Por exemplo no grafico que colocaste punha-se um escalão de amplitude Bu que é o valor de referência que queres ter à saída.
O que tens a fazer em primeiro lugar é arranjar uma EQUAÇÃO matematica que te modele o sistema físico (uma coisa do genero y(t) = velocidade(t) - constante_de_atrito*v(t)). Aplicas-lhe transformadas de laplace e ficas com a chamada "função de transferência". Essa função de transferencia corresponde a um bloco no simulink que é o que modela o teu sistema físico.
A partir daqui tambem não tenho as ideias bem acentes... Mas aqui vai um pouco de brainstorming:
Os blocos que ficam à volta, são os blocos do PID em si que tem a parte proporcional, integral e diferencial e vão fazer com que o a saída do sistema se mantenha o mais proximo do valor de referencia (Bu) possivel. Cada um desses três blocos tem um ganho e são esses tres ganhos que interessam determinar através da simulação.
Na realidade, deves saber a velocidade "real" do motor (através de um encoder ou óptica) e com base nisso aumentar ou diminuir o PWM (tendo em atenção valores limite).
Deixo mais uns links para referência:
http://atmel.nl/dyn/resources/prod_documents/doc2558.pdf (http://atmel.nl/dyn/resources/prod_documents/doc2558.pdf) (vê este, está muito bom! na página da atmel tens codigo de um controlador PID - basta inserires os valores das constantes - já pronto a enviar para um microcontrolador, provavelmente assim já consegues perceber melhor onde entra a parte do código em que alteras o PWM)
http://bestune.50megs.com/more.htm (http://bestune.50megs.com/more.htm) (exemplo de um esquema no simulink)
-
Olá msr, obrigado pela resposta.
Eu compreendo o funcionamento e a teoria, mas agora falta passar para a realidade.
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.cs.brown.edu%2F%7Etld%2Fcourses%2Fcs148%2F02%2Fimages%2Fpid.gif&hash=c6d586bd2e7ea9a81f1a47a47adab0cdf91dcaec)
Na imagem da para mostrar a estrutura básica do controlador PID, em que se pode ver os blocos do controlador propriamente dito, seguido do bloco designado por M que é o processo (o motor, caixa de engrenagem, etc) e a realimentação. Tendo o conhecimento destes blocos é possível simular o comportamento do sistema.
Como o msr disse é necessário medir a velocidade do motor para dps comparar com a velocidade pretendida, esta parte é fácil de implementar por exemplo tendo o motor um encoder óptico e dps contam-se os pulsos através de um contador num microcontrolador e uma base de tempo constante.
Cumprimentos, Mauro.
-
Aleluia alguem fala de PID Controlers (em português Controlo Proporcional Integral Derivativo) no fórum (não fosse ele de robótica)!
Há já algum tempo que ando a estudar isto a sério (tenho feito experiências e simulações com resultados bastante interessantes) e andava com ideias de começar a partilhar aqui mais informação, mas sendo assim, sugiro que criem um tópico para se falar de PID :D que dizem?
Não querendo fazer um post Off-Topic, vou dizer algo sobre este!
Ora bem, na minha opinião criar um algoritmo de controlo proporcional integral derivativo é ligeiramente exagerado... Já para nao falar dos custos absurdos de motores com encoders (minimamente razoaveis)!
A aproximação sugerida pelo nunosilvarocha é a mais indicada para esta situação. Contudo o maurosmartins tem toda a razão qd diz que este é necessario para a locomoçao diferencial de um robot. Até digo mais, para a locomoção de um robot, não usar algum tipo de algoritmo deste género é ridiculo! A não ser que não se queria ter qualquer tipo de controlo sobre o movimento do robot e se queira que este não ande a direito!
Olhando duma prespectiva muito muito muito simplista e já um tanto ou quanto abstracta poderia considerar-se a ideia do nunosilvarocha uma implementação de um closed-Loop :P!
-
Olha que este semestre no trabalho prático que me calhou foi feito um PID em atmega8 com bons resultados no controlo de um pêndulo invertido. Só que o meu grupo na parte do TP fez o PID analógico. No entanto há por aí uns quadrotors com 3 controladores PID's, um para cada eixo e estão implementados em Arduino num atmega328p.
-
Eu não disse que não dava para fazer com um pequeno Atmega, disse que para este projecto não valia a pena (ate pq os custos de o motor com encoder razoavel sao muito altos +/- 300 euros)! Um PID já razoável não deverá ocupar mais do que uns 800 a 1000 bytes! Qualquer micro hoje em dia já dá para isto. ;)
Não entendi bem essa resposta, há alguma intenção por aí?
-
esquece, quando disses-te isto
Ora bem, na minha opinião criar um algoritmo de controlo proporcional integral derivativo é ligeiramente exagerado...
na primeira vez que li fiquei com a impressão que tinhas dito que era exagerado para um micro. Tu estavas-te a referir que era exagerado só para controlar motores.
-
Viva pessoal!
Ainda bem que há mais pessoas que estão interessadas neste assunto! :D
tr3s, disseste que tinhas algumas feitas com resultados interessantes, gostaria de saber do que se trata, qualquer coisa ajuda :)
Mas quanto a mim acho k não é demasiado fazer um controlador PID para motores, eu acho k é mesmo imperativo! Pelo que tenho andado a ler o algoritmo nao é assim tão complicado, o que eu nao consigo perceber e já falei disso é como ajustar o dutty cycle do PWM em função do resultado do PID...
Quanto a motores com encoders, é claro que são mais caros que os normais, mas existem motores para pequenos robos, já com encoder e caixa de redução por cerca de 30€ como por exemplo este:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.robot-electronics.co.uk%2Facatalog%2Femg30a.jpg&hash=01284619cf149b3de06578cebd75c8fb1277c211)
E existe uma espécie de upgrade para os servos que permite colocar um encoder embora que de baixa resolução é bastante útil.
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.nubotics.com%2Fgraphics%2Fww01-kit_lg.jpg&hash=b5eb2734b96b9456c377402b0d17c932dd9f6448)
Também existem PICs (vá digam mal :P mas eu sou um gaijo dos PICs :D ) que tem um periferico chamado QEI que vem de Quadrature Encoder Interface e permite o acoplamento directo de encoders com saida em quadratura ao microcontrolador, quando o tempo o permitir vou usar uma placa que já tenho desenhada com um destes microcontrolador mas com dois modulos QEI (um para cada motor de uma base diferencial)
Agora falta o PID... :'(
É verdade como o metRo_ disse para arduino já existe uma biblioteca que implementa um controlador PID.
Pode ser que todos juntos consigamos fazer alguma coisa!
Cumprimentos, Mauro.
-
Não sei como te hei-de explicar esta parte mas basicamente a saída do PID é o valor do dutty-cicle.
-
Mas quanto a mim acho k não é demasiado fazer um controlador PID para motores, eu acho k é mesmo imperativo! Pelo que tenho andado a ler o algoritmo nao é assim tão complicado, o que eu nao consigo perceber e já falei disso é como ajustar o dutty cycle do PWM em função do resultado do PID...
Quanto a motores com encoders, é claro que são mais caros que os normais, mas existem motores para pequenos robos, já com encoder e caixa de redução por cerca de 30€ como por exemplo este:
E existe uma espécie de upgrade para os servos que permite colocar um encoder embora que de baixa resolução é bastante útil.
É verdade como o metRo_ disse para arduino já existe uma biblioteca que implementa um controlador PID.
Pode ser que todos juntos consigamos fazer alguma coisa!
Cumprimentos, Mauro.
Mauro, tens razão quando dizes que para controlar motores convém usar PID, mas é quando queres controlar movimentos e necessitas de precisão. Por exemplo, um micromouse.
Tens de me mostrar o link para esse motor para ver que tipo encoder isso tem, estou curioso quanto à resolução dele... E a caixa de redução não me agrada nada...
Esses encoders que se podem acoplar a servos e a motores DC são uma verdadeira bosta servem para praticamente nada! :D haha
Brevemente partilharei aqui mais informação, mas se tiverem dúvidas é só perguntar que responderei logo que possível e dentro dos meus limites :D
Vi um algoritmo de PID no sitio do Arduino e quase que me deu vómitos. Não sei se é o mesmo mas se é um com uma data de funções e etc.... não estou a dizer que está errado porque não está, usa a teoria toda e faz as contas certas mas em termos de optimização deixa muito a desejar... Vejam pelo espaço ocupado...
-
Estão a falar deste certo? http://www.arduino.cc/playground/Code/PIDLibrary (http://www.arduino.cc/playground/Code/PIDLibrary)
Também não me agradou muito...
Dêem uma olhadela no codigo do AVR211 http://www.atmel.com/dyn/Products/app_notes.asp?family_id=607 (http://www.atmel.com/dyn/Products/app_notes.asp?family_id=607) (cliquem no disco para sacar o codigo). Eu na altura que andei a pesquisar mais sobre este assunto estava com a ideia de tentar fazer código para um hipotético controlador PID mas depois de ver este da Atmel esqueci completamente a ideia ;D Não é que o já tenha experimentando, mas parece-me muito bom.
Para compilar é usado isto: http://www.iar.com/website1/1.0.1.0/675/1/ (http://www.iar.com/website1/1.0.1.0/675/1/) (kickstart edition é gratuita)
Edit: ja agora, este PID ocupa apenas 534bytes
-
O PID que eu vi estava dentro de um do projecto de um quadcopter mas não me lembro qual, assim que o vir outra vez posto aqui.
-
Viva pessoal.
Tens de me mostrar o link para esse motor para ver que tipo encoder isso tem, estou curioso quanto à resolução dele... E a caixa de redução não me agrada nada...
Esses encoders que se podem acoplar a servos e a motores DC são uma verdadeira bosta servem para praticamente nada! :D haha
Bem os motores e soluções que mostrei são para pessoas (como eu :D ) que tem low budget e tambem para pequenos robos, por isso é normal os motores nao serem os ideais, tambem preferia um Pittman ou melhor ainda um Maxon, mas são mto caros e o pior é que nem os que mostrei tenho :D loool
Não sei como te hei-de explicar esta parte mas basicamente a saída do PID é o valor do dutty-cicle.
metRo_ talvez na biblioteca do arduino isto se verifique, mas por exemplo basta eu usar um cristal diferente que os valores de frequencia e PWM já sao diferentes no entanto as "contas" do PID mantem-se, posso estar a pensar mal, mas ainda nao compreendi esta parte.
Cumprimentos, Mauro.
-
Como eu te compreendo!
Também ando a procura de uma solução mais "barata" para ter feedback dos motores ao mesmo tempo que consigo manter-lhes uma boa velocidade. Já estive a ver esses que mostraste, tem uma resolução razoável e comparando com o preço até é boa. Infelizmente são muito grandes e muito "bêbados" para o que eu procuro.
Mas digo que são "excelentes" para robots de tamanho intermédio e low-cost!
Eu ainda preferia uns faulhaber Mauro ;)
-
metRo_ talvez na biblioteca do arduino isto se verifique, mas por exemplo basta eu usar um cristal diferente que os valores de frequencia e PWM já sao diferentes no entanto as "contas" do PID mantem-se, posso estar a pensar mal, mas ainda nao compreendi esta parte.
Aquilo que eu disse verifica-se numa aplicação de um PID. Eu nunca vi essa biblioteca que vocês falam.
-
Eu nunca vi essa biblioteca que vocês falam.
não será esta? http://www.arduino.cc/playground/Code/PIDLibrary (http://www.arduino.cc/playground/Code/PIDLibrary)
-
Sim é essa, eu só estava a dizer que o que tinha dito não foi baseado nessa biblioteca nem em nenhum outra.
-
Boas.
Era só para avisar que alterei "uma parte deste post" que tinha exposto anteriormente, o regulador de velocidades e respectiva programação já se encontram aqui (podem ver na 1ª página).
Ps: peço desculpa, mas não sabia que ao modificar o post este não aparecia nos "post´s mais recentes",pois é a primeira vez que o faço, e como não sei se alguém estava a acompanhar este tutorial decidi avisar. Espero agradar-vos ;)
-
olha que tens as identações do código mal alinhadas ;)
experimenta fazer o seguinte: no IDE do arduino, seleccionas todo o código (Ctrl+A) e de seguida vais ao menu Edit e carregas em "Copy for forum" (Ctrl+Shift+C). De seguida colas aqui ou noutro post quando precisares de partilhar código, fica muito mais legível! :)
-
Já coloquei como disseste ;)
Obrigado Tiago :)