LusoRobótica - Robótica em Português
Robótica => Iniciantes => Tópico iniciado por: projectoAREA em 30 de Outubro de 2010, 20:51
-
Boas,
Vamos começar a planificar o nosso projecto, na sua parte mais técnica. Antes de mais, o conceito: um robot que se consiga desviar de obstáculos num plano horizontal, fazendo um percurso de A a B. O robot deve ter sensores de posição ou distância e rodas omnidireccionais. Corrijam-nos se estivermos enganados. Os nossos conhecimentos sobre robótica, programação e electrónica são ainda muito elementares. Contamos com a nossa vontade :D e também com o tempo que temos para concretizar o projecto: temos até Dezembro para ter a investigação feita e adquirir o material e até à Páscoa para ter o robot operacional. Digam-me, com a vossa experiência, se aquilo que temos em mente é possível.
Já pesquisámos um pouco sobre microcontroladores e pelo que percebemos, neste fórum trabalha-se mais com Arduino. Nós não conhecemos nenhum desses microcontroladores, por isso, também não temos preferências. Tendo em conta os nossos objectivos, Arduino continua a ser a opção mais viável?
Agradeciamos que respondessem a estas perguntas. À medida que formos avançando na nossa pesquisa, de certeza que mais questões vão surgir, mas também mais respostas ;)
projectoAREA
-
É aconselhável a utilização do Arduino por iniciantes pois é barato (+/- 25€) e é muito fácil de começar a trabalhar com um bichinho destes.
Em relação ao robot... Entre o percurso de A até B é em linha recta, segue linhas, como estão a pensar fazer isso? É que o robot tem de "seguir" ou dirigir-se para algum ponto.
Bom trabalho!
-
Err, desculpem por não ter sido mais específico. Quando dissemos percursos de A a B o que queríamos dizer era que o robot não se limitava a andar à toa a fugir dos obstáculos. Se conseguirmos fazer demonstrações do robot na escola, seria engraçado pedir às pessoas que dispusessem os obstáculos na área de movimento do robot (chão, mesa, vamos ver) e ele deslocar-se de uma ponta dessa área à outra, desviando-se dos obstáculos. Sem linhas auxiliares marcadas no chão. Ou orientamos o robot no início e programamos para ele não perder essa orientação (por exemplo, deslocando-se lateralmente em vez de rodar ou através de um servo com "memória") ou qualquer coisa desse género. Ainda estamos a definir esses pormenores, até porque não sabemos bem o que é possível programar no robot.
Cumps
-
Têm ou tiveram alguma aula/experiência de programação e/ou algoritmia?
-
Rodas omnidirectionais, acho que estão a pedir muito xD. Penso que seja mais fácil de usar e arranjar rodas normais, e depois o robô controla-as para virar quando necessário.
Sensores de posição, também acho que é um pouco pedir muito ... pode ser que consigam construir um se usarem a imaginação xD.
Sensores de distâncias, têm vários à vossa disposição ... pelo que percebi da descrição do projecto, um adequado seria: http://loja.lusorobotica.com/158-sharp-gp2y0a02yk0f-infrared-proximity-sensor-long-range.html (http://loja.lusorobotica.com/158-sharp-gp2y0a02yk0f-infrared-proximity-sensor-long-range.html) (ou outro sharp), ou podem tentar fazer uns com recurso a LEDs IV e fototransístores IV.
Para o vosso projecto, aconselho que comecem por estudar bastante electrónica e programação primeiro, para perceberem bem o que precisam, porque precisam, e como usar o que precisam.
Uma descrição mais detalhada dos obstáculos e do caminho entre A e B seria uma boa ideia, para podermos ajudar melhor.
-
Podem fazer qualquer coisa como isto:
- Anda sempre em linha recta;
- Quando detecta o objecto vira durante X segundos para a direita, depois segue mais X segundos "em frente, paralelamente à recta do circuito" e de novo mais X segundos para a esquerda, de forma a contornar o obstáculo e continuar depois na mesma linha recta.
Não é uma solução muito "branco no preto", mas acho que pode servir. ;)
-
Podem fazer qualquer coisa como isto:
- Anda sempre em linha recta;
- Quando detecta o objecto vira durante X segundos para a direita, depois segue mais X segundos "em frente, paralelamente à recta do circuito" e de novo mais X segundos para a esquerda, de forma a contornar o obstáculo e continuar depois na mesma linha recta.
Não é uma solução muito "branco no preto", mas acho que pode servir. ;)
No fim disso ainda tem de virar 90 graus á direita para continuar em frente.
Aconselho a ler os tutoriais de como usar o arduino, e procurar o tópico do Smalluino criado pelo TigPT, depois acho que fazerem o robot ir do ponto A ao B com obstaculos e sem linhas é definitivamente muita areia para a vossa camioneta, efectivamente se tudo correr muito bem no vosso grupo devem demorar uns meses até ter um robot que seja capaz de se mexer com acções programadas, mais um tempinho para o ensinar a seguir uma linha, depois de ele seguir uma linha sem nunca perder a linha podem começar a pensar em meter um obstaculo e ele conseguir desviar-se do obstaculo e voltar a seguir a linha, acho que um segue linhas que se desvia de obstaculos é um bom objectivo para o final do ano.
Quanto a micro-controlador aconselho o arduino pela facilidade de uso e pela enorme comunidade que ele tem, quanto ao resto é ler o tópico do Smalluino.
-
No fim disso ainda tem de virar 90 graus á direita para continuar em frente.
Quando disse para depois continuar na linha recta definida é obvio que o robot irá precisar de várias instruções e não é assim tão fácil e linear... Com o Arduino torna-se mais fácil, mas não deixa de ter a sua dificuldade.
Comecem por fazer um robot ridículo, e vão aperfeiçoando o animal depois.
-
Obrigado pelas respostas,
Pelo que vemos o melhor é descer uns degraus naquilo que temos em mente :D . Quer dizer, vocês já devem ter feito alguns robots e portanto, têm sempre a experiência do vosso lado.
Mas diz-nos senso, não é possível para nós enquanto nabos da robótica :) conseguir ter um robot que se mova sem auxílio de linhas, ou seja, com a condução diferencial do género do Smalluino? Sabemos que isso tem a ver com as variações da corrente que são dadas a cada motor e fazem com que eles rodem num sentido ou no outro e dessa forma, conjugados, fazem com que o robot se mova de determinada maneira. Visto assim, não parece muito díficil (mais uma vez não sabemos se estamos a dizer parvoíces). É preciso ligar cada motor ao Arduino e depois definir, em código, os casos possíveis (aqueles que o nelsonPRSousa tem no post (http://lusorobotica.com/index.php?topic=2918.msg30016#msg30016)dele), certo?
Acerca da detecção de movimentos, também já pesquisámos sobre fototransístores e como o robot escolhe para que lado se mover, consoante as leituras de intensidade luminosa em cada fototransístor. Mas estes podem ser muito sensíveis às condições exteriores e prejudicar a acção do robot, não é?
Cumprimentos
-
Os meus conhecimentos são, por enquanto, minimamente informativos (pelo que leio e pelo que me dizem), no entanto, acho que o que vocês podem fazer é similar ao que eu vou fazer.
Inicialmente vou fazer um género de Smalluino, mas apenas um pouco mais avançado... Terá 2 rodas, uma ball-center de apoio, o arduino, 2 motores, uma ponte de H para controlar os motores, o suporte das pilhas (com condensadores). Este primeiro robot apenas irá seguir uma trajectória que eu definir na programação (por exemplo: andar 3 segundos para a frente, depois 3 segundos para a direita, etc).
Só de seguida, e quando o robot estiver a fazer o primeiro passo correctamente, é que avanço para algo mais complexo (que ainda assim não tem grande coisa de complexo).
Parte das explicações que vês no tópico que abri é para a 2º parte do robot, que para aproveitar o que pago de portes, queria mandar já vir todas as peças, embora algumas não lhe dê logo utilização.
Em relação a esses sensores, são na verdade muito adversos a condições exteriores, como por exemplo a luz solar vinda de uma porta ou janela.
-
Mas os motores não são perfeitos, nem as tuas baterias têm sempre a mesma carga, logo tu chegas á conclusão que precisas de um motor a rodar para um lado durante 2 segundos para fazer uma curva de 90 graus, mas as baterias descarregam um bocado e uns 15 minutos depois já não demora só 2 segundos, e começas a ter erros por todo o lado e o robot ja não está a fazer nada do que tu querias.
Para seguir linhas aconselho isto:
http://loja.lusorobotica.com/64-optical-detector-phototransistor.html (http://loja.lusorobotica.com/64-optical-detector-phototransistor.html)
ou isto:
http://loja.lusorobotica.com/123-qtr-8rc-reflectance-sensor-array.html (http://loja.lusorobotica.com/123-qtr-8rc-reflectance-sensor-array.html)
Sendo este ultimo mais simples de usar por um iniciante que os outros, se querem que o robot chegue a um ponto arbitrário sem seguir uma linha e com os vossos conhecimentos só se fizer um movimento programado e ai precisão de encoders que são uns dispositivos que contam as voltas que as rodas dão que é para garantir que conseguem sempre fazer uma curva de 90 graus ou qual a distancia que o robot percorreu.
-
Sim, de facto, tens razão senso. A experiência vale de alguma coisa :D Apesar dessa ideia dos encoders não parecer má de todo...
Nelson, tu vais começar por ter uma configuração de duas rodas com condução diferencial. Eventualmente vais querer passar ou pelo menos experimentar configurações com mais rodas?
Nós vamos ter de nos reunir na 4ª feira para avaliar o projecto e, face ao feedback que tivemos aqui, escolher a melhor opção. Infelizmente, não fazemos robótica só pelo prazer mas também porque a nossa nota depende disso :D e temos de ter algo concretizado no final do ano. Em termos de conceito, preferíamos ter um robot que se movesse sem o auxílio de linhas (também temos de ter em conta o impacto que o robot possa ter em demonstrações), por isso, estamos num dilema.
Senso, achas que, com muita investigação, pesquisa e aprendizagem ao longo dos próximos meses, conseguimos ter um robot programado para avançar em frente, sempre que chegar a um obstáculo (lido por um sensor de distância ou um fototransístor), rodar para um lado (podendo optimizar esta decisão com sensores adicionais, ou outra coisa a ver) mover-se x voltas do motor e em seguida retomar o movimento para frente?
-
A acumulação de erros vai ser enorme ao fim até de meio metro ou um metro, um segue linhas que siga uma linha bem rápido na minha opinião é bastante interessante de se ver, e com o vosso conhecimento é algo possivel de se fazer, a outra coisa, nem tanto.
-
Como deves ter reparado, é fim-de-semana e só estão aqui duas pessoas em representação do grupo, pelo que depois vamos ter de decidir em conjunto :D
Um dos nossos princípios neste projecto era ter um robot relativamente simples que permitisse explicar como funcionam os robots em geral (nada de muito avançado, sensores, microcontrolador, programação lógica, etc.) e também faze-lo de uma forma interactiva. Ao ler a tua sugestão, veio-me logo à cabeça e se o "playground" do robot fosse um daqueles quadros brancos que se usam nas salas de aulas e os participantes pudessem traçar eles mesmos o caminho para o robot seguir com um marcador negro? Lembrei-me também de que esses quadros têm um pouco de reflexão a mais: isso pode ser um inconveniente "fatal"?
-
Nelson, tu vais começar por ter uma configuração de duas rodas com condução diferencial. Eventualmente vais querer passar ou pelo menos experimentar configurações com mais rodas?
Sim, na realidade começo por apenas ter um robot que nem se devia de caracterizar como tal. Apenas conterá 2 rodas e uma base de equilíbrio (ball center) atrás. Não estou minimamente interessado em que o meu robot possua 4 rodas (não me irá trazer vantagem nenhuma para o tipo de evento que vou participar).
---
Em relação à interacção que possas ter na demonstração do robot... Vai depender da tua imaginação, mas até podes criar coisas engraçadas:
- Disponibilizas umas 30 folhas de papel A4, cada uma com uma linha preta com um certo declive, ou uma certa direcção, de forma a que o pessoal coloque e faça a "pista" da maneira que bem intender;
- Podes ainda ter algumas especiais com "cortes" da linha preta, sendo que o robot teria de encontrar a linha mais à frente;
- O objectivo seria o pessoal fazer o próprio circuito do robot... Era uma solução interactiva e demonstrava como o robot funcionava.
;)
-
Bem, enquanto estava a ler o vosso post, a única ideia que me veio à cabeça para o fazerem mover num certo sentido, desviado-se dos obstáculos, sem necessitar de linhas auxiliares era utilizarem uma bússula como esta:
http://loja.lusorobotica.com/magneticos/17-compass-module-hmc6352.html (http://loja.lusorobotica.com/magneticos/17-compass-module-hmc6352.html)
Agora, eu nunca utilizei nenhuma nem sei qual a dificuldade da sua utilização, mas existe um tutorial aqui no forum feito pelo TigPT sobre ela (http://lusorobotica.com/index.php/topic,36.0.html (http://lusorobotica.com/index.php/topic,36.0.html)).
Com ela e com os encoders, supostamente, acho que deviam conseguir registar a orientação do robot quando carregassem num botão, e fazer com que ele tentasse mantê-la enquanto se desviasse dos tais obstáculos através de outros sensores de distância...
-
Em relação à interacção que possas ter na demonstração do robot... Vai depender da tua imaginação, mas até podes criar coisas engraçadas:
Obrigado pela sugestão. É outra possibilidade, mais barata provavelmente, a ter em conta.
Então, ao fim ao cabo, vamos ter um robot ou um aspirante a robot bastante parecido com o teu, Nelson. Dois motores, um Arduino, estive a ver no teu tópico que listas também uma ponte H (tenho de ver bem o que são, mas acho que percebo), a alimentação (ainda vamos investigar) e o resto é carpintaria.
Senso, ao dizeres "bem rápido", o que é que tinhas em mente?
-
Boa sorte com o projecto. ;)
Ao leres o tópico que abri com algumas dúvidas encontras respostas às tuas próprias perguntas! 8)
-
Sim, já andei lá a ver ;) Mais uma vez obrigado.
Bem, enquanto estava a ler o vosso post, a única ideia que me veio à cabeça para o fazerem mover num certo sentido, desviado-se dos obstáculos, sem necessitar de linhas auxiliares era utilizarem uma bússula como esta:
http://loja.lusorobotica.com/magneticos/17-compass-module-hmc6352.html (http://loja.lusorobotica.com/magneticos/17-compass-module-hmc6352.html)
Obrigado pela sugestão. Vamos tentar começar por algo mais simples mas nunca se sabe se no futuro vamos dar um passo nessa direcção. :)
-
Sim, fazem bem.
Mais vale começar com uma coisa simples e conseguir concretizá-la do que tentar logo uma difícil de que depois se tenha de desistir.
-
Uma ponte H é essencial para controlares os motores.
Ve estes filmes:
Line Follower Robot Competition (http://www.youtube.com/watch?v=JDxIorDI1VQ#)
MINIROBOTICA 2006 (http://www.youtube.com/watch?v=-qqBPEvEDoA&feature=channel#)
-
Pedimos desculpa por termos estado um pouco fora da participação nesta última semana. Tivemos alguns assuntos para tratar, mas já estamos 100% operacionais :D
Esses vídeos parecem bastante interessantes, mas deduzimos que os motores usados não sejam os de um smalluino. O atractivo dessas demonstrações é a velocidade: consegue-se ter uma velocidade razoável com motores de smalluino? Outros motores diferem muito em preço e dificuldade de programação?
Em relação aos sensores, os fotoresístores têm a vantagem óbvia do preço, mas parecem ser mais díficeis para programar e principalmente, de assegurar a ausência de erros (luz que entra pela janela, a própria iluminação da sala, etc.). Quem tem experiência em trabalhar com fotoresístores, pode dizer se conseguem obter bons resultados ou a acumulação de erros é muito grande?
Cumprimentos
-
Como já foi dito acima, fotoresistências(tambem conhecidas por LDR's) não podem ser usadas para segue linhas porque são MUITO lentas a responder a variações de luz, tens de usar sensores infra-vermelhos e mais uma vez repito o melhor será usar um qtr-8rc ou parecido.
-
Ok, não tenho ideia de ter visto isso, mas pronto. Na thread do Nelson, ele estava a falar de um segue-linhas baseado em foto resístores, por isso, é que levantamos essa questão :). E em relação aos motores?
-
Está mais acima nesta págna.
-
Para os motores, atendendo que a velocidade é um dos aspectos a ter em conta, é aconselhável usar motores DC ou servos? E servos de rotação contínua? O preço varia muito?
Sobre o sensor, vamos usar o que estavas a falar (http://loja.lusorobotica.com/123-qtr-8rc-reflectance-sensor-array.html).
-
Alguém pode explicar como se montam os reguladores e os condensadores, tendo em conta a sua função?
Li que os condensadores se devem montar próximo da alimentação (salvo erro) mas em que parte? Solda-se a algum outro componente?
Quantos são precisos e porquê esse número?
Há algum sítio em especial onde se possam adquirir? Ou qualquer loja de electrónica local serve?
Os reguladores tenho ideia que são na breadboard, mas ligados ao quê?
Apesar deste tópico ter estado um pouco parado, mesmo com a nossa pergunta sobre os motores, agradecemos desde já toda a ajuda que nos têm vindo e vão continuar a prestar ;)
-
Boas pessoal,
Ninguém tem respondido aqui :( . Temos feito mais alguma pesquisa e a maioria das dúvidas já conseguimos esclarecer e estamos prestes a encomendar os primeiros componentes. Ainda assim, temos algumas questões que só alguém com mais experiência pode responder:
- Condensadores: como se montam e quais os valores de capacitância que temos de usar?
- Reguladores: como se montam (no circuito da breadboard) e como funciona? (tivemos a pesquisar sobre transístores e pareceu-nos um conceito parecido. tem alguma coisa ver?)
- Em relação aos motores, os Dual Motor Gearbox (http://loja.lusorobotica.com/81-dual-motor-gearbox.html) estão esgotados. A alternativa que encontramos é da Pololu: http://www.pololu.com/catalog/product/1677/specs (http://www.pololu.com/catalog/product/1677/specs). Tendo em vista o nosso objectivo (alguma velocidade ;D) aconselham-nos esta solução?
Cumprimentos,
projectoAREA
-
Reguladores de tensão, se precisam de 5v, pesquisem por LM7805 datasheet, lá têm tudo o que precisam para os saber montar, se quiserem fotos deles montados numa breadboard é só meter LM7805 breadboard no google e têm imagens.
Não queiram velocidade sem serem capazes de controlar o robot.
Depois, condensadores, pesquisem por condensadores de decoupling ;)
-
Ok, então os reguladores servem para assegurar que a tensão que passa no Arduino é constante e igual a 5 V, certo? Isto porque usamos 2 suportes de 4 pilhas recarregáveis de 1,2 V (ou seja, 8 x 1,2 = 9,6 V). E precisamos desta tensão mais elevada (em vez de apenas um suporte de 4 pilhas, num total de 4,8 V) para haver energia suficiente para os motores. É isso?
-
O arduino tambem tem um regulador interno, basta comprar um jack(ficha femea para ligar no arduino) que ele regula para 5v, desde que não liguem os motores nem muita coisa ao arduino o regulador que ele tem serve bem.
Depois, condensadores podem comprar uns quantos com 100uF a 500uF de 16v electroliticos(estes condensadores têm polaridade, e está marcada no condensador com uma faixa de traços assim - que indica o polo negativo/massa), o polo negativo ligam á massa e o outro ligam aos 5v, estes condensadores servem mais como armazem de energia para quando os motores arrancam não baixar muito a tensão das pilhas, e depois em cada circuito integrado que usarem devem meter um condensador ceramico de 0.1uF, estes condensadores não têm polaridade e podem ser ligados em qualquer sentido, mas sempre uma pata no negativo e outra para no positivo, devem ser colocados o mais proximo possivel das linhas de alimentação de cada CI, depois se estão a usar motores dc tambem aconselho a colocar um condensador ceramico soldado directamente nos polos do motor para reduzir um pouco o ruido que os motores geram.
-
Essa já é alguma informação para digerir :D Obrigado
Se nós tivermos 9,6V a sair das pilhas, o regulador do Arduino faz com que só cheguem 5V ao próprio Arduino. Mas quando falas do polo positivo de 5V assumo que seja o da Breadboard. Como é que a tensão no positivo da breadboard, também é de 5V?
Depois esse tal jack, não percebi muito bem. Ligam-se os fios à entrada 5V do Arduino e à GND ou ao "power jack" (aquela entrada grande tipo carregador de pc)? Onde é que entra a ficha fêmea?
Finalmente em relação ao soldar directamente aos polos do motor. É como nesta imagem? As pontas não fecham o circuito provocando um curto? (https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.pololu.com%2Fpicture%2F0J677.300.png&hash=dcd47d5f3766d64506082fe888635dc249dd5cc4)
-
Além das 2 questões anteriores, estamos com dúvidas entre escolher motores, servos ou servos de rotação contínua. Os motores Dual Motor Gear Box estão esgotados na Loja da LusoRobótica. Encontramos algumas alternativas interessantes no site da Pololu (http://www.pololu.com/catalog/product/1677 (http://www.pololu.com/catalog/product/1677), por exemplo), mas tememos que não valha a pena por causa dos portes. Alguém sabe como é mandar vir pela Pololu dos US? Depois se for para utilizar servos, esses já se encontram disponíveis na LusoRobótica... Estamos na iminência de encomendar o material, por isso agradecíamos uma resposta breve.
Cumprimentos
-
Servos só rodam 180 graus a não ser que sejam modificados para rotação continua.
Os portes da polulu é fazer uma conta lá e fazer o checkout para ver em quanto ficam os portes.
Tambem têm a http://www.robotshop.com/eu/home.html (http://www.robotshop.com/eu/home.html) que tem loja em França, logo deve ser menos de portes.
-
Se forem modificados para rotação contínua (ou já de origem), vale a pena comprar em vez dos motores DC?
-
Isso depende da utilização, os servos já têm uma caixa, os motores DC depende, mas em termos de facilidade de uso é muito mais simples usar servos modificados que motores DC, pois só precisas de um fio para controlar cada servo e não precisas de ponte H nem nada disso.
-
E permitem obter exactamente o mesmo efeito? Contando que o conseguimos ter a fazer tudo o que queremos, há diferenças na velocidade de ambos os tipos de actuadores?
-
Isso depende da caixa que cada motor tem, mas podes meter os servos a rodar para um lado ou para o outro e tem controlo de velocidade, logo deve servir bem para o vosso robot.
-
Ok, e já agora podes explicar como é que se faz a alimentação do arduino e como funciona o regulador interno?
-
Eu tenho um bom projecto que é o smalluino mas com dois sensores ldr o objectivo e fazer o seu percurso e quando sentir luz seguir a luz.
Para ter melhor imform~ção procura sensor no smalluino.
Amanhã ja o vou começar a montar depois organizo um vedeo com tudo
-
Em relação aos condensadores cerâmicos, eles montam-se como é indicado neste link:http://www.pololu.com/docs/0J15/9 (http://www.pololu.com/docs/0J15/9)? Nesse caso, serão precisos 2 (um por casa motor) e podem ser de 0,1uF, certo?
Em relação à alimentação do Arduino, pelo que vi da imagem do Nelson, apenas um fio estava ligado à secção POWER do Arduino: era um que ligava a entrada VIN à massa da breadboard salvo erro. Isso basta?
-
Já vi em mais que um sítio neste fórum a referência à utilização de duas baterias, uma para o Arduino e outra para os motores. Como é que isso funciona? Devemos optar por isso?
Vamos mandar vir hoje (daqui a pouco de facto) os componentes da Lusorobótica e mais outros da Pololu, são 70 e poucos euros no total. Depois ainda vamos ter de recorrer a algumas lojas de electrónica locais para comprar os condensadores e assim.
As outras questões mantém-se, aliás era só confirmar (se estiver certo claro :) )
-
Têm isso aqui explicado: http://lab.guilhermemartins.net/2009/01/29/l293d-custom-motor-driver/ (http://lab.guilhermemartins.net/2009/01/29/l293d-custom-motor-driver/)
Basicamente ligam uma ao arduino normalmente, e a outra, o fio positivo ligam a onde diz unregulated voltage, e o negativo à massa:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Ffarm4.static.flickr.com%2F3407%2F3252941552_2f4919475f.jpg%3Fv%3D1240780044&hash=601a16eb9e215976866ce46805d782c3a9cf92b1)
-
Humm, okay ajuda preciosa. Desculpa a minha ignorância, mas ainda estou a espera de receber o Arduino e ainda não sei muito bem como funciona até a sua própria alimentação, portanto o que é que querias dizer com "ligam uma ao arduino normalmente"?
-
Eu costumo utilizar coisas destas a que ligo os fios das baterias (só uma de cada vez):
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.ptrobotics.com%2Fimg%2Fp%2F293-309-large.jpg&hash=19fc5589940330e28c7d18bd06ddc117a4f2f5c0)
-
Humm, ok e é possível encontrar esse tipo de fichas em lojas locais de electrónica? Não me apetecia nada ter de comprar isso da net, sendo a única coisa da PTRobotics. Só os portes deviam ser mais que o próprio jack.
Em relação aos condensadores de decoupling, vejo sempre "comprem alguns". Isso pode ser 3 de 100uF (16 V) e outros 3 de 220uF (16 V)? Nem tenho bem a noção, porque nunca trabalhei com condensadores, por isso, uma ajuda concreta era bem-vinda. :)
-
Além das 2 questões anteriores, estamos com dúvidas entre escolher motores, servos ou servos de rotação contínua. Os motores Dual Motor Gear Box estão esgotados na Loja da LusoRobótica. Encontramos algumas alternativas interessantes no site da Pololu (http://www.pololu.com/catalog/product/1677 (http://www.pololu.com/catalog/product/1677), por exemplo), mas tememos que não valha a pena por causa dos portes. Alguém sabe como é mandar vir pela Pololu dos US? Depois se for para utilizar servos, esses já se encontram disponíveis na LusoRobótica... Estamos na iminência de encomendar o material, por isso agradecíamos uma resposta breve.
Cumprimentos
Eu mandei vir mesmo esses e paguei 15,03€ com portes incluídos e recebidos em casa.
Na altura perguntei se alguém queria, que mandava-se junto e pagava-se apenas metade dos portes, mas pronto.
Recebi aviso de entrega em 5 dias e a própria entrega em 7 dias úteis.
-
Pois, infelizmente estamos com 1 mês de atraso em relação ao teu projecto. Pelo que vi noutro tópico foi no dia 10 de Novembro que mandaste vir as tuas coisas. Nós mandámos hoje, dia 10 de Dezembro. Vamos pagar 17€ no total, visto que aproveitamos e mandamos vir também a bola livre.
Tu neste momento estás a ter problemas com a alimentação do robot, já estive a acompanhar o teu tópico. Espero que isso se solucione ;) até porque a maior parte dos passos que tu estás a fazer, nós vamos fazer em seguida ;D Estás a considerar utilizar duas baterias por acaso?
-
Pois, infelizmente estamos com 1 mês de atraso em relação ao teu projecto. Pelo que vi noutro tópico foi no dia 10 de Novembro que mandaste vir as tuas coisas. Nós mandámos hoje, dia 10 de Dezembro. Vamos pagar 17€ no total, visto que aproveitamos e mandamos vir também a bola livre.
Tu neste momento estás a ter problemas com a alimentação do robot, já estive a acompanhar o teu tópico. Espero que isso se solucione ;) até porque a maior parte dos passos que tu estás a fazer, nós vamos fazer em seguida ;D Estás a considerar utilizar duas baterias por acaso?
Eu já reparei que quem passa pelos testes e pelas dores de cabeça sou eu! ;D
Fora de brincadeira, sim, estou a tentar com que o robot seja alimentado com 1 suporte para motores e 1 suporte para Arduino.
Amanha, em principio, estará tudo em cima!
Se precisarem de alguma coisa, depois também posso disponibilizar e dizer o que vou fazendo.
-
AHAHAH
Não é nossa intenção estar a reboque pelo facto do teu projecto estar mais avançado. Para andar à sombra da bananeira, já chega essa miúda que apareceu aí a querer fazer um helicóptero ;D (apesar de eu nem ter percebido muito bem a situação, não vale a pena estar a fazer juízos de valor). De facto, tem havido muita informação que tem sido nova para nós e temos tido alguma dificuldade em acompanhar tudo. Por outro lado, já muito aprendemos imensa coisa e é esse o nosso principal objectivo, antes sequer de ter um robot operacional no fim do ano.
Em relação aos suportes, isso significa que tens 4,8 V para o Arduino e 4,8V para os motores. Isso chega para cada coisa (tinha ideia de que cada motor era de 3V logo 2 motores 6V)? Nesse caso não usas o Regulador pois não?
-
As minhas pilhas dão um total de 5.2V, pois ficam sempre com cerca de 1.3V de carga.
Amanhã darei mais info a respeito disto.
-
Em relação aos suportes, isso significa que tens 4,8 V para o Arduino e 4,8V para os motores. Isso chega para cada coisa (tinha ideia de que cada motor era de 3V logo 2 motores 6V)? Nesse caso não usas o Regulador pois não?
a tensão não se soma dessa maneira, cada motor vai "puxar" uma certa corrente (amperes) ai é que se pode "somar" para se ter uma ideia de que bateria usar
-
Ok, então o que estás a dizer é que com a corrente certa é possível ter o Arduino e os Motores a funcionarem com uma bateria de 4,8 V (ou 5,2V) cada um, certo?
-
A alimentação faz-se sempre pelo Power jack como na imagem? (nesse caso, já percebo para que é que é necessária aquela ficha fêmea)
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fimg263.imageshack.us%2Fimg263%2F2732%2Falimentaoarduino.png&hash=74bb004151d2975a783adfca6011d9bffd115808)
É possível utilizar os pinos VIN e GND para fornecer energia (como inputs) ao Arduino ou estes só servem para ligar com o resto de circuito (como outputs)?
-
mas tambem da sem power jack????????????????????
-
Era isso que eu estava a perguntar? :)
-
temos ambos a mesma duvida
?????????????????????????????
-
Pode-se alimentar pelo VIN e GND, como eu tenho.
-
Ok, então tens diferente daquele esquema do teu tópico em que ligavas dois fios das pilhas à PowerJack do Arduino. Duvida esclarecida.
-
como se chama o teu topico nelson
-
[Dúvidas] Iniciação à robótica (http://lusorobotica.com/index.php?topic=2918.0)
-
Ok, então tens diferente daquele esquema do teu tópico em que ligavas dois fios das pilhas à PowerJack do Arduino. Duvida esclarecida.
Tenho 1 suporte para tudo.
Basicamente o positivo do suporte liga ao + da breadboard e o negativo do suporte liga ao -.
Depois um fio do - para o GND e um fio do + para o Vin.
Os motores estão normal, com a ponte de H (tal como no esquema).
-
Ok, só no esquema aparecia dois fios a vir do suporte para o PowerJack. De qualquer forma, não é isso que faz diferença quando já sei como é na verdade. Mal posso esperar que cheguem os componentes, tenho é de tratar do suporte estrutural. Só que em Área de Projecto temos de estar sempre a apresentar pré-projectos e reformulações, por isso, estou a tratar de trabalho "administrativo" até chegarem as coisas...
-
Já chegou o Arduino, a Ponte H, a bread e os sensores. Os motores só chegam no final da semana porque vêm da Pololu. Já tive a "brincar" com o Arduino e tenho-me divertido bastante :D Encontrei alguns tutoriais porreiros na net e até já começo a perceber algumas coisas sobre a estrutura do código e sobre as funções envolvidas...
Cumprimentos
-
Boas pessoal,
Antes de mais, bom ano 2011 (já vem com 12 dias de atraso mas é o primeiro post de 2011 :P)
Durante este tempo todo, não desligamos do projecto nem de vir aqui. De facto, já conseguimos testar os motores com a ponte H e tudo bateu certo. Ainda não temos os condensadores nem as pilhas recarregáveis, mas não se preocupem, apenas testamos o circuito por alguns segundos para ver se funcionava tudo. Suponho que não faça mal (os problemas são a longo prazo). Neste momento, estamos a trabalhar em construir a estrutura, completar o circuito do robot (com os condensadores, etc.) e experimentar o sensor. Amanhã em princípio, vamos correr um programa que devolva os valores lidos pelo sensor ao pc (através de um serialprint) com o arduino ligado por USB.
O sensor é o array digital da Pololu. A embalagem vinha com uma resistência que no site aparecia montada no bloco "destacável" de 2 sensores. É só para o caso de se destacar o bloco que serve essa resistência ou é necessário uma resistência por cada sensor em funcionamento? (a esquemática no site confundiu-me quanto a isso). E depois cada sensor individual terá de estar ligado por um fio a um pino do Arduino e à GND. Se estiver alimentado por PC, qual é a ground? Convém ligar a ground do arduino a uma bus da breadboard e ligar as GND dos sensores aí também, certo? E a alimentação, ligo um fio do arduino pelo pino "5V" e isso alimenta os sensores (sendo que a energia está a sair do Arduino e não a entrar)?
-
Em relação a esse array da pololu podes indicar a referencia?
-
É o QTR-8RC Reflectance Sensor Array (http://www.pololu.com/catalog/product/961). Pelo que pesquisei, a resistência deve ser mesmo só para usar se se destacar o bloco de 2 sensores.
Depois também já escrevi o código de teste para amanhã (isto é, copy-pastei de vários sítios e ajustei para o meu caso). Gostava que alguém aqui visse. Já o posto.
-
Isto é o que é necessário fazer para ler os sensores:
The typical sequence for reading a sensor is:
Turn on IR LEDs (optional)
Set the I/O line to an output and drive it high
Allow at least 10 us for the 10 nF capacitor to charge
Make the I/O line an input (high impedance)
Measure the time for the capacitor to discharge by waiting for the I/O line to go low
Turn off IR LEDs (optional)
Não sei o vosso nível de conhecimento mas se não possuírem um conhecimento básico isto pode-se complicar. Procurem no forum que há quem os já tenha usado e até acho que já há bibliotecas.
-
Na página desses sensor estão uma biblioteca da Pololu para arduino, é só copiar colar e usar o programa de teste que eles dão tambem.
É só ler isto tudo ;)
http://www.pololu.com/docs/0J19/all (http://www.pololu.com/docs/0J19/all)
-
Na página desses sensor estão uma biblioteca da Pololu para arduino, é só copiar colar e usar o programa de teste que eles dão tambem.
Sendo assim, óptimo :)
-
Sim, sim nós já fizemos isso tudo. A biblioteca tem funções que executam esses passos que descreveste metro, penso eu. A minha dúvida prende-se mais com o hardware. Tendo em conta que o Arduino é alimentado pelo PC e não por uma bateria, como é que se alimenta o sensor? Liga-se o "5V" do Arduino ao "VCC" do sensor e aquela entrada do arduino passa a funcionar como output de energia e não input como se fosse alimentado por bateria?
O código que vamos usar é este:
#include <PololuQTRSensors.h> //inclui a library da Pololu
PololuQTRSensorsRC qtr((unsigned char[]) {9,8,7,6,5,4,3,2}, 8);
//define os 8 sensores nos pinos 2 a 9 do Arduino (mudar consoante)
void setup()
{
Serial.begin(9600);
int i;
for (i = 0; i < 250; i++)
{
qtr.calibrate(); //faz 250 calibrações durante 5 s
delay(20); // passar o cartao de calibração neste momento
}
Serial.println("Calibrado");
}
void loop()
{
unsigned int sensors[8]; // (não sei o que é) get calibrated sensor values returned in the sensors array, along with the line position
int position = qtr.readLine(sensors); // position varia entre 0 e 7000 em que 0 é à esquerda do sensor 1 e 7000 é à direita do sensor 8
if (sensors[0] > 750 && sensors[1] > 750 && sensors[2] > 750 && sensors[3] > 750 && sensors[4] > 750 &&
sensors[5] > 750 && sensors[6] > 750 && sensors[7] > 750)
// se todos os 8 sensors see very low reflectance
{ // está quase a cair ou no meio do percurso. fazer alguma coisa
Serial.println("Tudo escuro"); //indicar esta situação
return;
}
// definir o erro da posição da linha. O erro será 0 quando o sensor do meio estiver sobre a linha
// como é pretendido. O erro vai variar entre -3500 e 35)0. Se o sensor 0 for o da esquerda e o 2
// o da direita, um erro de -3500 significa que a linha está à esquerda e um erro de 3500
// significa que a linha está à direita.
int error = position - 3500;
Serial.println(position); //podemos alterar entre "position" e "error" para ver ambos
delay(1000);
}
O compiler não deu erros. Junta várias funções da página que mandaste, Senso, bem como alguns Serial.println para irmos acompanhando pelo PC o que está a acontecer. Peço desculpa se os comentários preenchem o ecrã, mas dão nos jeito para perceber. Afinal somos verdes nisto...
-
Sim, para alimentar o sensor ligas aos 5v e ao GND, os 5v só são entrada se não tiveres o arduino ligado a nada, se estiver ligado ao pc ou com um jack de alimentação ligado, o pino dos 5v é uma saida, por assim dizer.
Leiam atentamente a página da pololu e não troquem os 5v com a massa/GND provavelmente queimam o vosso sensor se fizerem isso.
-
Ok, também vamos usar cores diferentes nos cabos, mas vou ter atenção reforçada nisso. Como o sensor tem várias GND (uma por individual) vamos usar a bread para ligar tudo. De qualquer forma, é só para testar...
O que achas do código?
-
Basta ligar um GND tanto quanto sei, pois é partilhado.
O Aquilo que dizes não saber o que é no código chama-se array, é basicamente uma tabela para meter valores.
-
Ok, então está bem definido como está. Pronto.
Quanto à GND, tens razão. Li este PDF http://www.pololu.com/docs/pdf/0J12/QTR-8x.pdf (http://www.pololu.com/docs/pdf/0J12/QTR-8x.pdf) e diz isso mesmo. Mais tarde poderei vir a usar um LEDON para reduzir os consumos, mas por agora fica só o básico. Mais tarde também devo soldar uns headers fêmea para os fios ficarem melhor fixos: http://electrolaser.net/produto_det.php?id=19210&cat=AW.03 (http://electrolaser.net/produto_det.php?id=19210&cat=AW.03)
Obrigado pela ajuda
-
Já conseguiram por o sensor a trabalhar?
-
experimenta para ver se tens o sensor bem ligado
#define IR 0 // mudas aqui o pino para o que tens ligado
void setup() {
Serial.begin(9600); // baudrate
}
void loop() {
Serial.println(analogRead(IR));
delay(1000);
}
-
O sensor é digital pelo que a função deverá ser a digitalRead(). Mas nem é por aí. O código penso que esteja correcto até pelas indicações que o Serial Monitor dá. Já experimentámos o sensor mas ainda não funcionou perfeitamente. O circuito está mesmo a pedir soldagem que não conseguimos fazer até agora. O sensor lê os valores mas não foi uma leitura normal e linear (numa ponta 0 e noutra 7000). Num vídeo que vi aí do TigPT, ele ligava o Sensor e os LEDs emitiam luz. No nosso circuito, não...
-
Então deve estar mal ligado, ficou assim muito tempo?
-
Fotos do circuito então..
Que sensor estás a falar?
DigitalRead ou retorna 0 ou 1, se um sensor é util só com dois estados, bem depende do sensor que é.
-
Então deve estar mal ligado, ficou assim muito tempo?
Fica assim estável. Emite regularmente os inputs, mas os valores são irregulares (dentro do intervalo esperado, ainda assim).
Fotos do circuito então..
Que sensor estás a falar?
A nossa intenção era só testar o sensor QTR 8-RC (http://www.pololu.com/catalog/product/961), ligado ao pc, sem mais nada. Foi só um esboço. Pusemos numa breadboard e usámos os headers macho que vinham com o sensor para ligar aos fios na bread. Os IR ficaram para cima. Tal e qual como no vídeo do TigPT (http://lusorobotica.com/index.php?topic=1971.msg21585#msg21585). Esquece isso do DigitalRead, a biblioteca da Pololu tem as funções certas, eu é que estava a tentar responder ao AcidDagger (mal pelos vistos :P).
-
Mostra ai uma foto da vossa montagem então.
O vosso problema actual é qual então?
-
Os LEDs deviam-se iluminar e não iluminam. O sensor está a emitir valores pelo Serial Monitor mas esses valores não parecem variar de acordo com o facto de estarmos a passar um papel branco ou escuro sobre os sensores.
Vou mandar uma foto de como estava a testar o sensor. Não é no entanto um circuito muito bem feito (muito menos final). Foi só uma forma que arranjei para experimenta-lo. Os headers a ligar os pins do sensor à bread e na fila correcta, os fios do Arduino dos pinos 2 a 9. A alimentação é um fio do Vin do Arduino ao Vcc do Sensor e outro do GND do Arduino a um dos GNDs do Sensor.
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.pololu.com%2Fpicture%2F0J623.600.jpg%3F1276058165&hash=8f8c21f2e2b0693ed2c899e6ae92f71596c24312)
-
Não terás ai um fio mal soldado?
-
Pois, ainda não soldei nada... Já te mando a imagem, o sensor está apoiado nos Headers em cima da bread. Vou reconfirmar os fios...
-
A alimentação é um fio do Vin do Arduino ao Vcc do Sensor e outro do GND do Arduino a um dos GNDs do Sensor.
Estás a por que tensão na vin do arduino?
-
Isso assim faz mau contacto, tens de soldar os headers.
-
A alimentação é um fio do Vin do Arduino ao Vcc do Sensor e outro do GND do Arduino a um dos GNDs do Sensor.
Estás a por que tensão na vin do arduino?
O Arduino está a ser alimentado por PC.
Isso assim faz mau contacto, tens de soldar os headers.
Ok. Vou arranjar uns headers fêmea que vão servir de terminais aos fios, para fortalecer as ligações. De qualquer forma, os LEDs não deviam mostrar luz nem que fosse por momentos (quando houvesse contacto) ? Outra coisa, quando tiro o sensor da bread, o Arduino continua a enviar valores diferentes, quando devia passar a dar 0.
-
Se os pinos digitais não estão ligados a nada, estão a flutuar, logo estão sempre a variar entre 0 e 1 por causa do ruido e radiação electromagnética que nos rodeia.
-
Mas se isso é significativo, então também não interfere na leitura normal do sensor?
-
Não, porque sem nada ligado ás entradas as pistas da placa do arduino funcionam tal e qual a antena de um telemovel, se tiveres lá alguma coisa ligada, seja uma resistência, esse sensor ou qualquer outro, o sensor tem um sinal milhares de vezes mais forte que o sinal que é criado pelo ruido electromagnético.
-
Humm, eu desconfiei que o sinal de qualquer coisa "a sério" ligada ao Arduino fosse mais forte e se sobrepusesse. Já tenho as fotos, não é que venham neste momento ser do mais útil, depois do conselho que deste...
Estão neste album do Picasa:http://picasaweb.google.com/107646094444896100474/RobotProjectoAREAImagens?authkey=Gv1sRgCMXSkOKb2O3P8AE&feat=directlink (http://picasaweb.google.com/107646094444896100474/RobotProjectoAREAImagens?authkey=Gv1sRgCMXSkOKb2O3P8AE&feat=directlink)
-
Esse sensor apesar de ser digital é um pouco diferente. Eu já os usei.
É tal e qual o fabricante manda fazer: primeiro têm de colocar o pino em HIGH como OUTPUT por algum tempo, porque esta saída está ligada a um condensador, que vai ficar carregado. Depois, esse pino deve ficar como INPUT e sem pull up (que é a tal resistência), porque o condensador vai fornecer alguma tensão e vai descarregando através do foto-transístor. Se houver muita luz a chegar ao foto-transístor o condensador descarrega mais rapidamente, e vice-versa. Assim só é preciso ir fazendo digitalRead() sucessivos até a tal entrada ficar a zero. Se demorar muito tempo até isso acontecer o robot está em cima de algo preto, senão é algo branco.
-
Não vale a pena inventar com o código porque a biblioteca que a Pololu oferece para esses sensores faz tudo isso sem teres que te chatear com nada de tempos nem nada, é invocar e chamar a função de leitura.
-
Senso, no vídeo do Tiago Rodrigues não dá para ver muito bem, mas também fiquei com a sensação que o array não estava soldado aos headers. Porque é que não deu luz nenhuma, mesmo quando eu via que os headers estavam a tocar no metal dos pinos do sensor?
-
Pode ter dado tão rápido que não viste, ou então a tua camera tem um filtro por causa dos infra-vermelhos, praticamente todas as cameras agora têm porque descobriram que grande parte dos bikinis e roupa de banho em geral são transparentes aos infra-vermelhos, então se fores para uma praia tirar fotos vês por baixo da roupa das pessoas lol...
-
Lol, é bom saber isso.... :D
Mas eu fartei-me de experimentar o sensor em vários momentos (desde 5ª feira) e nunca vi nada com os meus próprios olhos. Se é por piscar muito rápido, então porque é que isso está a acontecer, enquanto no vídeo do TigPT, não?
-
Por não teres isso a fazer bom contacto por não estar soldado.
-
Pensava que aquelas luzes eram uns LEDs normais que indicavam funcionamento. Só agora é que me apercebi que afinal são os emissores em IV do próprio sensor. Sabes, por causa do que disseste fui buscar o telemóvel do meu irmão que tem uma câmara sem filtro (lembro-me que numa sessão na Fábrica da Ciência Viva aí em Aveiro, sobre Robótica :D, a senhora disse isso que tu disseste mas sobre controlos remotos e aquele telemóvel mostrou os IV). Com o ajuste certo (vê a foto) consegui pôr um bom contacto e no telemóvel, voilá, luzes IV a dar. A partir daí comecei melhor a ter noção quando é que o sensor estava a ler valores ou não. Reparei que bem calibrado, as leituras davam correctas. Quer dizer não era uma perfeição, mas notei as variações concordantes com eu ir para a ponta da esquerda ou da direita com o papel pintado. Espero que quando soldado e no ambiente correcto (agora o sensor estava virado para cima e a minha mão treme um bocado também xD), as leituras melhorem um bocadinho...
Foto: http://picasaweb.google.com/lh/photo/3SZBKf9ctx1APrXr81fXH5SYJHQ_NssFyboOq_yFia0?feat=directlink (http://picasaweb.google.com/lh/photo/3SZBKf9ctx1APrXr81fXH5SYJHQ_NssFyboOq_yFia0?feat=directlink)
-
Tenho uma dúvida em relação à calibração. É individual de cada sensor ou é geral para todo o array? Ou seja, tenho de passar o cartão para calibrar em todos os sensores, uniformemente, ou basta em alguns? Isto porque durante a calibração, o sensor regista o mínimo lido como 0 e o máximo lido como 1000. Se os sensores são calibrados individualmente então é possível que pela variação da condições do meio, nem todos os sensores registem o mesmo 0 (mínimo) e depois a função readLine pode não funciona na perfeição...
-
Existe por ai um filme, penso que do TigPt a mostrar a calibração, simplesmente passou um papel de ponta a ponta dos sensores várias vezes.
-
Pois, esse já tinha visto. Okay então...
-
Dois meses depois, o nosso robot já anda.
Lá tivemos que tratar da parte estrutural e do circuito, o que ainda demorou algum tempo. E surgiram alguns obstáculos que nós tivemos de ultrapassar com a nossa inexperiência (ainda estragámos uma peça ou outra como um suporte de pilhas que ficou a fazer curto circuito na caixa do robot durante algumas horas :) ). Enfim, mas neste momento temos o robot programado o suficiente para "impressionar" uma pessoa que não perceba muito de robótica ;) . Anda em frente, roda consoante lê a linha à direita ou à esquerda e pára se ler tudo "escuro". Na prática segue uma linha sem ramificações de forma mais ou menos atabalhoada.
Dentro de 2 semanas, vamos apresentá-lo num evento (a Semana da Ciência lá da escola - em que todos os alunos visitam os nossos projectos, bem como experiências preparadas pelos professores de FQ e Biologia). Amanhã vou ver se faço um vídeo e posto o código para pedir a vossa opinião e ver que aspectos se podem melhorar :D
Para depois da Páscoa, gostava de tentar fazer do robot um Maze Solver e usar controlo PID com eficácia.
Cumprimentos,
Manel do projectoAREA
-
Parabéns ;)
Para estarem a falar em PID estou a fazer que correu mesmo bem o trabalho!
Cá esperamos para ver o video e ajudar no que for preciso.
PS: Não se esqueçam das outras disciplinas :p
-
Boas,
Pelo que eu estive a ver, o controlo PID é uma função ou umas funções que tens no código com uns certos parâmetros de afinação e que depois resultam num valor de velocidade de motores que transmito aos motores através da função analogWrite por PWM. Só não avançámos ainda para isso, porque temos outros aspectos para corrigir ainda e não temos muito tempo, mas se calhar até era capaz de experimentar um código com PID e depois se funcionasse, tudo bem. Se não funcionasse, tinha sempre o outro simples.
Em relação ao vídeo, peço desculpa mas não vai dar para postar. Ontem o robot ficou com um colega meu e hoje reparei que as pilhas estavam descarregadas. Faziam os motores entram em stall com uma chiadeira enorme mas nenhum movimento. No início, cheguei a temer que fossem atritos com os motores Tamiya Double Gearbox ou das rodas, porque os motores funcionam com as rodas levantadas mas era no contacto com o chão que tinham muita dificuldade em especial na rotação. Já agora, gostava que alguém que já tenha trabalhado com esses motores, partilhasse a sua experiência quanto a isto.
Amanhã de tarde tenho mais tempo (hoje ainda tenho de estudar para um teste) e vou fazer o tal vídeo. O código já o posso partilhar. Quer dizer, tenho uma série deles que fomos experimentando mas aqui está o último:
#include <PololuQTRSensors.h> //inclui a library da Pololu
PololuQTRSensorsRC qtr((unsigned char[]) {14,15,16,17,18,19}, 6);
// ————————————————————————— Motors
int motor_left[] = {3, 9};
int motor_right[] = {5, 6};
void setup()
{
Serial.begin(9600);
pinMode(13, OUTPUT);
digitalWrite(13, HIGH); //o LED 13 fica ligado durante
int i; // a calibração para indicar que está a decorrer
for (i = 0; i < 250; i++)
{
qtr.calibrate(); //faz 250 calibrações durante 5 s
delay(20); // passar o cartao de calibração neste momento
}
digitalWrite(13, LOW);
// Setup motors
int j;
for (j = 0; j < 2; j++)
{
pinMode(motor_left[j], OUTPUT);
pinMode(motor_right[j], OUTPUT);
}
delay(1000); //dá um segundo para não começar logo a andar
} // depois da calibração
void loop()
{
unsigned int sensors[6];
int position = qtr.readLine(sensors); // position varia entre 0 e 5000
int error = position - 2500; //o erro varia entre -2500 e 2500
if (sensors[0] > 750 && sensors[1] > 750 && sensors[2] > 750 && sensors[3] > 750 && sensors[4] > 750 &&
sensors[5] > 750) // tudo escuro => parar
{ // nao anda se levantar do chão nem sobre a linha preta transversal
motor_stop();
}
if (sensors[0] > 200 && sensors[1] > 200 && sensors[2] > 200 && sensors[3] > 200 && sensors[4] > 200 &&
sensors[5] > 200) // tudo branco => parar
{ // em princípio, não anda se se afastar muito da linha
motor_stop();
}
else if (error < -500) //linha à direita => roda à direita
{
turn_right();
}
else if (error > 500) // linha à esquerda => roda à esquerda
{
turn_left();
}
else // linha ao centro => anda para a frente
{
drive_forward();
}
delay(100); //não sei se é 100% mas dá algum tempo para o Arduino processar e decidir em que direcção mover
}
// ————————————————————————— Funções de movimento
void motor_stop(){
digitalWrite(motor_left[0], LOW);
digitalWrite(motor_left[1], LOW);
digitalWrite(motor_right[0], LOW);
digitalWrite(motor_right[1], LOW);
delay(25);
}
void drive_forward(){
analogWrite(motor_left[0], 150); // PWM
digitalWrite(motor_left[1], LOW);
analogWrite(motor_right[0], 150);
digitalWrite(motor_right[1], LOW);
}
void drive_backward(){ // está aqui just in case visto que não é usada
digitalWrite(motor_left[0], LOW);
digitalWrite(motor_left[1], HIGH);
digitalWrite(motor_right[0], LOW);
digitalWrite(motor_right[1], HIGH);
}
void turn_left(){
digitalWrite(motor_left[0], LOW);
analogWrite(motor_left[1], 150);
analogWrite(motor_right[0], 150);
digitalWrite(motor_right[1], LOW);
}
void turn_right(){
analogWrite(motor_left[0], 150);
digitalWrite(motor_left[1], LOW);
digitalWrite(motor_right[0], LOW);
analogWrite(motor_right[1], 150);
}
Gostava que comentassem esse código e dessem algumas sugestões para melhorar ;)
Cumprimentos,
Manel do projectoAREA
PS: Não se preocupem com as outras disciplinas :D Se bem que o robot faz-me perder algumas horas de estudo e sono, mas é por uma boa causa AHAHAH
-
Segue linhas projectoAREA (http://www.youtube.com/watch?v=TRWmHQBDqA4#)
Bem, como tinha dito, aqui está um vídeo do nosso robot. Fizemos hoje durante um intervalo entre aulas. As condições não as ideais (nem aquela pista será a final) mas foi só para mostrar aqui como é que está o nosso robot. Só postei hoje porque os motores tiveram um problema que fazia com que eles entrassem em stall e que só se resolveu quando mudei o gear ratio para uma configuração com mais torque...
Não é que ele já esteja acabado, mas agradeço ao pessoal que deu o seu contributo para nos ajudar a executar o nosso projecto. E fico então à espera de comentários :D