AR.L.O. – Un robot educativo da stampare in 3D, gestito da Arduino

Pubblicato il -
Questo articolo potrebbe contenere link di affiliazione, ovvero link a pagine in cui, se viene effettuato un'acquisto, potrebbero generare una commissione a settorezero ma comunque senza incidere sul costo finale dell'oggetto acquistato. E' un modo per non avere pubblicità invasiva (che, se non avete notato, abbiamo rimosso) e nel contempo garantire al sito di continuare ad esistere.
PROGETTO DEPRECATO

Questo progetto è deprecato, la sua nuova versione si chiama ARLO, ed è disponibile su Github. Ad ogni modo questo articolo rimane valido per quanto riguarda molte spiegazioni e concetti.

La genesi di questo robottino è stata piuttosto singolare, nel senso che non ero partito con l’idea precisa di realizzare un robot. Fin’ora ho sempre utilizzato dei normali motoriduttori per i robottini e avevo una scatola piena di vecchi servocomandi inutilizzati. Ho pensato quindi di modificarne un paio per farli diventare a rotazione continua, così, per passare il tempo. Dopo di questo, avevo anche una marea di avanzi di filamenti per stampante 3D e ho pensato quindi a stampare dei supporti per poter mantenere i servo su una base e fare dei test. Nel frattempo mio figlio ogni tanto veniva a vedere cosa stavo facendo, come fa sempre, e gli spiegavo tutto: questo è un motore con gli ingranaggi, vedi funziona come la bici blablabla. Successivamente su Thingiverse mi sono imbattuto in una ruota parametrica: adoro le cose realizzate con OpenScad perchè è un metodo di disegno 3D basato su formule e programmazione (vedremo dopo di cosa sto parlando se ne siete a digiuno). Ho quindi realizzato alcune ruote e con la complicità di mio figlio che si appassionava, po’ alla volta mi sono lasciato prendere la mano e sono arrivato ad un robottino completo. Il primo nome del Robot doveva essere Arlecchino proprio perchè il suo “vestito” era realizzato con avanzi e risultava tutto colorato. Dal momento che non mi piacciono molto i nomi lunghi ho abbreviato in AR.L.O., che è poi diventato l’acronimo inverso di ARduino Loaded with O-rings (non ha quindi nulla a che vedere col dinosauro della Disney/Pixar).

Mi fa piacere ricordare questa cosa: per quanto riguarda la scelta dei nomi corti, sono stato probabilmente influenzato in gioventù da una famosa scena di Ricomincio da tre in cui Gaetano, interpretato dall’immenso Massimo Troisi espone a Marta, la fidanzata nel film, le sue perplessità riguardo all’utilizzo di nomi troppo lunghi per un ipotetico figlio: altrimenti il bambino cresce “scostumato”. Per chi non conoscesse la scena (mi rivolgo sicuramente ai più giovani) può colmare la lacuna a questo link, la gag si trova a partire dal minuto 3:20.

Questo è un teaser del robottino:

Sponsor

I PCB di questo progetto sono stati gentilmente offerti da PCB Way – il servizio di realizzazione PCB più completo che c’è: realizzano PCB fino a 30 layers! (in tutti i colori, compreso il viola e per questo progetto ho scelto proprio questo colore), PCB flessibili, stencil SMD, PCB con base in alluminio o rame (e altri materiali). Hanno un prezzo molto vantaggioso che parte da $5 per 10 PCB standard (1 o 2 layers fino a 100x100mm). PCBWay ha un sistema che premia con punti (beans) e la possibilità di inviare inviti che permettono di avere sconti e regali. Assistenza istantanea anche tramite chat, lavorazione velocissima, precisione e qualità ai massimi livelli.

Sponsor

I componenti per qesto progetto sono stati gentilmente offerti da Futura Elettronica – Il negozio italiano più completo che c’è per soddisfare tutte le nostre esigenze da Maker: componenti elettronici, schede di sviluppo, videosorveglianza, stampa-3d, robotica, prodotti in kit.

Futura Elettronica

Update

Le informazioni riportate in questo articolo sono sempre valide: ovvero tutte le digressioni sulle scelte circuitali, i calcoli ecc. Per quanto riguarda, invece, la struttura vera e propria del Robottino in oggetto, ci sono stati dei piccoli aggiornamenti (retro-compatibili): il PCB è stato modificato leggermente per utilizzare una diversa scheda di sviluppo (la MakerUNO, che è una Arduino UNO compatibile) ed è stata cambiata leggermente la struttura. La nuova versione prende il nome di ARLOK ed è stata illustrata anche nel n°253 di Elettronica In. Per cui, se intendete realizzare il progetto, leggete tranquillamente questo articolo per avere le nozioni tecniche, dopodichè per l’eventuale acquisto di componenti, stampa, montaggio e programmazione, fate riferimento al nuovo repository Github che viene aggiornato continuamente:

Overview

AR.L.O. è un piccolo robottino a 2 ruote a guida differenziale, ovvero munito di due ruote entrambe collegate ad un proprio motore per cui la sterzata viene eseguita facendo girare le ruote in direzioni opposte alla stessa velocità (il baricentro rimane fermo) oppure facendo girare le ruote nella stessa direzione ma a velocità differenti (virata). L’equilibrio è mantenuto tramite un terzo punto di appoggio fornito da un ball-caster (una sferetta montata in un supporto, libera di rotolare). Il firmware di ARLO è un programma per Arduino che, in questa prima fase, non fa altro che far camminare il robot sempre dritto fino a che non trova un ostacolo rilevato da un sonar (sensore ad ultrasuoni) e quindi decide di cambiare direzione. Come accessori sono presenti un piccolo Display Oled ed un modulo Bluetooth. Il robottino può essere espanso a piacere man mano che si acquisisce confidenza con la programmazione e con le dinamiche di movimento.

Analizziamo nel dettaglio le varie parti che compongono il robot, con alcune considerazioni.  Più in basso verrà riportato l’elenco riassuntivo del materiale occorrente.

Telaio

Il telaio è da realizzare con la stampa 3D. Ho disegnato i modelli con Tinkercad e caricato i files STL sia sul repository Github di AR.L.O. che su Thingiverse anche se, per essere sicuri di avere sempre i files più aggiornati, è sempre meglio fare affidamento a Github. I files vanno stampati in modo che i pezzi risultino abbastanza solidi: io ho usato un riempimento del 30% e li ho stampati in PLA+, che rispetto al PLA ha delle caratteristiche migliori. Il telaio si compone di 8 parti (6 files singoli) e qui farò riferimento ai nomi che ho dato ai files per descrivere le varie parti.

Pezzi di cui si compone il telaio di AR.L.O.

Abbiamo un pianale, rotondo, dello spessore di 5mm, che ha le forature per le staffe dei servo, le scanalature per accogliere i servo, le forature sia avanti che indietro per il modello di ball-caster scelto e due fori centrali per accogliere un portabatterie opzionale standard da 3AA posto verso il basso. Il file plate_base.stl è il pianale inferiore, gli incavi per i servo, dopo numerose prove, sembra che vadano bene un po’ per tutti i servocomandi standard: qualcuno può andare leggermente largo e altri possono calzare perfettamente. Gli unici servo in mio possesso che non sono entrati sono quelli della Multiplex per il solo motivo che avevano dei rinforzi sulle staffe di fissaggio, ma è questione di due secondi adattare i servo o la scanaltura per accoglierli..

Le scanalature per accogliere i servo sono profonde 2.5mm. Considerando che un servo standard (coricato sul lato più lungo col perno di uscita parallelo al piano) ha un’altezza di circa 20mm e che il perno si trova al centro (a 10mm), la distanza tra punto centrale del perno e terra (considero il servo incastrato nella base, con la base appoggiata a terra) è pari a 12.5mm: useremo dopo questo valore per alcune considerazioni, per cui tenetelo a mente.

Ci sono quindi le due staffe per bloccare i servo (servo_bracket.stl, da stampare 2 volte) e un pianale superiore (plate_top.stl) con le forature per accogliere un Arduino e con delle alette per mantenere un altro portabatterie da 4 stilo. Sono presenti due montanti per il pianale superiore: uno anteriore con i buchi per incastrare il sensore ultrasuoni (pillar_HC-SR04.stl) e uno posteriore presente in tre versioni: con foro da 6mm (pillar_hole_6mm.stl) , con foro da 10mm (pillar_hole_10mm.stl) e con foro da 12mm (pillar_hole_12mm.stl). In questo foro io metto l’interruttore per scollegare il pacco da 4 batterie stilo. Ci sono tre versioni con foro di diverso diametro perchè il foro da 6mm può essere utilizzato per i classici interruttori a levetta, che magari sono più diffusi, mentre quelli da 10 e 12mm li uso per dei pulsanti autobloccanti:

Questi pulsanti  li preferisco ai classici a levetta perchè più carini da vedere (l’ho usato anche sul Metromik): premendo il tasto il circuito si chiude e il tasto rimane premuto, premendolo nuovamente si sgancia e il circuito si apre.

Per la stampa completa delle parti, tranne le ruote, potete anche utilizzare il file all_but_wheels.stl che contiene tutti i pezzi (compresi, però, due pilastrini per l’interruttore: 6 e 10mm). CURA per questo STL fornisce una stima di 86grammi di filamento (circa 29 metri) e 7 ore di stampa con layer da 2mm, riempimento del 30% e una velocità di stampa bassa di 45mm/sec. Questi dati, ripeto, sono per tutte le parti senza le ruote.

Viti, dadi, rondelle, distanziali

Consiglio di utilizzare viti M3 del tipo TCEI (Testa Cilindrica con Esagono Incassato). Generalmente utilizzo sempre questo tipo di vite dato che è possibile stringerle anche quando si trovano in posti angusti visto che le chiavi a brugola hanno la parte più corta piegata di 90°, e poi esteticamente le trovo più carine. Queste sono le parti necessarie (tutte con diametro M3):

  • Rondelle: n.6 (non strettamente necessarie)
  • Dadi M3: n.10 (altri 4 li prendete dal kit del ball-caster)
  • Viti 6mm: n.8
  • Viti 10mm: n.2
  • Viti 12mm: n.10
  • Viti 16mm: n.2
  • Distanziali 8mm: n.4

Ho cancellato alcune parti perchè dopo un’accurata analisi è possibile eliminarle acquistando un solo tipo di viti, quelle M3 da 12mm: il ball-caster andrà montato con le viti in dotazione nel kit e utilizzando la scheda MakerUNO, essendo questa piatta nella parte inferiore (non ci sono saldature o pin che sporgono), potete fissarla al pianale usando del biadesivo o, meglio, del velcro. Potete quindi acquistare un kit di viti M3 da 12mm su amazon e un kit di dadi M3.

La misura indicata delle viti è chiaramente quella della sola parte filettata, senza tenere conto della testa. Anche se probabilmente costano un po’ troppo, io presi tempo fa dei kit inscatolati di viti TCEI M3 e di distanziali in ottone su Amazon, vi lascio quindi qui i link come riferimento: viti – dadi – distanziali. Se si acquistano su ebay in Cina, vengono a costare infinitamente meno, ma c’è chiaramente da aspettare. Questi kit sono comodissimi perchè ci sono varie misure e i pezzi sono separati tra loro in un pratico contenitore.

Ruote

Le ruote non le ho realizzate io ma ho sfruttato un progetto trovato su Thingiverse che mi è piaciuto molto: Servo Wheel 4.0 by Obijuan. Questo progetto è costituito da un file OpenScad che permette di realizzare delle ruote personalizzate adatte ad essere montate sulle squadrette dei servo. Vi ho già parlato di OpenScad qui su settorezero in passato (vedi articolo su dado parametrico): è un tool che adoro e apprezzo ancor più i progetti che ne fanno uso e che permettono di parametrizzare i vari aspetti dei pezzi che andremo a stampare.  Le ruote generate con questo script sono piene, hanno una scanalatura sul bordo che serve ad accogliere un O-Ring di gomma per dare grip e un incavo circolare (o a stella a 4 o 6 braccia) per accogliere la squadretta da montare sul servo, con 4 minuscoli fori intorno per il fissaggio della ruota alla squadretta. Tutti questi aspetti della ruota sono parametrizzati.

Esempio di squadrette per servo. In inglese vengono chiamate “horn“

Tra i files STL che ho caricato sul repository Github c’è la ruota che ho utilizzato io (my_servo-wheel.stl), che ha uno spessore di 4mm, un diametro adatto ad accogliere un O-Ring di 7cm di diametro e un incavo circolare del diametro di 21mm per le squadrette (tonde) dei servo che ho utilizzato io, con fori che si trovano a 8mm di distanza dal centro per avvitare la squadretta alla ruota. Il diametro finale delle ruote è influenzato dal diametro interno dell’o-ring e va scelto insieme all’altezza del ball-caster per fare in modo che il robot si mantenga dritto o meglio leggermente inclinato verso la parte posteriore per fare più peso sul ball-caster e mantenere meglio l’equilibrio. Il ball-caster scelto, della Tamiya, può essere montato in diversi modi che forniscono diverse altezze, analizzeremo dopo il ball-caster. Il diametro della ruota finita sarà quindi uguale al diametro interno dell’o-ring + due volte lo spessore (la sezione) dello stesso: avendo utilizzato un o-ring che ha una sezione di 2.5mm e un diametro interno di 70mm, la mia ruota ha un diametro esterno finito di 75mm. Tenete conto che poi il diametro finale aumenta leggermente quando andrete ad installare l’O-Ring.

Vediamo come è possibile personalizzare la ruota. Apriamo il file in OpenScad:

//-- Wheel parameters
wheel_or_idiam = 50; //-- O-ring inner diameter
wheel_or_diam = 3; //-- O-ring section diameter
wheel_height = 2*wheel_or_diam+0; //-- Wheel height: change the 0 for

Le dimensioni sono espresse tutte in mm. Il primo parametro (wheel_or_idiam) imposta il diametro interno dell’o-ring. Il secondo imposta lo spessore (il diametro della sezione circolare) dell’o-ring e l’ultimo indica lo spessore della ruota: normalmente viene spessa il doppio dell’o-ring con l’o-ring al centro. Se vogliamo la ruota più spessa cambiamo lo zero con un numero ma senza esagerare.

Seguono quindi i parametri usati per tutti i tipi di squadretta (horn):

//-- Parameters common to all horns
horn_drill_diam = 1.5;
horn_height = 6; //-- Total height: shaft + plate
horn_plate_height = 2; //-- plate height

Il primo parametro indica il diametro dei fori di fissaggio squadretta, questo parametro l’ho lasciato così com’è a 1.5mm: le vitine ci devono entrare strette e crearsi la filettatura quando le andiamo a stringere. Il secondo parametro indica lo spessore totale della squadretta (parte piana+imbocco perno servo) e l’ultimo il solo spessore della parte piana (senza tener conto, quindi, dell’imbocco del perno): questi due parametri serviranno a “scavare” la parte centrale della ruota per fare in modo che la squadretta entri dentro la ruota ad incastro, ho messo un’immagine più in basso per far capire meglio questi parametri dato che ho fatto anche io un po’ di fatica a capirli all’inizio.

Subito dopo ci sono parametri relativi ad una squadretta di tipo circolare. I valori di default sono quelli relativi alle squadrette forniti con i servo della Futaba:

//-- Futaba 3003 servo rounded horn parameters
rh_diam1 = 8.5; //-- Rounded horn small diameter
rh_diam2 = 21.5; //-- Rounded horn big diameter
rounded_horn_drill_distance = 7.3;

Il primo parametro indica il diametro esterno dell’imbocco del perno del servo (small diameter: diametro piccolo) e il secondo il diametro esterno (big diameter) della squadretta. Il terzo infine indica la distanza dei fori di fissaggio della squadretta dal centro. Seguono quindi parametri relativi ad altri tipi di squadrette, che non prendo in considerazione perchè è già difficile mettere d’accordo le tolleranze della stampante 3D con le misure prese a mano della squadretta circolare, figuriamoci con le squadrette a forma di stella.

Qui ho fatto un’immagine che dovrebbe aiutare a capire meglio questi ultimi parametri cosa indicano:

La generazione delle ruote viene fatta alla fine dello script:

//-- Test!
Servo_wheel_rounded_horn();
translate([wheel_or_idiam+10,0,0]) Servo_wheel_4_arm_horn();
translate([-wheel_or_idiam-10,0,0]) Servo_wheel_6_arm_horn();

La ruota per la squadretta tonda è generata dalla funzione Servo_wheel_rounded_horn(); per cui le altre due funzioni, che generano le ruote per le squadrette a 4 e 6 braccia, le potete commentare con un doppio slash.

Per le ruote cho usato io, piene al 50%, ci vogliono 37grammi di filamento (circa 12.4 metri) e 2 ore e mezza di stampa.

In totale, quindi, telaio+ruote necessitano di circa 123 grammi di filamento (41.4 metri), tenendo conto di un costo del filamento pari a 30euro al Kilo (questo il prezzo di una bobina di PLA+ della SUNLU acquistata durante la quarantena), il costo del materiale è di circa 4 euro. Questi dati sono approssimativi e dipendono da tanti fattori quali percentuale di riempimento e spessore delle pareti.

Ball caster

Il Ball-Caster è generalmente uno dei sistemi più utilizzati come terzo punto di appoggio per i robot a guida differenziale. Dato che ci sono due ruote mosse ciascuna da un proprio motore, poste più o meno al centro, e che non si tratta di un robot auto-bilanciante, per non ribaltarsi il robot ha bisogno di almeno un terzo punto di appoggio sul quale deve cadere gran parte del peso. Ho utilizzato un modello di ball-caster abbastanza comune e sicuramente ingegnerizzato meglio rispetto alla media: il Tamiya 70144. E’ possibile acquistare questo modello di Ball-caster presso Futura Elettronica seguendo questo link.

Questo modello di Ball Caster, rispetto ad altri mi piace perchè la sfera d’acciaio non poggia sulla plastica della struttura ma rotola su 3 piccole sbarrette metalliche e questo consente di avere un attrito e un’usura minori. Questo ball-caster si può montare in 4 differenti modi che portano a 4 diverse altezze: 11mm, 16mm, 27mm e 37mm. Le istruzioni di montaggio di questo ball-caster si trovano nella confezione. Le ultime 2 altezze, 27 e 37mm in realtà vengono raggiunte montando tra le due parti principali della struttura delle rondelle di plastica (indicate come H1 nello schema di montaggio) che sono alte circa 2mm: togliendole si arriva quindi a 25 e 35mm di altezza.

Montaggio del ball caster ad un’altezza di 27mm. Non utilizzando le rondelle H1 si arriva a 25mm, che è l’ideale

Ricordate che sopra ho detto che il centro del perno del servo si viene a trovare ad un’altezza di circa 12.5mm da terra. Utilizzando il ball-caster a 25mm (ovvero montaggio a 27mm ma senza le rondelle h1), il raggio della ruota, compresa di O-ring deve essere quindi 12.5+25mm=37.5mm ovvero diametro 75mm che è proprio il diametro della mia ruota come dicevo sopra (7cm diametro interno o-ring + 2 volte la sezione dell’o-ring che è 2.5mm). Dato che poi, mettendo l’o-ring il diametro aumenta un po’, il robot si trova leggermente inclinato verso il ball-caster, come volevo.

Sulla mia versione di AR.L.O., per quanto riguarda il gruppo di locomozione, ci sono quindi:

  • Ruote diametro 75mm (o-ring sezione 2.5mm e diametro interno 70mm)
  • Ball-Caster Tamiya 70144 nella versione da 27mm ma senza le rondelle H1 (altezza ball-caster:25mm)

Esistono comunque tanti modelli di ball-caster stampabili in 3D (vedi su Thingiverse). Cambiando Ball-Caster bisogna poi valutare l’altezza da terra e cambiare il diametro delle ruote (e di conseguenza trovare altri due O-Ring) e capire se possono essere montate le batterie al piano inferiore eventualmente vogliate utilizzarle (vedremo tra poco se sono necessarie). Oltre ai ball-caster esistono anche i ruotini pivotanti, del tipo di quelli usati per i mobili ma li sconsiglio perchè a volte, ruotando di 90°, rimangono incastrati, per contro vanno meglio su pavimenti muniti di fughe: il pallino del ball-caster infatti, quando attraversa la fuga tra le mattonelle, fa rumore.

Il robot è aperto a soluzioni: la licenza vi permette di parlarne sul vostro sito illustrando le modifiche che avete fatto (purchè citiate sempre questo articolo e l’autore) e i professori delle scuole, soprattutto, possono anche contattarmi per avere l’accesso ai files sorgente di Tinkercad. Ad ogni modo, se fate delle modifiche e trovate altre soluzioni, vi invito sempre a contattarmi in modo che possiamo ampliare il progetto e illustrare alternative perchè AR.L.O. è lungi dall’essere perfetto.

Batterie / Alimentazione

Per le batterie ho scelto la soluzione più spicciola e a portata di mano nelle case di tutti: batterie stilo (AA). Sulla mia versione del robot utilizzo un unico portabatterie per 4 stilo, montato tra le staffe dei servocomandi e la base del piano superiore che ha delle ali per accoglierlo. 4 batterie stilo classiche, ovvero non ricaricabili, forniscono 6V, che vanno bene per i servocomandi che richiedono proprio quella tensione per poter funzionare. Utilizzando un’unica fonte di alimentazione a 6V non è possibile fornire tale tensione direttamente ad Arduino. Come escamotage low-cost, nel caso in cui si decidesse di utilizzare solo le 4AA, ho previsto un diodo in serie alla 6V solo per la logica. Il diodo introduce una caduta di tensione pari a circa 0.7V per cui alle logiche arrivano tra 5.3V e 5.4V, prima di fare questa operazione, però ho fatto comunque delle considerazioni per capire se potevo utilizzare questa tensione (fino a 5.5V) senza rompere nulla. Illustro qui l’analisi che ho fatto:

Considerazioni sull’utilizzo di una tensione superiore a 5V

Da datasheet l’ATMega328 a bordo di Arduino Uno può funzionare fino a 5.5V, così come anche gli ATmega8U2 e 16U2 (utilizzati sull’UNO come bridge seriale – datasheet) e l’ATmega32U4 (unico chip su Arduino Leonardo – datasheet).

Su Arduino UNO ci sono altri integrati: LM358 (fino a 32V, datasheet), LP2985-33 (fino a 16V, datasheet), MC33269 (fino a 20V, datasheet). Anche su Arduino Leonardo ci sono altri integrati: un LMV358 (fino a 5.5V, datasheet), LP2985-33 (fino a 16V, datasheet), NCP1117 (fino a 20V, datasheet)  quindi per questi modelli di Arduino non ci sono problemi. A bordo del robot, però, oltre ad Arduino ci sono altre logiche che devono funzionare a 5V: abbiamo il sensore ad ultrasuoni HC-SR04 ed eventualmente il display OLED e il modulo Bluetooth.

Qui faccio solo un’analisi delle tensioni di funzionamento, vi illustrerò i moduli di cui parlo più in basso

Il Sensore HC-SR04 è dichiarato per funzionare a 5V ma non tutti i produttori specificano un range di funzionamento. Ho comunque analizzato lo schema di questo sensore: a bordo ha 3 circuiti integrati: un amplificatore operazionale  LM324 (in alternativa un TL074), un MAX232 e un microcontrollore STC11F. Gli operazionali (LM324 e TL074) sopportano tensioni ben più alte (10V per il TL074, molti di più per l’LM324), il MAX232 lavora fino a 6V e il micro STC11F da datasheet arriva a 5.5V, quindi per il sensore non ci sono problemi fino a 5.5V.

I sensori HC-SR04 che utilizzavo 8 anni fa, che avevano il PCB di colore verde, oltre ad avere il MAX232, rimasto invariato, come operazionale avevano l’LMC6034 (fino a 16V, datasheet) ed un microcontrollore Elan EM78P153 (di cui non si riesce più a recuperare il datasheet perchè credo sia un prodotto obsoleto, penso possa essere stato sostituito dall’EM78P153K che arriva fino a 5.5V, datasheet, e ho buone ragioni per pensare che anche il precedente arrivi alla stessa tensione).

Il display OLED è basato sul classico SSD1306. Da datasheet questo controller funziona da 1.65 a 3.3V ma il display viene venduto come compatibile 5V: questo perchè a bordo c’è un minuscolo regolatore di tensione che scala la 5V a 3.3V. Tenendo da parte la tensione, che è assicurata dal regolatore che accetta in ingresso più di 5V (c’è un regolatore XC6206P, Q1 -disegnato sugli schemi cinesi come fosse un transistor!- che arriva a 6V – vedi schema display – vedi datasheet regolatore), ci sarebbe da analizzare la parte relativa al level-shifting dei segnali logici dato che i livelli sulle linee SDA/SCL devono giungere al controller necessariamente a 3.3V, tensione a cui viene fatto funzionare il controller. Sui display OLED 128×32 Adafruit la conversione dei segnali su SDA/SCL da livello logico alto 5V a 3.3V è affidata a mosfet collegati alla linea dei 3.3V per cui, anche in questo caso, non ci sono problemi (vedi schema di riferimento). Su quelli cinesi, come quello che ho io, dato il basso costo, non vengono usati mosfet e comunque non sono strettamente necessari nel caso in cui sul bus I2C il livello di tensione venga stabilito dal display stesso: sappiamo bene che le linee dell’I2C sono open-drain (i dispositivi che comunicano tra loro tirano solo la linea verso il livello basso, mentre quando bisogna andare a livello alto, vanno in alta impedenza e il livello è fornito da resistenze di pull-up). Sullo schema del display cinese SDA e SCL sono portati a livello alto (verso la 3.3V fornita dal regolatore) on-board con due resistenze da 4.7kΩ e in più Arduino UNO e Leonardo (vedi schema) riportano i due pin SDA e SCL sull’header senza resistenze di pull-up, il che significa che il livello logico alto non può arrivare ai 5.3V che stiamo fornendo ad Arduino ma viene determinato dall’altro dispositivo posto sul bus (che ha il pull-up verso 3.3V), quindi anche per il display non c’è problema! Ad ogni modo a display alimentato a 5.5V, con le linee di comunicazione scollegate, ho misurato la tensione sui pin SDA e SCL e questa oscilla tra 3.2 e 3.3V confermando quello che ho detto.

Il modulo Bluetooth che utilizzo, un diffuso HC-05 (ma la considerazione vale anche per il modulo HC-06) viene generalmente venduto saldato su una breakout board (una schedina blu che ha un pin-strip maschio da 6 pin) sulla quale c’è un minimo di circuiteria. La breakout board viene alimentata a 5V ma a bordo c’è un regolatore di tensione a 3.3V in formato SOT-23 a 5 pin (potrebbe essere un Microchip TC1055-3.3 o un Texas Instruments LP2985 o magari anche altri, non ho approfondito). Questi regolatori arrivano come minimo a 6V in ingresso o 5.5V nel peggiore dei casi, quindi ci teniamo buona una tensione di alimentazione del modulo di massimo 5.5V, quindi nessun problema lato alimentazione. Sul livello logico invece il problema c’è ma ci sarebbe stato in ogni caso, anche alimentando il modulo con 5V precisi. Questi moduli Bluetooth, difatti, richiedono sempre che esternamente venga messo un partitore di tensione sulla loro linea di ricezione nel caso in cui il dispositivo con cui comunicano non lavori a 3.3V. Sul PCB della breakoutboard del modulo si legge chiaramente: Level: 3.3V. Sul PCB di ARLO ho predisposto il partitore formato da R1 e R2 dalla linea TX di Arduino verso la linea Rx del modulo Bluetooth. Con i valori specificati nello schema (R1=15kΩ e R2=22kΩ), al modulo bluetooth arriverà un livello logico massimo di 3.3V se l’alimentazione è 5.5V.

VOUT=VIN*(R2/R1+R2)=VIN*0.5945

Il range di tensione sul pin RX del modulo è quindi da 3.3V (tetto massimo, alimentando con Vservo a 6V) a 2.67V (tetto minimo, alimentando con 3 pile AA): non superiamo il massimo ammesso e rientriamo nei 2V minimo per far considerare valido il livello (tutorial sparkfun sui livelli logici). Per la linea di comunicazione opposta, da TX del modulo a RX di Arduino, non c’è bisogno di fare nessun adattamento perchè i 3.3V forniti dal modulo vengono già interpretati correttamente dalle logiche a 5V.

Il PCB di AR.L.O., comunque ha due ingressi per due tensioni separate: una per la tensione dei servo (6V) e una per la tensione logica (VDD). E’ quindi possibile utilizzare un portapile aggiuntivo per 3 stilo (4.5V) da mettere sotto al pianale per alimentare la sola logica; in questo modo le tensioni di alimentazione (servo e logica) sono separate e si minimizzano anche eventuali disturbi. Questa soluzione però l’ho provata ben poco perchè mi sono trovato bene con il solo portapile da 4 stilo. Ho provato anche ad utilizzare anche una sola fonte di alimentazione a 4.5V sia per logica che per i servo ma la maggior parte dei servo standard si comporta in maniera instabile: girano come gli pare indipendentemente dai comandi inviati, solo alcuni servo più sofisticati riescono a funzionare correttamente con 4.5V.

Volendo, ancora, è possibile utilizzare il portabatterie per 4 stilo con batterie ricaricabili NiMH: dato che queste hanno una tensione di 1.2V, avremmo un totale di 4.8V : in questo caso, però, non tutti i servo potrebbero funzionare correttamente e in aggiunta al posto di D1 dovremo mettere un ponticello perchè se scaliamo la tensione arriviamo a 4.1V e dubito che le logiche funzionino tutte correttamente.

Più in basso, al paragrafo PCB, ho illustrato come connettere le batterie. Se dovete acquistare le batterie, vi consiglio di prendere confezioni con un certo numero, come queste.

Servocomandi

Perchè usare un servocomando al posto di un motoriduttore? I motivi sono molto semplici: i servocomandi hanno dimensioni standard, contengono un motore con le riduzioni, costano molto poco e sono molto facili da trovare, e, cosa forse più importante di tutte: hanno l’elettronica di pilotaggio del motore a bordo, il che vuol dire che non abbiamo bisogno di un ponte H per dare corrente al motore: questo riduce ulteriormente costi e dimensioni. Chiaramente non è possibile usare i servocomandi così come sono dato che, sappiamo bene, hanno una corsa limitata. Anche se in commercio esistono già servocomandi a rotazione continua, vediamo di seguito come modificare due servocomandi standard RC per farli diventare a rotazione continua.

Modifica dei servocomandi

Sui miei AR.L.O. ho usato dei servocomandi XQ Power modello XQ-S3003S e MG996R. I primi sono servocomandi buoni, ad un buon prezzo, e che a differenza di molti ultra-economici hanno il cuscinetto a sfera sull’albero di uscita, ma sono difficili da trovare. I secondi sono molto comuni e hanno gli ingranaggi in metallo, una costruzione molto solida con cavi più spessi e invece dei cuscinetti hanno delle boccole in metallo.

Attenzione: sul PCB ho messo i connettori dei servo con un pinout standard: ovvero con il terminale di alimentazione, 6V, al centro. Generalmente la stragrande maggioranza dei servo usa questo pinout (segnale-tensione-gnd, sul PCB li ho indicati come S + -) anche se possono cambiare i colori dei fili. Mi sono capitati in passato dei servocomandi che non seguivano questo pinout: in questo caso l’unica cosa da fare è spezzare il connettore e saldarne uno nuovo oppure, se ci riuscite, sfilare delicatamente i terminali dal connettore originale e riallinearli.

La modifica per la rotazione continua è molto semplice e consiste in due operazioni: rimozione del notch dall’ingranaggio del perno di uscita e sostituzione del potenziometro (che funge nei servo da sensore di posizione) con due resistenze di uguale valore. In pratica il servo, leggendo sempre un valore “centrale” sull’IO del potenziometro, crederà che l’albero si trovi sempre al centro e quindi l’elettronica a bordo continua far ruotare il motore anzichè fermarlo. Il notch viene messo solo per sicurezza.

Alcuni servo più sofisticati, però, rilevano la condizione di rotazione continua: si accorgono, cioè, che nonostante stiano dando corrente al motore e questo gira (tra l’altro ne rilevano anche l’assorbimento), la posizione restituita dal sistema di feedback (il potenziometro) rimane sempre al punto centrale, quindi, non sapendo cosa stia accadendo in realtà, dopo un po’ fermano il motore. Per questo è forse meglio necessario utilizzare dei servo analogici classici.

Nelle seguenti foto viene illustrato come ho fatto la modifica (leggere la descrizione in basso per ogni foto e spostarsi usando le frecce):

modifica_servo_014

◄ Indietro
Immagine 14 di 14

Il lavoro è finito: possiamo richiudere tutto.

Arduino UNO

Dopo alcune prove, consiglio di utilizzare un Ardui Arduino Leonardo NON va bene perchè il codice di esempio utilizza il Timer 2 che il Leonardo non ha, per cui da errore nella compilazione! Stiamo cercando sistemi alternativi

Duemilanove anche se è praticamente uguale all’UNO (differiscono nel modello del bridge USB, sull’UNO hanno usato un chip della stessa Atmel) perchè manca dei pin aggiuntivi SDA/SCL sull’header esterno che sono necessari al display. Ma, dato che il display è un accessorio, se avete un vecchio Duemilanove nel cassetto potete usarlo ugualmente.

In realtà anche su Arduino Duemilanove ci sono i pin SDA e SCL: sono condivisi con gli ingressi analogici A4 e A5, questo vale anche per Arduino UNO

Sensore Ultrasuoni HC-SR04

Qui non ho nulla da dire se non che costa due soldi e che ne ho già parlato abbondantemente 8 anni fa: da allora è solo cambiato il colore del pcb.

Sensore Ultrasuoni HC-SR04

Potete acquistarlo su Futura Elettronica a questo link.

Display OLED

Ho predisposto il circuito e il codice per l’utilizzo di un piccolo display oled da 0.91″ con una risoluzione di 128×32 pixel. Molto utile per la taratura del punto zero dei servocomandi e per mostrare altre informazioni. Ad ogni modo non è necessario perchè la taratura si può fare anche senza. Altre info sul display le ho date più alto quando ho parlato della tensione di alimentazione. Si trova su Futura Elettronica a questo link.

Display OLED I2C 0.91″ 128×32

Modulo Bluetooth

Personalmente ho usato un comune modulo HC-05, ma va bene anche l’HC-06: tra poco vedremo le differenze. Dato che viene venduto il modulo HC-05 anche come a sè stante, ho specificato di prendere quello montato sulla breakout board: la board riporta all’esterno i pin RX/TX del modulo e ha il regolatore di tensione a bordo per far funzionare il modulo a 3.3V. Come specificato in alto, però, i livelli di comunicazione sono a 3.3V ecco perchè è necessario mettere un partitore tra la linea TX di Arduino, che lavora a 5V, e la linea RX del modulo.

Modulo Bluetooth HC-05 montato su Breakout Board con collegamento a 6 pin

Quando innestate il modulo bluetooth controllate il pinout: ho utilizzato il pinout più diffuso di questi moduli e sulla serigrafia ho indicato TX e RX di Arduino, non del modulo. Quindi il pin RX del modulo va allineato col pad TX e viceversa, ma più in basso c’è uno schema di collegamento.

Il modulo bluetooth è un accessorio e può essere utile per sperimentare ulteriormente: avere un debug, ad esempio, sul cellulare utilizzando un software qualsiasi che fa da terminale o possiamo anche realizzare un’app, magari tramite MIT App Inventor, per poter pilotare il robottino dal cellulare o semplicemente avere una dashboard con indicazioni e letture di sensori fornite dal robot. Ancora potremmo utilizzare un’app android, Bluetooth Electronics, che è un semplice tool di comunicazione seriale over bluetooth ma con gli steroidi: ci da la possibilità di costruire interfacce con pulsanti ai quali possiamo associare comandi da inviare via seriale.

Differenze tra il modulo Bluetooth HC-05 e HC-06

Il modulo HC-05 può anche fungere da master oltre che da slave, a differenza dell’HC-06 che funziona solo come slave. A noi non interessa la funzionalità master dato che sarà sempre il cellulare a fare il master. Un’altra differenza tra i due moduli sta nella modalità di funzionamento attiva all’avvio: il modulo HC-06 si avvia in modalità AT (può accettare da subito comandi per la configurazione), mentre l’HC-05 non accetta comandi AT all’avvio e per mandarlo in questa modalità bisogna premere il pulsantino on board.

Questi moduli, oltre all’alimentazione e alle linee uart hanno altri due pin: STATE, che è il pin a cui è collegato il led on-board che lampeggia in modalità diverse a seconda delle modalità attive, e un altro pin che a volte è riportato come KEY, altre volte come EN.

In genere quando c’è EN si tratta di un pin per spegnere il modulo: mandando un livello basso si spegne, lasciandolo scollegato o a 3.3V il modulo si accende. Quando è riportato come KEY potrebbe non servire a nulla (HC-06) o per attivare la modalità AT sul modulo HC-05: in questo caso dato che il pin per la modalità AT è tenuto normalmente a livello basso con una resistenza di pull-down, per entrare in questa modalità dal pin (cioè senza premere il pulsante) bisogna mandarlo a livello alto (3.3V). Il problema di questi moduli è che ogni produttore è d’accordo sul pin STATE ma ognuno fa un po’ quello che gli pare con l’altro pin KEY o EN, per tale motivo sul PCB di AR.L.O. ho messo un connettore a 6 pin per il modulo ma i due pin laterali non li ho collegati a nulla. Esistono poi alcune breakout board che non hanno i pin disposti allo stesso modo: a quel punto dovete utilizzare l’area millefori e fate voi un adattatore.

Il connettore per il modulo Bluetooth lo potete utilizzare anche per collegare altri dispositivi di comunicazione, basta che state attenti alla tensione di alimentazione del modulo che volete usare (i moduli ESP-01 vanno alimentati a 3.3V) e al pinout.

Poi non abbiamo una stretta necessità della modalità AT: questa viene utilizzata per cambiare la configurazione del modulo ovvero cambiarne il baudrate (default 9600bps sull’HC-05), la password di accesso (default 1234 sull’HC-05, a volte 0000), il nome (default HC-05) ecc. Sul modulo HC-05, quando si entra in modalità AT il baudrate non è più 9600 ma 38400 e durante questa modalità non è possibile collegare un dispositivo bluetooth.

Sul modulo HC-06, che ha la modalità AT attiva di default, immagino che la comunicazione tramite bluetooth e la possibilità di inviare comandi AT siano funzionali contemporaneamente, se avete usato un HC-06 magari contattatemi per poter confermare questa cosa.

Se volete cambiare i parametri di configurazione del modulo è necessario un adattatore UART/USB e un programma di comunicazione, i comandi AT utilizzabili sono elencati qui. Se utilizzate il mio adattatore UART/USB, dovete settarlo a 3.3V (Jumper chiuso verso il connettore USB, c’è la scritta 3V3) e prendere la 5V per l’alimentazione della breakout board da quello stesso jumper, dal pin rimasto libero (non occupato dal jumper) che è collegato alla 5V fornita dalla porta USB.

Potete acquistare, a scelta, su Futura Elettronica il modulo HC-05 oppure l’HC-06.

Shield AR.L.O. by PCBWay

Lo Shield di AR.L.O. l’ho disegnato per poter accogliere con facilità i vari componenti elettronici a bordo del robot e dare maggiore sicurezza e comodità nella realizzazione del robot. Ringrazio PCBWay che ha supportato questo progetto fornendomi la realizzazione del PCB. Questa volta ho voluto provare il colore viola perchè piuttosto inusuale e potete notare l’estrema cura con cui i PCB sono realizzati:

Questo è lo schema elettrico:

Ho immaginato che sia meglio montare l’Arduino UNO con la porta USB verso la coda del robot e che quindi noi ci trovassimo sempre dietro di esso (per la programmazione, per seguirlo ecc) e quindi le scritte sono ottimizzate per essere viste da questo lato. Su un lato ci sono i due connettori a vite per l’alimentazione con l’indicazione di positivo e negativo: su V Servo andrà la tensione fornita dalle 4 batterie AA. Nel caso in cui volessimo utilizzare un solo pacco batterie (quello da 4 stilo), allora il jumper posto dietro i connettori a vite (JP1) va messo sulla posizione  VServo (verso destra, in direzione del diodo): in questo modo, come dicevo più in alto, alle logiche arriverà la 6V scalata dal diodo D1 (quindi circa 5.3∼5.4V). Un altro jumper (Power) può essere utilizzato per disconnettere la sola tensione logica: qui può anche essere messo un piccolo interruttore con passo da 2.54″ come ho fatto io. L’altro connettore a vite (VDD) va usato nel caso in cui alle logiche volessimo fornire un’alimentazione separata: in questo caso J1 va chiuso verso la dicitura VDD (verso sinistra, in direzione dei connettori dei servo).

Nel disegno di seguito viene mostrato come fare per alimentare AR.L.O. (sia servocomandi che logiche) con una sola sorgente costituita dal pacco batterie da 4 stilo (che va posizionato tra pianale superiore della struttura e staffe dei servocomandi):

Nel disegno che segue, invece, viene illustrato come configurare la scheda per poter utilizzare due alimentazioni separate (il pacco da 3 stilo andrebbe installato sotto al pianale inferiore, tra ruote e ball-caster, sfruttando i due/tre fori centrali):

Se i servo assorbono poca corrente e quindi non creano sbalzi di tensione, si può utilizzare la prima soluzione (solo le 4 batterie AA), se invece notate che il modulo Bluetooth si resetta o addirittura si resetta Arduino, provate prima ad aumentare il valore dei condensatori sulla scheda e anche ad aumentare l’ampiezza della rampa di decelerazione dei servo durante uno stop o un cambio direzione (i cambi improvvisi portano a picchi di assorbimento). Se anche questo non risolve i reset, allora è necessario utilizzare la seconda soluzione con il pacco batterie aggiuntivo per alimentare la sola logica.

All’altra estremità del PCB va collegato il sensore ultrasuoni rispettando la piedinatura riportata sulla serigrafia, che combacia con quella del sensore orientato con il quarzo verso il basso. Potete collegare il sensore utilizzando 4 cavetti jumper femmina/femmina oppure fare come ho fatto io (soluzione consigliata): rimuovere l’header dal sensore ultrasuoni e saldare 4 fili che terminano con un connettore molex femmina con passo da 2.54mm, da innestare sul maschio saldato sul PCB:

Questa soluzione è la migliore, altrimenti dovrete piegare verso l’alto l’header del sensore durante il montaggio perchè tocca sul vano batterie e non potete innestare i cavetti jumper. Potete utilizzare o un’accoppiata connettore femmina munito di cavi + maschio da montare sul circuito stampato oppure un cavo maschio/femmina da innestare direttamente sull’header del sensore (dopo avero piegato).

Qui ho fatto un piccolo schema che illustra come vanno collegate le elettroniche esterne:

Particolare attenzione va prestata al modulo Bluetooth: normalmente il verso di innesto è quello indicato nella foto: il pin RX del modulo deve entrare nel pad contrassegnato con TX e il pin TX in quello RX. I due pin esterni (STATE e KEY o EN) non sono collegati. Verificate la piedinatura del vostro modulo Bluetooth prima di innestarlo! E non innestatelo al contrario (è facilissimo sbagliarsi, è capitato anche a me parecchie volte ma per fortuna non è successo nulla!). Come detto sopra dovete fare molta attenzione anche al pinout dei servocomandi, verificate sul sito del produttore dei vostri servo che il pinout sia quello giusto, altrimenti dovete modificare il connettore del servo con un po’ di fantasia.

Sul PCB sono riportati anche due header (EXT1 e EXT2) con i pin rimasti liberi. In particolare l’header EXT1, sotto al connettore per l’ultrasuoni, l’ho immaginato per un eventuale futuro modulo aggiuntivo line-follower (non ancora realizzato): ci sono 3 IO da sfruttare per il sensore di linea centrale e i due laterali. Gli ingressi analogici, tranne lo zero che è occupato dal trimmer, sono riportati su pad quadrati in basso. Il trimmer collegato ad A0 servirà nel firmware di esempio per la regolazione del punto zero dei servocomandi. Nella parte centrale del PCB c’è una utile area millefori che si presta a modifiche e aggiunte.

Attenzione: se intendete utilizzare gli ingressi analogici A4 e A5, sappiate che questi sono condivisi con SDA e SCL

Elenco componenti per PCB

La maggior parte dei componenti possono essere acquistati da Futura Elettronica, per cui troverete il link diretto alla pagina del prodotto: acquistando questi prodotti dal link contribuite a mantenere attivo questo sito; la spedizione è dall’Italia, viene usato il corriere espresso e i costi di spedizione sono molto contenuti (si paga €4,90 iva inclusa con Bartolini -consegna 1 o 2 giorni- fino a 30Kg e fino a €90 di spesa, dopo i €90 la spedizione è gratuita!).  Ho preparato un foglio di lavoro con Google Spreadsheet per l’elenco di tutte le parti per costruire il robot.

I condensatori elettrolitici, quelli multistrato, il led e le resistenze possono essere acquistati su Futura Elettronica in comodi kit che vi permettono di avere anche una certa scorta di componenti utili per progetti futuri, vi lascio qui i link:

Montaggio PCB

Non ci sono particolari accorgimenti per la saldatura dei componenti: è necessario rispettare le misure dei componenti specificate e usare degli header maschio più lunghi del normale per il collegamento tra shield e Arduino. I normali header hanno, infatti una lunghezza totale di 11.5mm, con la parte sottostante (quella che entrerebbe negli header femmina di Arduino di 6mm: questi header non vanno bene perchè altrimenti il connettore USB di Arduino UNO è molto ingombrante e tocca sotto lo shield mettendo in corto delle saldature.

Con Arduino Leonardo, che ha un connettore micro-usb, si risolve in parte ma c’è comunque il barrel-jack, che seppur di plastica, tocca ugualmente lasciando parte dello shield alzato: in questo caso la soluzione potrebbe essere quella di dissaldare il connettore barrel dato che non lo utilizziamo. Ma come detto sopra: per ora Leonardo non è supportato dal codice di esempio

I normali header che vengono venduti per Arduino (quelli passanti) hanno una lunghezza dei pin di 10.5mm. Su Ebay, comunque, è possibile cercare male header long per avere un’inserzione in cui è possibile acquistare degli header specificandone la lunghezza: quella minima è 15mm che dovrebbe essere il totale, per cui togliendo i 2.5mm della parte plastica e i 3mm della parte da saldare, avanzano 9.5mm che poterbbero essere sufficienti: ad ogni modo verificate col venditore che i 15mm siano totali perchè io qui non ho acquistato. Avevo degli header lunghi da un vecchio acquisto e ho usato quelli, altrimenti, ripeto, la soluzione è provare con Arduino Leonardo, dissaldare il connettore di alimentazione e usare header standard.

La galleria sottostante illustra le fasi del montaggio del PCB passo passo, leggete le descrizioni sotto alle foto:

cof

◄ Indietro
Immagine 1 di 23

PCB di ARLO

Qui c’è anche una GIF animata che mostra la sequenza del montaggio:

Montaggio Telaio

Dopo aver preparato i servo, montato il PCB, e stampato i pezzi con la stampante 3D, possiamo procedere all’assemblaggio. Seguire le foto passo passo leggendo la descrizione sotto ogni foto:

montaggio_arlo_0001

◄ Indietro
Immagine 1 di 44

Pezzi stampati in 3D di cui si compone il telaio. Qui ho utilizzato il PLA+ "Pure Yellow" della SUNLU

Ricapitoliamo

Riepilogo qui l’elenco del materiale che ho utilizzato io, come riferimento, ma vi invito a fare modifiche per usare il materiale che avete voi. All’ultimo paragrafo, Links, ho messo un foglio di lavoro Google con l’elenco dei materiali, prezzi e link dove acquistarli.

  • Pezzi stampati in 3D (plate_base, plate_top, 2x servo_bracket, pillar_HC-SR04, pillar_hole_6mm oppure pillar_hole_10mm) (link su github) – necessari almeno 42m in totale di filamento
  • 2 Ruote stampate in 3D (my_servo-wheel se utilizzate i miei stessi servocomandi, ovvero l’ XQ-S3003S oppure l’MG996R, il mio stesso tipo di O-Ring e il mio stesso ball-caster, altrimenti dovete generarvi da soli la ruota utilizzando lo script scaricabile qui)
  • Due servocomandi modificati. Consiglio l’MG996R perchè è tutto in metallo, solido ed è eventualmente riconvertibile in servo normale dopo la modifica.
  • 2 O-Ring in gomma nera (consigliato diametro interno 70mm, sezione 2.5mm)
  • Kit ball-caster Tamiya 70144
  • Viti, Dadi, rondelle e distanziali come elencato sopra
  • Componenti elettronici, elencati sopra
  • Arduino UNO Rev.3
  • Shield AR.L.O. by PCBWay – fate attenzione agli header per il montaggio su Arduino come specificato nell’elenco componenti del PCB!! O header maschio lunghi o kit di header passanti specifici per Arduino

Questo è il risultato finale, in alcune foto compare la primissima versione (quella tutta colorata) che era più piccola perchè stavo usando dei rari servocomandi che riuscivano a funzionare con solo 4.5V e usavo solo il portabatterie da 3 stilo sotto al pianale inferiore:

Codice sorgente

Installazione librerie

Prima di tutto è necessario installare su Arduino IDE alcune librerie. Basta andare in Strumenti > Gestione librerie scrivere il nome della libreria (quello scritto in grassetto nella lista che segue), premere invio per cercare e cliccare sul pulsante Installa nella casella dove compare la libreria precisa. Dato che possono esserci varie librerie con nomi simili, leggete bene quali sono gli autori, che ho riportato in corsivo:

  • Adafruit SSD1306 by Adafruit (questa ha bisogno di una libreria aggiuntiva che verrà installata automaticamente dopo un pop-up che vi richiede il permesso di farlo)
  • Adafruit GFX by Adafruit
  • TimerOne by Jesse Tane, Jérôme Despatis, Michael Polli, Dan Clemens, Paul Stoffregen

Bisogna installare ancora un’altra libreria che non compare nella lista di Arduino IDE per cui dovremo farlo a mano. Andare all’url https://github.com/nabontra/ServoTimer2 premere il pulsante Clone or download e quindi Download ZIP. Estrarre il file ZIP (estrai qui se usate 7zip): si genera la cartella ServoTimer2-master, rinominarla in ServoTimer2. Copiare questa cartella nella cartella delle librerie Arduino in documenti (Faccio riferimento a Windows: Documenti/Arduino/libraries). Dopo averla copiata, giusto per sicurezza, controllate che all’interno di questa cartella ci sia una cartella examples.

Se Arduino IDE era aperto, dobbiamo chiuderlo e riavviarlo per fargli vedere questa libreria installata a mano. 

Ora è possibile scaricare il programma di esempio per far muovere AR.L.O. Si trova nel mio repository Github a questo indirizzo. Se volete evitare di clonare tutto il repository, copiate solo il codice e incollatelo nella finestra di Arduino IDE. Selezionate la scheda che state utilizzando e provate solo a compilarlo senza caricare: premete il tasto di spunta. Se la compilazione va a buon fine, siete già a buon punto, altrimenti vuol dire che non avete installato qualche libreria o avete selezionato la scheda sbagliata.

Funzionamento del codice

Partiamo dalla gestione del sonar: questo viene controllato tramite interrupt per non bloccare il programma aspettando di fornirgli il trigger e controllare la risposta: in tutto questo tempo il robot potrebbe benissimo sbattere senza accorgersi dell’ostacolo! L’idea della lettura del sonar tramite interrupt è di Steve Garrat. Per questo motivo vi ho fatto installare la libreria TimerOne che consente di impostare con facilità un interrupt per overflow sul Timer1 con il quale gestiremo il triggering del sensore.

Il Timer viene impostato per generare un interrupt ogni 50µS. Questo interrupt viene agganciato alla funzione timer1_ISR. Qui utilizziamo una macchina a stati ed è bene che vi ricordiate come funziona il sonar. La prima volta che scatta l’interrupt ci troviamo nello stato 1: viene mandato a livello alto il pin di trigger, si imposta un contatore trigger_time_count e ci si posiziona per lo stato 2. La seconda volta che scatta (dopo altri 50µS) ci troviamo quindi nello stato 2 e il pin di trigger viene portato a livello basso: l’impulso sul trigger è durato quindi 50µS, da datasheet deve durare almeno 10µS. Si torna allo stato zero, ovvero non si fa nulla: quando trigger_time_count raggiunge lo zero si ricomincia daccapo inviando un nuovo impulso sul trigger.

Il contatore arriva a zero dopo 225mS, impostati da TICK_COUNTS (4500*50µS=225000µS). Ricordo dal mio articolo che quando il sonar non rilevava nulla, ovvero dopo circa 3m, mi veniva restituito un echo di 222mS. L’articolo però è di molti anni fa e operazionale e microcontrollore sulla board sono cambiati da allora… altri test non ne ho fatti.

Nel frattempo l’impulso di ritorno viene monitorato da un pin al quale abbiamo agganciato un interrupt sul cambio di stato che abbiamo chiamato sonarEcho_ISR. In quest’altra funzione controlliamo se il cambio di stato del pin di echo è stato da livello basso a livello alto o viceversa; nel primo caso vuol dire che l’impulso è appena arrivato e la sua durata (cioè fino a che non ridiventa basso) sarà proporzionale alla distanza rilevata. Viene quindi memorizzato il valore del contatore micros() di Arduino. Dopo un po’ scatterà un nuovo interrupt causato dal nuovo cambio di stato di echo da alto a basso: a questo punto dal contatore micros() attuale si sottrae il valore memorizzato prima e abbiamo quindi la durata dell’impulso di echo da cui ricaviamo la distanza. Il valore di distanza rilevato viene salvato in una variabile globale in modo che sia disponibile anche al Loop. Tutto questo deve essere eseguito nel tempo tra un trigger e il successivo.

Nota importante, già specificata nelle fasi di montaggio: il sensore ultrasuoni deve stare tutto fuori: se le capsule vanno a filo con la staffa, le letture sono sballate e il robot comincia a rilevare ostacoli anche se non ci sono.

Per la gestione dei servo ho scelto di non utilizzare la funzione standard di Arduino ma una modificata che vi ho fatto installare a mano, ServoTimer2, che per la generazione del PWM per pilotare i servo si avvale del Timer2 piuttosto che dell’1, che, come avete visto, stiamo sfruttando per gestire il sonar e non possiamo quindi utilizzare per altro.

Avrei anche potuto usare, per generare l’interrupt, una libreria che sfrutta il Timer2 per generare l’interrupt e lasciar perdere la libreria alternativa per i servo. Potete provarci voi e mandarmi il codice riveduto.

Questa funzione, diversamente da quella standard di Arduino, non accetta come parametro l’angolazione in gradi, bensì la durata in microsecondi dell’impulso di pilotaggio, come abbiamo imparato quando abbiamo parlato di come funzionano i servo.

Il codice non fa altro che far andare AR.L.O. dritto (i due servo, dato che si trovano montati in maniera speculare, dovranno girare uno in un senso e l’altro nel senso opposto per far andare AR.L.O. dritto). Nel momento in cui la distanza rilevata dal sonar è al di sotto di una certa soglia (parametro OBSTACLE), il robottino si ferma e con una funzione random sceglie di andare a destra o sinistra.

Il valore di OBSTACLE non deve essere troppo basso perchè c’è una certa lentezza di aggiornamento dovuta alla gestione del display, il valore attuale nel codice è un buon compromesso.

Lo stop del robot, però, non è immediato dal momento che causerebbe il ribaltamento del robot in avanti per la forza di inerzia (ricordiamoci che il ball caster sta solo dietro) ma c’è una piccola rampa di decelerazione. E’ possibile difatti variare la velocità dei servo fornendo un impulso di diversa durata. Ricordo come funzionano i servo: tenendo 1500uS come valore di servo in posizione centrale (fermo nel nostro caso), al di sopra di tale valore il servo ruoterà in un verso e al di sotto nel verso opposto, ma più siamo vicini al valore di 1500 tanto più il servo girerà lentamente, altrimenti in condizioni normali (servo non modificato) non riuscirebbe a fermarsi in tempo per riportarsi precisamente al centro, per cui il comportamento normale è che la velocità di rotazione del servo diminuisce man mano che si avvicina al punto centrale.

…E ricordiamo: il servo, che abbiamo modificato, crede di trovarsi sempre al punto centrale

C’è però da gestire il punto zero dei servo, dal momento che non tutti i servo si fermano precisamente al valore di 1500uS, specie questi che sono stati modificati. Per tale motivo ho predisposto una semplice funzione di setup.

Setup

Per il setup avete bisogno di qualcosa su cui appoggiare il robottino per fare in modo che le ruote siano libere di girare in aria senza toccare e di un piccolo cacciavite a taglio che entri nel cursore del trimmer VR1. Il setup è facilitato di molto dall’utilizzo del display, ma anche se non lo avete montato, può essere fatto ugualmente. Vi lascio qui un video che spiega come va fatto il setup

Licenza

Per questo progetto, nella sua interezza (schema, PCB, sorgente) ho scelto la licenza Creative Commons BY-SA-NC 4.0, ovvero in parole molto povere:

Si è liberi di condividere il progetto e farne modifiche a patto che (detto brevemente):

  • Sia indicato l’autore originale ed indicate chiaramente le eventuali modifiche fatte
  • Il progetto o qualsiasi sua parte non siano utilizzati a scopi commerciali (non ve lo potete vendere, ne nella sua interezza, ne in una sua parte)
  • La condivisione deve essere fatta allo stesso modo di come l’ho fatta io (stessa licenza)

Il testo completo della licenza è disponibile qui. Chiaramente non c’è nessun tipo di garanzia nè responsabilità: il progetto è fornito a titolo puramente didattico.

Links

Se avete necessità di un PCB contattatemi, vi lascio comunque il link su PCBWay da cui potete ordinarli direttamente senza fare ulteriori operazioni.

 

Se questo articolo ti è piaciuto, condividilo su un social:
      
Se l'articolo ti è piaciuto o ti è stato utile, potresti dedicare un minuto a leggere questa pagina, dove ho elencato alcune cose che potrebbero farmi contento? Grazie :)