Aiuto sviluppo codice per roving self balancing

Ciao a tutti raga… sto facendo vari test con un selfbalancing che puo’ essere definito il meno costoso del mondo :stuck_out_tongue: uso due microservi come unità motrici e 4 led ir per determinare l’inclinazione del robot (inclinati verso il pavimento). La differenza tra i due valori ottenuti se è 0 vuol dire che il robot è perpendicolare al terreno (sensori equidistanti davanti e dietro).

Per ottenere feedback dai led uso l’algoritmo ERER di mia invenzione con letture di 2500 microsecondi (letture molto veloci), analizzando un sensore per uno per evitare che riflessioni di un emettitore finiscano nel ricevitore dell’altro sensore. Per schermarli dalla luce ambientale uso questa scocca che ho progettato:
http://www.gioblu.com/prodotti?page=shop.product_details&flypage=flypage_images.tpl&product_id=184&category_id=63
Per la correzione uso il PID.

La parte strutturale è composta da delle ruote da 10cm che permettono un angolo di recupero decisamente migliore delle vecchie da 8 e 3 layers Pico 1.1

Questo è il video del robot in azione:

Questo test mostra la risposta dei sensori alle varie superfici e sembra che sia piuttosto buono come risultato visti i costi…

Questo è il codice:

#include <Servo.h>
#define frontEmitterPositive 5            // polo positivo emettitore
#define backEmitterPositive 3            // polo positivo emettitore
#define frontReceiverNegative 6          // polo negativo ricevitore
#define backReceiverNegative 4          // polo negativo ricevitore
#define servoLeftPin     10
#define servoRightPin   9
#define servoZero       90 //calibration 4 servos - calibrazione per servi  
long angle = 0;
long previousAngle = 0;
long frontDistance = 0;
long backDistance = 0;
int frontInterval = 2550;
int backInterval = 2500;
int setPoint = 0;
int switcher = 0;
float P = 0;
float I = 0;  //Il mesurement (empirism) - misurazione inerziale
float D = 0;
int fall = 0;       //value used to determine if the robot is fall
                    //variabile utilizzata per determinare se il robot è caduto
float kP = 2.5;      //used to tune
float kI = 150;
float kD = 1;
float time = 0;

Servo left; 
Servo right;


void setup() {
  left.attach(servoLeftPin);
  right.attach(servoRightPin);
  left.write(servoZero);
  right.write(servoZero);
  Serial.begin(9600);
  pinMode(frontEmitterPositive, OUTPUT);      // il led emettitore è un output
  pinMode(backEmitterPositive, OUTPUT);      // il led emettitore è un output
  //pinMode(irReceiverP, OUTPUT);    // il polo positivo del let ricevitore è un output
  //digitalWrite(irReceiverP, LOW);  // e deve essere LOW
}

void getOrientation() { focus(0); focus(1); }

void focus(int side) { 
 switcher = side;
 if(side == 0) frontDistance = frontReadLight(true) - frontReadLight(false);
 if(frontDistance - backDistance == 0) setPoint = frontDistance;
 if(frontDistance >= setPoint && setPoint != 0);
 if(side == 1) backDistance =  backReadLight(true) - backReadLight(false); 
}

double frontReadLight(boolean lightOn) {       
   digitalWrite(frontEmitterPositive, lightOn ? HIGH : LOW);
   pinMode(frontReceiverNegative, OUTPUT);
   digitalWrite(frontReceiverNegative, HIGH); //carico ricevitore di induttanza
   pinMode(frontReceiverNegative, INPUT);
   digitalWrite(frontReceiverNegative, LOW);
   long lightTime = micros(); 
   long frontReading = 0;
   while((micros() - lightTime) < frontInterval)
     if(digitalRead(frontReceiverNegative) == 0) frontReading++;
     return frontReading;
}
  
double backReadLight(boolean lightOn) {       
  digitalWrite(backEmitterPositive, lightOn ? HIGH : LOW);
  pinMode(backReceiverNegative, OUTPUT);
  digitalWrite(backReceiverNegative, HIGH); //carico ricevitore di induttanza   pinMode(backReceiverNegative, INPUT);
  pinMode(backReceiverNegative, INPUT);
  digitalWrite(backReceiverNegative, LOW);
  long lightTime = micros(); 
  long backReading = 0;
  while((micros() - lightTime) < backInterval)
    if(digitalRead(backReceiverNegative) == 0) backReading++;
    //Serial.print( " b ");
    //Serial.println(backDistance);
    return backReading;
}


void loop() {
 getOrientation();
 angle = frontDistance - backDistance;
 float previousTime = time;
 time = millis();
 float interval = time - previousTime;
      P = angle / kP;
      I = I + (P * interval) / kI;
      D = (angle - previousAngle) / interval / kD;
      float PID = P + I + D;
if(P > 90) P = 90; //stop increase or decrease of the value
if(P < -90) P = -90; //costrizione del valore tra 90 e -90
//if(orientation > 250) fall = fall + 1; 
//if(orientation < -250) fall = fall - 1;
if(PID <= 1 && PID > 0) PID = 0; //cut off micro-corrections
if(PID >= -1 && PID < 0) PID = 0;
left.write(90 + PID);
right.write(90 - PID); 
previousAngle = angle;
 /*Serial.print(P);
 Serial.print("  ");
 Serial.print(I);
 Serial.print("  ");
 Serial.print(D);
 Serial.print("  ");
 Serial.print( " f ");
 Serial.print(setPoint);*/
 Serial.print( " f ");
 Serial.print(frontDistance);
 Serial.print( " b ");
 Serial.print(backDistance);
 Serial.print( " a ");
 Serial.println(angle);           //spedisci a processing distanza
 
 
}

Adesso vorrei insegnargli a camminare in avanti, indietro e ruotare.
Secondo voi è complesso? Stavo pensando di aggiungere un semplice valore da sommare al PID per dare un offset allo 0 ma non so se basta…
Piu’ che altro ci sono tante considerazioni da fare, per esempio quando il robot va in avanti dovrà essere sempre inclinato indietro rispetto allo 0 di un angolo che varia in rapporto alla sua velocità (deve essere molto inclinato all’indietro al max per evitare di cadere in avanti)…

Ma quanto mi fa ridere quando va sul parquet, sembra ubriaco.
Il rov con il parkinson non l’avevo mai visto.

L’ho scaricato è quando sono giù di morale me lo guardo.

Ciao.

Hehehe ciao Mauro. Si è vero sembra fuori di testa sul legno. E' un comportamento decisamente randomico haahah Cmq il problema è che dovro' integrare un sistema che regola il valore 0 che poi sarà setPoint (che attualmente nel codice non viene considerato, lo stampo semplicemente in seriale), in rapporto al comportamento del robot, cioè il robot si posiziona su 0 ma cade sempre da un lato (problema finitura o colore superificie, vedi parquet), togli 1 a 0 e vedi se cadi ancora e cosi' via...

X deambulazione Il problema di base è delineare il metodo con cui si sposterà in una direzione, ma soprattutto renderlo con un algoritmo. Fondamentalmente se non ho visto male dai video dei self balancing PRO fatti da dio da Ing. vari quello che andrebbe fatto sarebbe lasciar cadere il robot nella direzione in cui ci si vuole muovere, fino a un punto tale da permettere al robot di poter partire senza cadere indietro (e questo angolo dipende dall'accelerazione, piu si accelera piu il robot dovrà essere inclinato verso il suolo per evitare di ribaltarsi indietro, pensate che movimenti fighi si potranno fare!!!!), conseguentemente portare la postura del robot inclinata nel senso opposto alla direzione di moto, con un angolo che varia in rapporto alla velocità del robot e alla decelerazione che si vuole applicare in futuro... hahaha sono sicuro che lesto qui impazzisce :grin: In poche parole quando va il robot deve sempre avere un angolo di offset rispetto al suo 0 naturale, che servirà per poter gestire la situazione e avere un margine inerziale per poter recuperare in entrambi i lati, in rapporto chiaramente alla sua inerzia, la sua velocità e la sua inclinazione...

Volendo si potrebbe proprio scrivere un sistema fisico :grin: Sono aperto e curioso di testare qualsiasi proposta

Ciao Gbm,

scusami ma non ho ancora avuto il tempo per rispondere al tuo invito, penso lunedì in mattinata d'iscrivermi sul tuo sito,

nel frattempo, quando mi ero dilettato nella stabilizzazione/autopilota di aeromodelli RC avevo utilizzato il filtro Kalman con gyro+acelerometri... il tuo bot se non ricordo male utilizza dei sensori IR posti sulla base per determinare il valore differenziale della distanza dal pavimento e di conseguenza azionare i servi corrispondenti per riportarlo a livello...

prova ad utilizzare il kalman come algoritmo di stabilizzazione passandogli il valore dei sensori IR, vediamo che succede :P

conosci diydrones?

ecco il link: http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A23188

ciao Kattivik76

Ciao Kattivik, ho usato piu volte il filtro di Kalman ma solo applicato a sistemi inerziali MEMS. Il problema è che non saprei come applicarlo a due input che sono sempre (o quasi) inversamente proporzionali. Io lo applicavo all'arco tangente di due assi dell'acc e a un giroscopio a singolo asse, ottenendo l'inclinazione assoluta del robot rispetto al terreno filtrata dal rumore e dal drift: http://www.gioblu.com/tutorials/programmazione/98-filtro-di-kalman-con-arduino Ma se devo dirvi la verità non ho mai fatto mio in toto il funzionamento del filtro, ho provato a farmelo spiegare da un'amica che studia ingegneria matematica, ma anche lei fatica a concepirne il funzionamento :grin:.

Rimango aperto a consigli / ipotesi su come fare l'algoritmo per la camminata in una direzione.

Volendo si potrebbe proprio scrivere un sistema fisico smiley-mr-green Sono aperto e curioso di testare qualsiasi proposta

Si scriviamolo, chiama la tua amica Matematica lei detta e io scrivo. :D

Parlando terra terra. Facciamo un'esperimento: Prendiamo il robo togliamo i 4 montanti e tetto (dove c'è la batteria). Alla base con le ruote monti un'antenna molto flessibile alto quanto i montanti di prima. Quando il robo è fermo in equilibrio perfetto l'antenna non oscilla ma se non è perfetto vediamo l'antenna oscillare avanti e indietro. L'estremità dell'antenna si sposta nella direzione contraria al moto il che evidenzia l'inerzia della parte superiore a seguire il vettore impresso dalle ruote. Questo a mio modo di vedere la cosa indica che per accelerare in questo verso ---> il robo deve essere sbilanciato nello stesso verso --->.

Il problema vero è proprio però è che non ci sono altre forze esterne che intervengono, non c'è la possibilità di spostare masse ammeno che non monto un ulteriore servo che sposta un peso da una estremità all'altra, senza questo ammesso di riuscire a fare un'accelerazione in equilibrio di ritrovi con il problema della decellerazione, che fa cascare il robo nello stesso senso di marcia.

Una prova che si potrebbe fare è intervenire via software, sommando un valore x alla distanza rilevata dal sensore. Se vuoi farlo andare avanti gli devi far credere che sta cadendo in avanti, ma poi il valore sommato devi subito togliero per riacquistare stabilità per poi introdurlo nuovamente e così via fino ad aver raggiunto la velocità voluta. Una sorta di PWM sul valore. Per evitare l'uso di masse mobili, e permettere la partenza devi fargli credere che sta cascando indietro per un tempo x, così lui recupera equilibrio andando indietro e allora che introduci il valore così non tentera di stare a zero ma inclinato in avanti e allore recupera accelerando.

Spiegarsi non è facile, io mi sono capito ma non è questo l'obbiettivo.

Ciao.

potresti imbrogliare il sistema sottraendo valori dai sensori (frontale o posteriore a seconda del moto) e poi rimettendoli a posto. senza sentire l'accelerazione però è difficile indovinare il momento per iniziare a rimettere a posto i valori dei sensori ed evitare di sbattere. per esempio , per andare in avanti, bisognerà aggiungere (gradualmente) altezza al sensore frontale cosicchè il sistema pensi di star cadendo indietro e reagisca tentando di portarsi in posizione eretta (senza mai riuscirci) fino a che decidiamo di fermarci sottraendo (gradualmente) altezza al sensore frontale fino ad avere la lettura originale invariata. L'aggiunta o la sottrazione di valori ai sensori, dovrà avere un andamento a rampa crescente o decrescente ed il valore critico da prevedere (senza accelerometro) è proprio la pendenza in salita e in discesa delle rampe, che credo sia funzione dei servi che usi e della velocità alla quale avviene il tutto.

Dunque ho fatto due disegnini, stanotte ho dormito bene (c’èra fresco) e mi sono alzato presto.

Al robo sono state aggiunte delle rotelle anti ribbaltamento R, i sensori S.
Ora non vedo perchè dover leggere i due sensori, basterebbe uno in alcune circostanze, es all’accenzione registra l’altezza da terra, dopo basta leggere un solo sensore perchè l’altro non può essere che l’opposto.

I primo disegno mostra la fase di accelerazione la freccia in altro indica il verso di marcia voluto, la freccia in basso indica le masse dinamiche (non le ho saputo chiamare diversamente) che si spostano in verso opposto all’accelerazione. Sono queste masse dinamiche che fanno abbattere il robo in senso opposto all’accelerazione.

Il secondo disegno mostra la fase opposta all’accelerazione e prevede che il robo abbia già guadagnato una certa velocità costante. Qui le masse dinamiche si spostano verso il senso di marcia, facendo abbattere il robo in avanti.

Per contrastare queste forze si potrebbero usare delle masse in movimento, es. in frenata la tendenza ad abbattere viene compensata da una massa che si sposta al posteriore del robo, permettendo una frenata più energica. In accelerazione la cosa contraria si sposta la massa all’anteriore e si fa in modo di tenere l’assetto di avanzamento. Sensa queste masse penso si possa provare a bilanciare il tutto con masse statiche concentrate tutte sotto l’asse delle ruote distribiute in modo uniforme e nella posizione simile ad i sensori S.

per esempio , per andare in avanti, bisognerà aggiungere (gradualmente) altezza al sensore frontale cosicchè il sistema pensi di star cadendo indietro e reagisca tentando di portarsi in posizione eretta (senza mai riuscirci) fino a che decidiamo di fermarci sottraendo (gradualmente) altezza al sensore frontale fino ad avere la lettura originale invariata.

Si ma bisognerebbe togliere altezza al sensore frontale ed aggiungerla al quello posteriore, così accelera per recuperare insomma il succo e quello ma invertendo i sensori.

Ciao.

robo-frenata.png

robo-accelerazione.png

Quindi la "massa dinamica" o quantità di moto sarà proporzionale all'accelerazione e di conseguenza il nostro valore di offset dovrà essere anche lui proporzionale a quella. quindi sia la partenza che l'arrivo dovranno essere fatte gradualmente per mitigare al massimo il problema, per quello nel mio post precedente parlavo di rampe.

la quantità di moto dipende dalla velocità, quindi solo indirettamente dall'accelerazione. http://it.wikipedia.org/wiki/Quantit%C3%A0_di_moto

la quantità di moto dipende dalla velocità, quindi solo indirettamente dall'accelerazione.

Nel link mi ha colpito questa affermazione.

L'importanza della quantità di moto è espressa dalla seconda legge della dinamica, la quale afferma che la forza applicata ad un punto materiale è pari alla rapidità con cui la quantità di moto del punto stesso varia nel tempo:

Io la traduco così, quelle forze (o masse dinamiche) sono massime quando avviene la partenza, e sono più alte tanto più rapida è la partenza. Dopo aver raggiunto una velocità costante quelle forze si distribuisco come se fossere statiche, mentre rimane la forza di avanzamento ma quella dipende dalla forma più o meno aereodinamica del oggetto, che nel caso del robo si tratta di una forza minima in quanto ci sono solo 4 sottilissimi montanti e una tettoia. Quando dico accelerazione mi riferisco al moto rettilineo accelerato, dopo raggiunta la velocita parliamo di moto rettilinero uniforme.

Quello che dico lo dico con convinzione, tuttavia non è una materia semplice e io non sono in grado dimostrare nulla con le formule ed è anche molto probabile che abbia detto qualche caz..ta.

Mettetevi in auto, date gas e fate una partenza spettacolare, in pratica tanto fumo e niente arrosto, far pattinare le ruote non serve a partire rapidamente. Ma perchè pattinano le ruote? Avviene un trasferimento di carico dall'avantreno al retrotreno, l'avantreno trovandosi più leggero ha le ruote che premono sull'asfalto molto meno di prima riducendo l'attrito. In frenate invece abbiamo un bel vantaggio in quanto il trasferimento di carico segue il verso opposto, quindi maggiore attrito dove serve, sempre che non freniate in curva perchè in tal caso il retrotreno essendo più leggero tende verso la tangente (insomma una sbandata). Qui so cosa dico e posso dimostrarvelo se vi fate un giro in auto con me.

Ciao.

allora, premetto che di fisica sono una capra, però

L'importanza della quantità di moto è espressa dalla seconda legge della dinamica, la quale afferma che la forza applicata ad un punto materiale è pari alla rapidità con cui la quantità di moto del punto stesso varia nel tempo:

vuol dire: la quantità di moto è importante perchè, secondo la seconda legge della dinamica, la forza applicata ad un corpo varia la sua quantità di moto.

Quello che dici infatti è errato, quello che tu stai sperimentando è la differenza tra sistema di riferimento "assoluto" (ovvero fermo rispetto all'esperimento) e sistema di riferimento "relativo" (ovvero in moto rispetto all'esperimento) (esempio: assoluto il traguardo per misurare la velocità della macchina, che però è relativo alla terra se tieni anche la rotazione dell'asse terrestre per calcolare la velocità della macchina)

Infatto la formula è Q = m*V ovvero quantità di moto = massa * velocità, quindi non è che se smetti di accelerare la quantità di moto diventa 0, ma rimane costante!

Quello che GBM può fare è: trovare la funzione di accelerazione, che permette di dire quanto tempo impieghi per passare da V0 a V1. A questo punto sai la quantità di moto attuale (conoscendo massa e velocità attuale), puoi ricavare quanto sarà a V1 e quanto tempo impieghi a contrastarla.

sinceramente non mi pare l'approccio migliore, partirei piuttosto dal http://it.wikipedia.org/wiki/Moto_circolare_uniforme per poi, una volta risolto, aggiungere il problema della massa.

Ciao ragazzi, grazie delle varie risposte e proposte. Ciao Lesto, non capisco come vorresti usare il moto circolare uniforme! Scusami ma non sono un matematico, ma con la costante di mezzo non vedo, come potrebbe tornarmi utile, dovrei mettere in relazione la velocità e la massa.

Sto facendo vari test per capire quali soluzioni sono fattibili quali no, ma soprattutto mi sono letto un po' i progetti di altri e le soluzioni scelte. Fondamentalmente la scelta di molti è di affiancare al PID (con un'addizione) un valore che sommato al PID crea un offset dell'angolo a cui tende l'algoritmo. Questo offset varia in rapporto a 3 dati fondamentali velocità, accelerazione (velocità attuale - velocità precedente) e (in alcuni progetti avanzati) spazio percorso.

poniamo che il robot stabile ha angolo 0, sdraiato indietro - 90, sdraiato in avanti 90 Fondamentalmente, quello che io vorrei fare è spiegare al robot che se vuole spostarsi in avanti partendo da angolo 0, dovrà iniziare a ricercare un dato angolo (esempio 10), questo angolo varia in rapporto alla velocità che il robot vuole raggiungere. Raggiunto l'angolo richiesto puo' iniziare ad accelerare e raggiungere un angolo negativo (esempio -10) che varia in rapporto alla sua velocità attuale. Per frenare il robot in questo caso diminuirà con un certo rapporto l'angolo negativo e la velocità fino a fermarsi.

Per fare cio' devo comprendere e scrivere in codice la relazione tra l'offset dell'angolo, la velocità che io determino leggendo il voltaggio ai poli del motore come nel tutorial sul robot cartesiano: http://www.gioblu.com/tutorials/robotica/217-robot-cartesiano-e-odometria-con-arduino

Il tutto si conclude in 3 fasi: 1 Fase statica orientata alla ricerca dell'angolo di partenza 2 Fase dinamica orientata alla ricerca della velocità richiesta 3 Fase dinamica di mantenimento del moto e della posizione raggiunta 3 Fare dinamica orientata alla ricerca della posizione statica

Se il robot è in fase 1: l'offset da 0 diventerà positivo e aumenterà in rapporto all'aumento della velocità da raggiungere Se il robot è in fase 2: l'offset positivo è stato raggiunto e il robot inizia ad accelerare, l'offset tenderà a un valore negativo in rapporto alla velocità richiesta Se il robot è in fase 3: l'offset è negativo e qui lavorerà quasi completamente il PID influenzato Se il robot è in fase 4: l'offset da negativo tenderà a 0 in rapporto alla diminuzione della velocità

Posizione attuale 0 velocità 0 velocità richiesta 10 = offset + 10 Posizione attuale 10 velocità 0 velocità richiesta 10 = offset 10 (il robot inizia a muoversi in avanti) Posizione attuale -10 velocità 10velocità richiesta 0 = riduco velocità riduco angolo convergendo a 0

se dovessi risolvere il problema dal punto di vista fisico, io per prima cosa lo risolverei con il moto circolare NON uniforme (strane redirezioni di wikipedia), per poi complicarmi piano piano la vita se le formule non dovessero bastare/avessi tempo da buttare.

sinceramente se già possiedi un PID usa quello, è nato apposta per evitarsi questi sbatti. probabilmente tu adesso in input al pid dai il tuo angolo e zero, e lui ti dice a quando far andare i motori giusto? bene, quando vuoi avanzare, anzichè zero devi dargli il valore di angolazione. Se per input dai l'angolo, allora anche al posto di 0 dai un angolo di inclinazione, se gli dai l'attuale distanza dal suolo (la differenza delle 2 letture dei sensori) allora darai un valore che inclini dei abbastanza ma non troppo nella direzione voluta etc etc..

Ciao Lesto, non capisco come vorresti usare il moto circolare uniforme! Scusami ma non sono un matematico, ma con la costante di mezzo non vedo, come potrebbe tornarmi utile, dovrei mettere in relazione la velocità e la massa.

Si io sono ancora più capra e ci sta che non lo capisco, al momento mica deve girare, quindi al massimo rettilineo uniforme. Niente lo riletto ma non ci ho capito meno di zero.

Raggiunto l'angolo richiesto puo' iniziare ad accelerare e raggiungere un angolo negativo (esempio -10) che varia in rapporto alla sua velocità attuale. Per frenare il robot in questo caso diminuirà con un certo rapporto l'angolo negativo e la velocità fino a fermarsi.

Cioè visto che sai che la frenata fa abbattere il robot di +90 preventivamente vuoi mantenere un angolo di inclinazione di -10 gradi. Se riesci a mantenere questo assetto poi in frenata non devi superare i 0 gradi o comunque non andare oltre durante i primi istanti della frenata, poi quando è quasi fermo dovrebbe entrare in azione quello che già funziona per mantenerlo in equilibrio.

A mi è venuta una fantastica idea, la base che slitta avanti e indietro rispetto all'asse motrice, risultante i motori girano e tu mantieni l'equilibrio solo spostando le masse. Niente non ci badare e che sono convinto che senza contrappesi se si riesce avrai una frenata luuuuuuuuuuuuuuuuuuuuuuuuunga. Tra l'altro se già potessi spostare le masse allanteriore secondo me già cammina, tanto per provare di fronte appicicaci un peso, no in alto, in basso.

Ciao.

MauroTec:

Ciao Lesto, non capisco come vorresti usare il moto circolare uniforme! Scusami ma non sono un matematico, ma con la costante di mezzo non vedo, come potrebbe tornarmi utile, dovrei mettere in relazione la velocità e la massa.

Si io sono ancora più capra e ci sta che non lo capisco, al momento mica deve girare, quindi al massimo rettilineo uniforme. Niente lo riletto ma non ci ho capito meno di zero.

lol :D guarda il robot di lato. Il pavimento inganna, e ti togle metà rotazione per ottenere un cerchio, ma si tratta comunque di moto circolare. Comunque le formule possono essere tranquillamente usate anche per girare, è tutta una questione di sistema di riferimento :)

Tra l'altro la formula ci dice che più peso (o meglio massa) hai, più sarà grande la tua quantità di moto, quindi più tempo o forza impiegherai per frenare (o meglio cambiare il tuo stato attuale, ovvero fermo/movimento, movimento rettilineo/movimento circolare, etc..)

lol smiley-grin guarda il robot di lato. Il pavimento inganna, e ti togle metà rotazione per ottenere un cerchio, ma si tratta comunque di moto circolare. Comunque le formule possono essere tranquillamente usate anche per girare, è tutta una questione di sistema di riferimento smiley

ahhhhhhhhhhhhhhhhh :D, certo tu intendevi la rotazione -90 0 +90, si ok. Pero quelle formule io non le so capire, o meglio per adesso ho altro su cui sbattere le testa e c'è la sto sbattendo tanto ma tanto, tanto io la testa dura c'è lò :P.

Tra l'altro la formula ci dice che più peso (o meglio massa) hai, più sarà grande la tua quantità di moto, quindi più tempo o forza impiegherai per frenare (o meglio cambiare il tuo stato attuale, ovvero fermo/movimento, movimento rettilineo/movimento circolare, etc..)

Allora si tratta di vedere le cose da un'altro punto di vista, il tuo non mi appare (a me) lampante e semplificato come il mio. Tu lo hai visto il video, secondo te se lo sbilancia con un peso sull'anteriore non potendo recuperare mai tenderà sempre ad accellerare fino a cadere sui -90 o no che dici?.

Ciao.

Hehehe ciao Mauro, anche io avevo pensato a muovere un peso fisicamente, ma alla fine sono giunto alla conclusione che gia possiamo farlo con i motori, forse è un aggiungere complessità e peso non strettamente necessaria, ma sicuramente interessante da sperimentare :grin:.

In questo video, a 3:22 trovate una rappresentazione grafica delle 4 fasi che vi ho descritto:

Sono d’accordo con Lesto per l’uso dell’offset, l’unica cosa è che questo offset varierà dinamicamente, devo scrivere la formula è li il problema :grin:

io direi di scomporre il problemone in due problemini per adesso, 1) calcolare l'offset da applicare 2) applicare l'offset calcolato e focalizzarsi sul primo. Come calcolare l'offset di partenza/regime/arresto? Cosa abbiamo a disposizione per calcolare l'offset? (formule, prove empiriche, altri esempi, ecc...) Quali variabili necessarie al calcolo dell'offset sono note o facilmente calcolabili? ecc..

BrainBooster: Come calcolare l'offset di partenza/regime/arresto? Cosa abbiamo a disposizione per calcolare l'offset?

Mi ricordo ancora qualcosa di fisica, voglio provare a dare il mio contributo.

L'unica formula è F=ma, ovvero la forza che viene impressa è proporzionale all'accelerazione, e sarà piccola quando non ci sarà da accelerare o da frenare, come avete detto. Lungo la direzione del movimento abbiamo che in ogni momento la forza di gravità è pari al seno delll'inclinazione per la massa e deve essere quella a causare l'accelerazione. Ovvero la formula per l'inclinazione dovrebbe essere arcoseno(a/g), con g = 9,8 m/s^2... Dato che si tratta di piccole inclinazioni e che l'offset è direttamente proporzionale, basta una formula approssimata, offset = k*a con k... da trovare provando :( ma almeno credo sia l'unica formula. Dovresti solo decidere come far variare l'accelerazione lungo il percorso, in modo da non avere inclinazioni eccessive e non troppi sbalzi all'inizio e alla fine dell'accelerazione. Insomma, qualcosa di graduale all'inizio e in fondo, quando si raggiunge la velocità voluta misurata con il metodo:

gbm: Per fare cio' devo comprendere e scrivere in codice la relazione tra l'offset dell'angolo, la velocità che io determino leggendo il voltaggio ai poli del motore come nel tutorial sul robot cartesiano: http://www.gioblu.com/tutorials/robotica/217-robot-cartesiano-e-odometria-con-arduino

Non ho ben capito come funziona :~ ma questa è un'altra storia, se dici che misura bene la velocità va benissimo. Ho una domanda, la misura della velocità (e quindi della distanza percorsa etc etc) che ottieni con questo metodo è affidabile anche durante l'accelerazione?