Difference between revisions of "Talk:LURCH - The autonomous wheelchair"
m |
|||
Line 1: | Line 1: | ||
− | '''****** IMPORTANT: THE INFORMATION | + | = 2013: relazioni tra lo stato del robot Lurch e quanto descritto nella documentazione = |
+ | Descrizione dello stato del robot rispetto a quanto descritto dalla documentazione disponibile | ||
+ | |||
+ | I documenti principali che descrivono la struttura del robot Lurch sono le tesi di laurea di Simone Ceriani e Marco Dalli. | ||
+ | Il robot si trova oggi (anno 2013) in uno stato simile, ma non identico, a quello descritto nella tesi di Laurea di Marco Dalli, che a sua volta fa riferimento a quella (precedente) di Simone Ceriani. Si noti che la tesi di Marco Dalli indica alcune modifiche (effettuate da Dalli durante il suo lavoro di tesi) rispetto a quanto descritto dalla tesi di Ceriani. | ||
+ | |||
+ | Le differenze tra lo stato attuale del robot e quanto descritto nelle suddette tesi di laurea sono sia di tipo software che hardware, e sono dovute in parte alla mancata piena applicazione a Lurch del lavoro di tesi di Marco Dalli, e in parte a modifiche successive effettuate da Simone Ceriani per vari motivi (principalmente per implementare funzionalità che via via si rendevano utili: per le prove a Sim-Patia, per le demo in fiera, ...). | ||
+ | |||
+ | Le differenze principali tra l'effettiva struttura di Lurch (quale è nel 2013) e quanto descritto nella tesi di Marco Dalli sono le seguenti. | ||
+ | |||
+ | |||
+ | ==1. Introduzione del pulsante di sicurezza ("fungo" e radiocomando)== | ||
+ | Il ricevitore radio e il pulsante a fungo fanno capo ad una scheda per la sicurezza, che a sua volta comunica con il PC. | ||
+ | La scheda è in grado di mettere Lurch "in protezione" (accensione del led rosso vicino al pulsante rosso e blocco del movimento del robot) simulando la situazione generata dal caricabatteria, in cui viene modificato il potenziale elettrico di uno dei tre piedini del connettore Cannon al quale si collega il caricabatteria. In tale condizione, il sistema Dynamic che governa la carrozzina entra in blocco e Lurch non è in grado di muoversi. In queste condizioni il display a 7 segmenti che indica la velocità sul joystick Dynamic mostra un segmento orizzontale (il segmento orizzontale centrale della cifra 8). Per permettere quanto sopra, la scheda per la gestione della sicurezza è connessa al controller Dynamic tramite il connettore Cannon, mentre il caricabatteria si connette al robot tramite il connettore Cannon montato sul lato del contenitore dell'elettronica aggiuntiva. | ||
+ | |||
+ | Rispetto allo stato del sistema di controllo del robot descritto da Dalli, è stato introdotto un modulo software aggiuntivo (emergency_batt_level) che si occupa di comunicare con la scheda per la sicurezza. Tale agente è inoltre in grado di leggere (sfruttando una funzionalità aggiuntiva della scheda) la tensione delle batterie della carrozzina. | ||
+ | |||
+ | E' stato verificato nella pratica che la condizione di blocco di emergenza di Lurch viene attivata via software se si verificano determinate condizioni di anomalia (pianificatore che non riesce a produrre un piano, sensori Hokuyo che non rispondono, ???). | ||
+ | |||
+ | |||
+ | ==2. Controllore PID realizzato via software che gira sul PC== | ||
+ | La tesi di Marco Dalli descrive la realizzazione di due schede: un sistema di odometria e un controllore PID ad esso collegato. Le due comunicano attraverso opportuni segnali elettrici. In questo schema, il controllore è un dispositivo hardware montato sulla carrozzina, che esegue i comandi del software che gira sul PC. Dunque (nella struttura descritta da Dalli) il software sul PC si limita a definire i setpoint per l'azione di controllo, che viene applicata dalla scheda. | ||
+ | In realtà le cose sono diverse. La scheda odometria installata su Lurch è quella descritta da Dalli (forse con qualche modifica), ma la scheda di controllo NON è mai stata installata sul robot. Tale scheda, chiamata Board2, è stata in effetti realizzata e testata da Marco Dalli (con l'aiuto di Simone Ceriani), ma non è mai effettivamente stata portata su Lurch. | ||
+ | |||
+ | Il sistema di controllo di Lurch è basato, invece, su un controllore PID realizzato tramite software che gira sul PC di bordo. Tale controllore, sviluppato da Simone Ceriani, si basa su un controllo PID in cui i valori delle costanti Kp (e forse anche Ki e Kd) variano nel tempo. [Ad esempio se l'utente esercita un'azione di comando molto intensa (e.g., joystick tutto indietro quando la carrozzina sta muovendosi velocemente in avanti) Kp viene fortemente aumentata; se le azioni di controllo sono modeste, Kp viene diminuita.] | ||
+ | Questo controllore software è realizzato tramite quella che di fatto (anche se in modo non dichiarato) è una seconda istanza di Brian. Tale seconda istanza (indipendente da quella che controlla il robot, e che non interagisce con essa), tramite opportune regole, calcola e genera i comandi da inviare alla scheda hardware che interagisce con il controller Dynamic simulando il movimento della leva del joystick. | ||
+ | |||
+ | Rispetto a quanto descritto da Dalli, la scheda odometria si limita ad acquisire i segnali elettrici dagli encoder, calcolare la cinematica della carrozzina e inviare (fin dall'accensione, costantemente, senza aspettare alcuno specifico comando) messaggi periodici che indicano la stima della pose della carrozzina. L'agente software che li riceve è il modulo odometry, che di fatto fa poco più che implementare il protocollo di comunicazione con la scheda odometrica. | ||
+ | |||
+ | |||
+ | ==3. Modifica del sistema di evitamento ostacoli== | ||
+ | Rispetto a quanto descritto nelle tesi di Ceriani e Dalli, l'evitamento ostacoli è stato completamente riprogettato da Simone Ceriani: sia per tenere conto dell'installazione dei sonar, sia per maggiore sicurezza in vista delle demo a Sim-Patia e in fiera. | ||
+ | |||
+ | Attualmente l'evitamento ostacoli si basa sull'identificazione di "zone" all'interno del campo di percezione dei sensori, e sulla generazione di messaggi che indicano quali di tali zone siano libere o occupate. Di fatto, tale informazione rappresenta una sorta di mappa locale della zona circostante il robot, sebbene non sia rappresentata come mappa e non sia gestita in modo centralizzato da un modulo apposito. Le informazioni sull'occupazione dello spazio intorno al robot sono poi sfruttate (credo) da Brian per determinare i comandi di movimento di Lurch. | ||
+ | |||
+ | I messaggi relativi alle zone occupate sono generati da un "obstacle manager" che riceve i messaggi sui punti percepiti dai sensori, generati dai moduli che gestiscono questi ultimi. La versione iniziale dell'evitamento ostacoli (descritta nelle tesi di Ceriani e Dalli) sfruttava direttamente questi ultimi messaggi, ma si era rivelata poco gestibile. | ||
+ | |||
+ | Si noti che, non esistendo una mappa locale, in Lurch l'evitamento ostacoli non prevede né l'uso di metodi geometrici né alcun tipo di pianificazione locale. Per questa ragione Simone Ceriani consiglia di non conservare tale sottosistema e passare invece ad un sistema software (e.g., il navigation stack di ROS) che preveda questi elementi e consenta perciò un controllo più preciso delle traiettorie seguite dal robot per evitare gli ostacoli. Questo renderebbe l'evitamento ostacoli più preciso e darebbe al robot una maggiore capacità di sfruttare correttamente eventuali passaggi angusti ma percorribili. | ||
+ | |||
+ | |||
+ | |||
+ | '''****** IMPORTANT: THE INFORMATION BELOW MAY BE OBSOLETE! ******''' | ||
=Planner= | =Planner= |
Revision as of 16:23, 10 September 2013
Contents
2013: relazioni tra lo stato del robot Lurch e quanto descritto nella documentazione
Descrizione dello stato del robot rispetto a quanto descritto dalla documentazione disponibile
I documenti principali che descrivono la struttura del robot Lurch sono le tesi di laurea di Simone Ceriani e Marco Dalli. Il robot si trova oggi (anno 2013) in uno stato simile, ma non identico, a quello descritto nella tesi di Laurea di Marco Dalli, che a sua volta fa riferimento a quella (precedente) di Simone Ceriani. Si noti che la tesi di Marco Dalli indica alcune modifiche (effettuate da Dalli durante il suo lavoro di tesi) rispetto a quanto descritto dalla tesi di Ceriani.
Le differenze tra lo stato attuale del robot e quanto descritto nelle suddette tesi di laurea sono sia di tipo software che hardware, e sono dovute in parte alla mancata piena applicazione a Lurch del lavoro di tesi di Marco Dalli, e in parte a modifiche successive effettuate da Simone Ceriani per vari motivi (principalmente per implementare funzionalità che via via si rendevano utili: per le prove a Sim-Patia, per le demo in fiera, ...).
Le differenze principali tra l'effettiva struttura di Lurch (quale è nel 2013) e quanto descritto nella tesi di Marco Dalli sono le seguenti.
1. Introduzione del pulsante di sicurezza ("fungo" e radiocomando)
Il ricevitore radio e il pulsante a fungo fanno capo ad una scheda per la sicurezza, che a sua volta comunica con il PC. La scheda è in grado di mettere Lurch "in protezione" (accensione del led rosso vicino al pulsante rosso e blocco del movimento del robot) simulando la situazione generata dal caricabatteria, in cui viene modificato il potenziale elettrico di uno dei tre piedini del connettore Cannon al quale si collega il caricabatteria. In tale condizione, il sistema Dynamic che governa la carrozzina entra in blocco e Lurch non è in grado di muoversi. In queste condizioni il display a 7 segmenti che indica la velocità sul joystick Dynamic mostra un segmento orizzontale (il segmento orizzontale centrale della cifra 8). Per permettere quanto sopra, la scheda per la gestione della sicurezza è connessa al controller Dynamic tramite il connettore Cannon, mentre il caricabatteria si connette al robot tramite il connettore Cannon montato sul lato del contenitore dell'elettronica aggiuntiva.
Rispetto allo stato del sistema di controllo del robot descritto da Dalli, è stato introdotto un modulo software aggiuntivo (emergency_batt_level) che si occupa di comunicare con la scheda per la sicurezza. Tale agente è inoltre in grado di leggere (sfruttando una funzionalità aggiuntiva della scheda) la tensione delle batterie della carrozzina.
E' stato verificato nella pratica che la condizione di blocco di emergenza di Lurch viene attivata via software se si verificano determinate condizioni di anomalia (pianificatore che non riesce a produrre un piano, sensori Hokuyo che non rispondono, ???).
2. Controllore PID realizzato via software che gira sul PC
La tesi di Marco Dalli descrive la realizzazione di due schede: un sistema di odometria e un controllore PID ad esso collegato. Le due comunicano attraverso opportuni segnali elettrici. In questo schema, il controllore è un dispositivo hardware montato sulla carrozzina, che esegue i comandi del software che gira sul PC. Dunque (nella struttura descritta da Dalli) il software sul PC si limita a definire i setpoint per l'azione di controllo, che viene applicata dalla scheda. In realtà le cose sono diverse. La scheda odometria installata su Lurch è quella descritta da Dalli (forse con qualche modifica), ma la scheda di controllo NON è mai stata installata sul robot. Tale scheda, chiamata Board2, è stata in effetti realizzata e testata da Marco Dalli (con l'aiuto di Simone Ceriani), ma non è mai effettivamente stata portata su Lurch.
Il sistema di controllo di Lurch è basato, invece, su un controllore PID realizzato tramite software che gira sul PC di bordo. Tale controllore, sviluppato da Simone Ceriani, si basa su un controllo PID in cui i valori delle costanti Kp (e forse anche Ki e Kd) variano nel tempo. [Ad esempio se l'utente esercita un'azione di comando molto intensa (e.g., joystick tutto indietro quando la carrozzina sta muovendosi velocemente in avanti) Kp viene fortemente aumentata; se le azioni di controllo sono modeste, Kp viene diminuita.] Questo controllore software è realizzato tramite quella che di fatto (anche se in modo non dichiarato) è una seconda istanza di Brian. Tale seconda istanza (indipendente da quella che controlla il robot, e che non interagisce con essa), tramite opportune regole, calcola e genera i comandi da inviare alla scheda hardware che interagisce con il controller Dynamic simulando il movimento della leva del joystick.
Rispetto a quanto descritto da Dalli, la scheda odometria si limita ad acquisire i segnali elettrici dagli encoder, calcolare la cinematica della carrozzina e inviare (fin dall'accensione, costantemente, senza aspettare alcuno specifico comando) messaggi periodici che indicano la stima della pose della carrozzina. L'agente software che li riceve è il modulo odometry, che di fatto fa poco più che implementare il protocollo di comunicazione con la scheda odometrica.
3. Modifica del sistema di evitamento ostacoli
Rispetto a quanto descritto nelle tesi di Ceriani e Dalli, l'evitamento ostacoli è stato completamente riprogettato da Simone Ceriani: sia per tenere conto dell'installazione dei sonar, sia per maggiore sicurezza in vista delle demo a Sim-Patia e in fiera.
Attualmente l'evitamento ostacoli si basa sull'identificazione di "zone" all'interno del campo di percezione dei sensori, e sulla generazione di messaggi che indicano quali di tali zone siano libere o occupate. Di fatto, tale informazione rappresenta una sorta di mappa locale della zona circostante il robot, sebbene non sia rappresentata come mappa e non sia gestita in modo centralizzato da un modulo apposito. Le informazioni sull'occupazione dello spazio intorno al robot sono poi sfruttate (credo) da Brian per determinare i comandi di movimento di Lurch.
I messaggi relativi alle zone occupate sono generati da un "obstacle manager" che riceve i messaggi sui punti percepiti dai sensori, generati dai moduli che gestiscono questi ultimi. La versione iniziale dell'evitamento ostacoli (descritta nelle tesi di Ceriani e Dalli) sfruttava direttamente questi ultimi messaggi, ma si era rivelata poco gestibile.
Si noti che, non esistendo una mappa locale, in Lurch l'evitamento ostacoli non prevede né l'uso di metodi geometrici né alcun tipo di pianificazione locale. Per questa ragione Simone Ceriani consiglia di non conservare tale sottosistema e passare invece ad un sistema software (e.g., il navigation stack di ROS) che preveda questi elementi e consenta perciò un controllo più preciso delle traiettorie seguite dal robot per evitare gli ostacoli. Questo renderebbe l'evitamento ostacoli più preciso e darebbe al robot una maggiore capacità di sfruttare correttamente eventuali passaggi angusti ma percorribili.
****** IMPORTANT: THE INFORMATION BELOW MAY BE OBSOLETE! ******
Planner
MSL library soruce + PQP source: Media:MSL.zip compiled on Ubuntu 8.10 with gcc 4.3.2
Software Installation [TODO: complete]
This is obsolete for certain. Ask Giulio Fontana for an up-to-date installation guide
This guide is tested on Ubuntu 8.10, 9.04 and Xubuntu 8.10. GCC version in 4.3.
- Install the following packages:
- qt3-dev-tools
- qt4-dev-tools
- build-essential
- flex
- bison
- libjsw-dev
- libboost-dev
- libdc1394-13-dev
- libgsl0-dev
- libgtk2.0-dev
- libncurses5-dev
If you want you can cut and paste this command line: sudo apt-get install ...
- Download this file: [TODO], which contains ARToolKitPlus Libraries
- unpack it in /opt folder
- go into /opt/ARToolKitPlus_2.1.1
- export ARTKP=/opt/ARToolKitPlus_2.1.1
- qmake
- make
- sudo make install
- download lurch-control.tar.gz
- extract it in your home folder
- make cleanall
- make ROBOT=wheelchair MODULE=misc
- make ROBOT=wheelchair MODULE=fuzzy
- make ROBOT=wheelchair
- cd wheelchair
- ln -s ../logExtract.sh ./
- ln -s ../run.sh ./
- [usually not necessary; see NOTA below] download lurch-wheelchair-standalone.tar.gz
- extract it in your home folder
- go into lurch-wheelchair-standalone/config
- edit config.ini
- replace line with hostname=airlab-blackbox with hostname=<yourhostname>
- edit agent.ini
- find and replace all "airlab-blackbox" with <yourhostname>
- [NOTA a proposito di lurch-wheelchair-standalone. Simone Ceriani: "Riguarda una particolare configurazione (ovvero file di config diversi, ma stesso identico sw) che usavo per fare girare il sw di lurch su un pc qualunque e simulare il robot con un simulatore java (Simbad) che avevo reso compatibile con lurch. In pratica lui apriva n server TCP/IP, uno per ogni "sensore" di lurch e permetteva di simulare il funzionamento per provare le funzionalità, come evitamento ostacoli, nav autonoma, guida ecc ecc. Del tutto obsoleta non è, ma non so più a che punto è rimasta e se è tuttora funzionante... di sicuro per un po' era usabile!]
- download the server for simulation (you need sun-java6-jdk installed and Eclipse is suggested)
...
- from lurch-wheelchair-standalone
- sudo ./run.sh
Timeline
Breve riassunto dello stato attuale di Lurch, e delle ultime modifiche:
2012/07/10: - corretto un errore in una shape fuzzy (qualità della speed) e allo stesso tempo aumentato la soglia entro la quale la quality speed è definita "good" e "very good", allontanando la "medium" e "bad" - cambiato una soglia sulla distanza minima letta dai sonar: i sonar hanno come valore nominale minimo 142mm, però due di essi (quelli a sinistra) con il sole (vai a capire perchè ma la causa sembra quella) leggono sempre 142... abbiamo impostato nel "sonarExpert" di scartare valori inferiori (o <=, non sono sicuro) a 0.143 metri.... barbatrucco un po' rischioso, ma efficace - cambiata la soglia di raggiungimento via point e passaggio al successivo da 0.4m a 0.5m, per rendere più fluido il movimento
la storia precedente... lo sviluppo sw di lurch è fermo a settembre 2009 [demo e prove a Simpatia - agosto/settembre 2009] con pochissime revisioni per Robotica 2009 a novembre dal punto di vista hw nel 2010 è stato fatto da Giulio e Davide quello che chiamiamo "restyling", in quanto non è cambiato nulla dal punto di vista funzionale (stessi sensori, stesso hw per tutto, solo posizionato diversamente) a valle del quale il sw è stato riadattato, ma le modifiche sw sono state proprio poche, soprattutto sono state configurazione delle nuove posizioni dei sensori. Le cose che vedo più sostanziali relative a ciò sono state: - passagggio da due pcbrick (di cui uno con cpu via - i pc brick originali - e uno con dual core - il cosidetto pcbriccone - su cui erano distribuiti gli agenti running) ad un solo (il pcbriccone). Da quel momento non sono più stati aggiornati i driver del touch screen (che tuttora non è funzionante) e il sw gira tutto su un pc solo, mentre prima era distribuito - è stata sostituita la camera firewire (fire i 400) con una ethernet (prosilica) e di conseguenza aggiunto un pezzo sw per leggere dalle api prosilica e non da firewire
Available Documentation
- Documentation on the interface circuit between the wheelchair joystick and computer: Media:LurchCircuitDocument.pdf.
- WARNING: the circuit was modified and the documentation above is upgraded by this new file: Media:LurchXBee.pdf.
- How to modify the wheelchair joystick to connect to the interface circuit: Media:LurchCircuitJoystick.pdf.
- Brief discussion about the interface circuit between the wheelchair joystick and computer: Media:LurchCircuitJoystickBrief.pdf.
- Brief description of the LURCH project: Media:LurchBriefDesc.pdf.
- Brief description of the communication between the wheelchair interface circuit and a PC via RS232 port: Media:LurchProtocol.pdf.
- Source code for PIC 18F452 microprocessor and Eagle project (schematic and board): Media:LurchCircuitProject.zip.
- Battery replacement done on May 2009, description of work: Media:LurchBatteryReplacement.pdf.
- Thesis by Simone Ceriani, titled Sviluppo di una carrozzina autonoma d'ausilio ai disabili motori (Development of an autonomous wheelchair to help motor-disabled persons): Media:LurchThesisCeriani.pdf (in Italian)
- Thesis presentation by Simone Ceriani (note: Videos don't work, you can found similar videos below): Media:LurchPresentazioneThesisCeriani.zip
- Thesis by Marco Dalli, titled Sviluppo di un sistema di controllo basato su odometria per una carrozzina robotica (Development of a control system based on odometry for a robotic wheelchair): Media:LurchThesisDalli.pdf (in Italian)
- Thesis presentation by Marco Dalli: Media:LurchPresentazioneThesisDalli.zip
- Thesis by Marco Assini, titled Sviluppo di un pianificatore di percorsi geometrici per una carrozzina autonoma (Development of a geometric path planner for an autonomous wheelchair): Media:LurchThesisAssini.pdf (in Italian)
- Thesis presentation by Marco Assini (the file contains a ppt version, a pptx, and a simplified pdf version without animation): Media:LurchPresentazioneThesisAssini.zip
- Thesis by Mauro Brenna, titled Scan Matching, Covariance Estimation and SLAM: Models and Solution for the scanSLAM Algorithm: Media:MauroBrennaMastersThesis2010.pdf (in English)
- Pdf with ArtoolKitPlus Fiducial Markers collection. Dimension are 160x160mm. Media:ArtoolKitPlusMarkers-160mm.pdf.zip
PCBricks Configuration
PCBrick-03 and PCBrick-05 feature Xubuntu Linux 7.10, Xfce Window Manager, Openchrome graphics drivers and eGalax touchscreen drivers v1.08.1227 (Drivers here). The touchscreen is configured and calibrated on both machines, hence it can be used with either one or the other indifferently.
Electronics development
We are currently designing a new electronic main board for the wheelchair.
The idea is to base the whole system on a CANbus, allowing a complete modularization of the on-board electronics.
Read more on this topics here...
Software development
- Try a different sw architecture, now we are examinating orocos [1]
- Integrate Marco Assini's thesis (RRT planning) with current release
- Develop an improved navigation system Read more on this topics here...
People Involved
Marco Dalli (ex-Tesista)
Simone Ceriani (Dottorando)
Matteo Rossi (ex- Tesista)
Marco Assini (ex-Tesista)
Mauro Brenna (Tesista)
Diego Consolaro (ex-Tesista)