The RoboCare Project: Intelligent Systems for Elder Care
Anuska Benacchio Giuseppe Cassano Mirco Furlan
Tesina per il corso di Intelligenza Artificiale, Prof.ssa Silvana Badaloni
Università degli Studi di Padova, Facoltà di Ingegneria
12 Gennaio 2010
1 Introduzione
Planning e scheduling [1] è l’area dell’intelligenza arti-
ficiale che riguarda lo studio di modelli e tecniche per
la sintesi ed il mantenimento di piani di azione, strate-
gie di esecuzione e politiche di allocazione delle risorse
che permettono la realizzazione di compiti (task) com-
plessi. Oltre all’intelligenza artificiale, P&S è anche
oggetto di studio di altre materie quali la ricerca op-
erativa ed il management ed è impiegato in tantissime
realtà diverse (pubblica amministrazione, industria,
assistenza agli anziani, missioni spaziali, ect).
Il planning è il processo di sintesi di sequenze di
azioni o attività che permettono di raggiungere un
desiderato stato obiettivo (goal ) a partire da uno stato
iniziale. Sin dalle origini, al planning automatizzato
è stata data una caratterizzazione logica consistente
nel punto di vista di un agente centrale che esegue
azioni che modificano il mondo circostante, permet-
tendo di giungere ad una desiderata situazione (goal ).
In maniera formale, un problema di planning consiste
nel cercare una sequenza di azioni o istanze di op-
eratori che trasformano uno stato iniziale nello stato
obiettivo. Esso è definito da una quaterna del tipo
(A, I, O, G) dove:
ˆ A è l’insieme delle proposizioni usate per carat-
terizzare gli stati e a ciascuno di essi è assegnato
un valore di verità (true o f alse);
ˆ I e G rappresentano rispettivamente lo stato
iniziale e quello finale;
ˆ O è un insieme di funzioni che permettono di
ottenere uno stato a partire da un altro.
Lo scheduling, invece, si focalizza sul processo di
allocazione di risorse ed attività nel tempo, nel rispet-
to di vari tipi di vincoli, quali ad esempio capacità,
precedenza e durata. L’attività dello scheduling con-
siste nel determinare quando un insieme di task deve
essere eseguito in modo che la soluzione finale garan-
tisca buone prestazioni relazionate all’ottimizzazione
di una funzione obiettivo. Formalmente, un problema
di scheduling è un elemento rappresentato attraverso
una tupla del tipo < T, P, R, C, U > [8] dove:
ˆ T ⊆ T ASKS è un insieme di task e ogni task è
caratterizzato da un tempo di inizio e di fine;
1
Francesco Locascio Nicolò Paganin
ˆ P ⊆ P RECS rappresenta un insieme di vincoli
temporali che i task devono rispettare;
ˆ R ⊆ RES è un insieme di risorse rinnovabili;
ˆ C : R → <+ (insieme dei reali positivi) è una fun-
zione che determina la disponibilità di ciascuna
risorsa;
ˆ U : T × R → <+ ∪ {0} è una funzione che indica
la quantità di una determinata risorsa R di cui
necessita un determinato task T .
Sebbene il planning e lo scheduling all’inizio fos-
sero due discipline diverse, oggi la ricerca in questi
settori si è fusa in un unico campo di studi. Ciò è
avvenuto perché è diventata sempre meno consistente
la soglia di differenza tra sintetizzazione di un piano
per raggiungere un obiettivo (planning) e il modo in
cui allocare le risorse per questo piano (scheduling).
La ricerca descritta qui di seguito deriva da un pro-
getto di tre anni chiamato ROBOCARE: “Un sistema
multiagente dotato di componenti robotiche mobili,
intelligente ed in grado di interagire con l’uomo”. La
motivazione per la quale questo ed altri lavori simili
sono stati sviluppati in tutto il mondo è il fenomeno
dell’invecchiamento demografico, una tendenza che si
integra bene con il desiderio delle persone di essere in-
dipendenti il più a lungo possibile. Questi fattori moti-
vano la ricerca tecnologica a creare strumenti per l’as-
sistenza dell’uomo. Le sfide derivanti da questo cam-
po hanno portato allo sviluppo di un’emergente area
dell’intelligenza artificiale chiamata Eldercare, che ha
come obiettivo lo sviluppo di attività e l’erogazione di
servizi che rispondono alle esigenze e necessità tipiche
delle persone anziane, dei malati cronici e dei disabili.
ROBOCARE si è specificatamente focalizzato sullo
sviluppo di una tecnologia basata sull’AI, per fornire
i servizi di assistenza domestica. Il risultato della
ricerca è un prototipo di casa intelligente (the ROBO-
CARE domestic environment, RDE), nel quale robot,
sensori ed altri agenti intelligenti operano coordinata-
mente per fornire supporto alle attività quotidiane di
una persona anziana. Più precisamente, il prototipo di
casa intelligente ROBOCARE comprende un singolo
robot ed una stereo-camera. Queste componenti sono
integrate con un sistema di monitoraggio delle attiv-
ità, il cui obiettivo è quello di reagire a comportamenti

inaspettati delle persone assistite. Lo scopo generale
dell’ambiente è di osservare le azioni della persona
assistita e mantenere un’aggiornata rappresentazione
dello stato dell’ambiente e della persona. Basandosi
su queste osservazioni, occorre valutare se le attività
della persona rientrano all’interno di un insieme pre-
definito di modelli comportamentali. Questi modelli
sono rappresentati nella forma di piani flessibili (flex-
ibile schedules) definiti da un caregiver e sono schedu-
lati/eseguiti per mezzo delle tecnologie di scheduling
allo stato dell’arte. Esempi di tali piani sono gli at-
ti linguistici attraverso i quali il sistema avverte una
persona delle incongruenze che possono sorgere come
conseguenza delle sue azioni. L’obiettivo principale
di tutto l’ambiente è quello di assicurare, attraver-
so attività di monitoraggio quotidiano, l’aderenza dei
comportamenti della persona assistita a dei modelli
comportamentali prestabiliti per vivere bene.
Il risultato di tutto il lavoro è un prototipo di am-
biente intelligente che integra robotica e componenti
software per ottenere un monitoraggio proattivo. Rias-
sumendo il tutto, si può dire che gli obiettivi di fondo
sono:
1. mantenere un comportamento continuo, in modo
tale da garantire un monitoraggio continuo di ciò
che avviene (lo stato degli anziani assistiti ed il
loro contesto domestico);
2. creare delle conoscenze circa le azioni che
l’anziano assistito esegue (routine, eccezional-
mente, ecc);
3. fornire servizi di interazione contestualizzata
con l’obiettivo di garantire assistenza proattiva
all’anziano.
Come già detto precedentemente, il progetto Robo-
Care mira ad usare le tecniche dell’AI per migliorare la
qualità della vita di tutti i giorni delle persone anziane.
Un uso similare di tecnologie intelligenti è descritto in
una catena di indagini indirizzate in altri campi di
ricerca. Tra quelle che anticipano e influenzano Robo-
Care, vale la pena ricordarne alcune. PEAT è uno
strumento basato sulle tecnologie AI che vuole miglio-
rare l’indipendenza delle persone affette da lesioni in-
tracraniche. Esso è un calendario elettronico ed anche
rubrica che usa il planning automatizzato per generare
i piani per le attività della vita quotidiana. PEARL è
un assistente mobile robotico, sviluppato per assistere
gli individui anziani con lievi deficit fisici e cognitivi,
nonché per supportare gli infermieri nelle loro attiv-
ità quotidiane. Tre moduli principali costituiscono le
componenti base per fornire l’interazione uomo-robot:
un sistema di memoria automatizzato; un sistema di
monitoraggio e rilevazione delle persone; e un robot
controller di alto livello. I.L.S.A è un sistema di sup-
porto che incorpora modulo di rilevamento, capacità
di rilevamento della situazione e pianificazione della
risposta per aiutare le persone anziane a vivere au-
tonomamente nella propria casa. Esso fornisce un’in-
terfaccia web che permette agli utenti di visualizzare i
2
The RDE Project
promemoria rilasciati per la giornata, di controllare gli
orari e lo stato dei farmaci (preso/non preso), lo stato
di mobilità degli utenti ed eventuali allarmi. Un altro
interessante uso delle tecniche dell’AI per assistere le
persone nella vita quotidiana è COACH, un’ortosi cog-
nitiva progettata per assistere le persone con un grado
di demenza tra grave e moderata, mentre si lavano le
mani. Il sistema è composto da una videocamera e da
un software che segue la posizione delle mani dell’u-
tente, determinando la sequenza di passi che l’utente
sta completando e generando un richiamo verbale in
caso di necessità. Esperimenti con potenziali soggetti
mostrano un significante aumento del numero di passi
nel lavaggio delle mani che un soggetto è in grado di
completare senza l’assistenza di un caregiver.
2 Schema generale RDE (Robo-
care Domestic Enviroment)
In figura è rappresentato uno schema degli elementi
di RDE [2][3]. Il contesto principale è un apparta-
mento di tre stanze di una persona anziana. Il RDE
è equipaggiato con i seguenti agenti, che forniscono
servizi di varia natura:
ˆ Un robot di servizio domestico, dotato di
laser basato su algoritmi di scansione per l’auto-
localizzazione robusta, per la pianificazione dei
percorsi e gli algoritmi per evitare gli ostacoli;
ˆ Un Interaction Manager, che coordina la sin-
tesi degli atti linguistici e fornisce la capacità di
rispondere a semplici domande fatte dall’utente,
quindi fornire un’ interfaccia utente intuitiva
da/per il robot;
ˆ Due telecamere stereo fisse che forniscono
un servizio di People Localization and Tracking
(PLT) [9], e un servizio di Posture Recognition
(PR) [10];
ˆ Un ADL (Activities of Daily Living) monitor,
un sistema di monitoraggio delle schedulazioni
che è responsabile per il monitoraggio delle attiv-
ità giornaliere della persona assistita e di valutare
l’aderenza ai vincoli comportamentali definiti dal
caregiver;
ˆ Un personal data assistant (PDA) in cui è pre-
sente una interfaccia molto semplice, formata da
quattro bottoni, che permette di (1) convocare il
robot, (2) inviare il robot a una posizione speci-
fica, (3) trasmettere streaming video dal robot al
PDA, e (4) fermare il robot.
3 MONITORAGGIO ATTIVITÀ E GENERAZIONE DELLE INTERAZIONI
2.1 Interaction Manager
È stata accoppiata con la piattaforma robotica una
sottocomponente separata con la capacità di inter-
azione verbale, che si occupa di controllare e integrare
i servizi esportati dai seguenti sottosistemi:
ˆ una “testa parlante” , Speech Synthesis Mod-
ule, chiamata Lucia, sviluppata presso l’istituto
di tecnologie e scienze cognitive di Padova. E’
una piattaforma software, dotata di funzionalità
di parola basate sull’elaborazione di specifici file
in formato testo.
ˆ un sistema di riconoscimento vocale, Speech
Recognition Module, chiamato Sonic, svilup-
pato presso l’Università del Colorado. Le pa-
role e/o frasi riconosciute sono successivamente
restituite in formato testo, l’IM è incaricato
di interpretare le stringhe restituite e aggiustare
le variabili ambientali coinvolte in conformità ai
messaggi ricevuti.
2.2 Daily Activity Monitor
Tornando alla spiegazione della fig. precedente, un
ruolo importante è giocato dal modulo per il monitor-
aggio dell’attività quotidiane. In linea generale, l’idea
è quella di tenere traccia di una serie di raccoman-
dazioni prescritte dal caregiver per una “vita sana”
sotto forma di comportamenti che l’anziano dovrebbe
seguire in un periodo di tempo. Tali vincoli compor-
tamentali vengono specificati attraverso un linguag-
gio a vincoli temporali, messo a disposizione dall’ ar-
chitettura di scheduling O-Oscar [6], inteso a facilitare
gli utilizzatori in generale. I comportamenti di “vita
sana” sono ricette come “prendere la medicina solo
dopo mangiato” o “L’ora per il pranzo è tra 12:00-
2:00”, ecc. L’insieme delle “specifiche di comporta-
mento sicuro” è rappresentato, in O-Oscar, come un
programma parzialmente ordinato di attività, costru-
ito come un problema temporale semplice (STP - Sim-
ple Temporal Problem - Dechter et al. (1991)).
L’ultimo collegamento tra l’ambiente fisico e le rac-
comandazioni è il modulo finale della figura, chiama-
to schedule execution. Questo è un modulo software
che simula principalmente l’esecuzione del programma
raccomandato e combina tale esecuzione con l’osser-
vazione dei sensori nell’ambiente reale. Dall’analisi
dei dati dei sensori è possibile discriminare tra i com-
portamenti degli utenti nominali e quelli anomali. Le
anomalie possono essere disfunzioni gravi (per es. l’u-
tente non risponde all’ interazione per troppo tempo)
che portano direttamente ad allarmi verso il mondo es-
terno,oppure meno critiche (per es. prendere medicine
in ritardo) che porta ad un’interazione verbale robot-
utente che intende sottolineare la violazione della re-
gola e il suggerimento di una linea di comportamenti
corretta.
3
The RDE Project
3 Monitoraggio Attività e Gen-
erazione delle Interazioni
Le informazioni provenienti dai sensori ambientali
sono date come input per l’Activity Monitor, che è
incaricato di seguire l’andamento reale del compor-
tamento della persona assistita e di confrontarlo con
le raccomandazioni del caregiver. Due tipi di infor-
mazione sono fondamentali per orientare l’interazione
mixed-initiative (Allen et al., 1999): (a) qualsiasi vi-
olazione di vincoli rappresenta un’occasione per il sis-
tema di intervenire; (b) l’interpretazione semantica dei
vincoli violati determina il contenuto della verbaliz-
zazione. A tal fine l’Interaction Manager esegue un
processo di ragionamento sui vincoli violati e sintetiz-
za una verbalizzazione contestualizzata che è presen-
tata all’utente sotto forma di avvertimenti, consigli o
allarmi.
L’interazione è stabilita in due differenti direzioni, in
base a chi prende l’iniziativa di iniziare un dialogo:
ˆ Iniziativa dell’utente. Classifichiamo come in-
iziativa dell’utente la categoria di dialoghi “do-
manda/risposta”. Questa attività ha inizio da
un input vocale da parte della persona assisti-
ta. La produzione della risposta è gestita inter-
namente prevalentemente dal gestore che ha in-
formazioni sulla cronologia delle attività e/o sul-
lo stato attuale dell’ambiente, per rispondere a
domande del tipo “ho pranzato?” , “Che ora
è?”. In questo modo l’assistito riceve un sostegno
per la propria pianificazione delle attività gior-
naliere o per questioni specifiche connesse allo
stato dell’ambiente.
ˆ Iniziativa del sistema. In questo caso è l’am-
biente intelligente che inizia l’interazione guida-
to dal suo ragionamento interno. Istanze delle
iniziative del sistema sono scenari “Danger” e
“Warning”. L’attivazione del pericolo è affronta-
to da uno specifico comportamento del sistema
multi-agente che interrompe il flusso abituale di
attività e si impegna in un’azione: il robot viene
inviato alla persona assistita, inizia un dialogo
specifico, e in assenza di risposta dell’assistito,
darà immediatamente un allarme verso il mondo
esterno (chiamata ad un parente,ecc.). Uno sce-
nario di avvertimento è quello in cui le violazioni
dei vincoli vengono rilevate dall’Activity Moni-
tor che decide i valori per i parametri utilizzati
dall’ Interaction Manager al fine di attivare un
dialogo, sintetizzato sulla base della conoscenza
interna del monitor, con la persona assistita.

3.1 Generazione di interazioni a par-
tire dalla conoscenza dello schedul-
ing
Al fine di fornire servizi affidabili, il RDE deve
mantenere un modello interno dell’ambiente che
viene monitorato (world database), i cui aspetti
più significativi devono essere tenuti costantemente
aggiornati e coerenti con i dati ambientali ricevuti
dai sensori. La precisione di allineamento tra il
mondo reale e il modello è essenziale per garantire la
precisione necessaria del compito di controllo.
Modellazione dei tipi di comportamento desiderato. I
vincoli comportamentali da monitorare, imposti dal
caregiver, sono facilmente espressi come attività in
un calendario che sono legate l’una all’altra attraverso
una serie di relazioni temporali. Qualora il piano
iniziale preparato dal caregiver contenga incongruenze
temporali, il sistema è progettato per evidenziarle in
modo da essere corrette; nessun piano inconsistente è
mai avviato per il controllo dell’esecuzione.
Un esempio di programma è rappresentato nella
figura soprastante. La figura mostra tre attività che
sono temporalmente legate l’una all’altra attraverso
una serie di vincoli (le frecce nere), i cui valori sono
espressi per mezzo di intervalli [dmin, dmax] che
determinano la distanza minima e massima tra le
attività coinvolte in ogni vincolo. Questo paradigma
di rappresentazione permette di gestire facilmente
il modello e la flessibilità temporale attraverso la
gestione di vincoli in termini di finestra temporale
piuttosto che imporre valori rigidi per gli istanti di
tempo. Un requisito importante per la rappresen-
tazione dello scheduling nominale è quello di evitare
di vincolare la persona assistita (e il caregiver!)
con eccessiva rigidità. La capacità di esprimere tali
concetti è essenziale quando si tratta di modelli di
comportamento umano, in quanto consente di definire
i limiti per la durata di attività e di collocamento
nel tempo che siano sufficientemente flessibili per
accogliere una forte variabilità.
Una volta che i vincoli comportamentali sono spec-
ificati dal caregiver in termini di un insieme coerente
di azioni,viene avviato il monitoraggio del comporta-
mento della persona assistita nell’ ambiente. Quando
il monitoraggio delle attività inizia, i sensori vengono
periodicamente interrogati e il programma nominale è
regolato in conformità con il comportamento rilevato
del paziente. Ad ogni ciclo di rilevamento, viene
verificato lo stato di esecuzione di ogni attività: tra i
casi possibili, alcune attività possono essere segnalate
come in esecuzione prima del loro orario di inizio
nominale, l’esecuzione di altre attività può essere
4
The RDE Project
segnalato come in ritardo, la durata di alcune attività
può superare il valore nominale, e cosı̀ via; ogni
deviazione dal piano nominale è un evento che può
comportare un conflitto che deve essere soddisfatto.
La capacità di aggiungere e ritrattare vincoli tem-
porali da/per il piano in corso permette di mantenere
costantemente solo le informazioni originali che sono
coerenti con lo stato del mondo attuale, senza tener
conto delle informazioni temporali che confliggono con
la situazione ambientale rilevata (che viene sfruttata
per far scattare gli avvisi e gli allarmi). Il fatto che
il contenuto informativo inizialmente fornito dal care-
giver è mantenuto al massimo nel piano con il passare
del tempo, viene utilizzato per fornire alla persona as-
sistita un servizio affidabile e un servizio di monitor-
aggio di alta qualità, anche in termini di spiegazioni
date.
4 DCOP per Smart Homes
In questo paragrafo discuteremo di una soluzione al
problema del coordinamento fra servizi, definito in
termini di distributed constraint reasoning.
Per il caso in esame, il coordination framework è
basato sull’algoritmo Adopt-N (descritto successiva-
mente) utilizzato per risolvere Distributed Constraint
Optimization Problems (DCOP ) [4].
4.1 Multi-Agent Coordination nella
Smart Home
Come già descritto precedentemente, le componenti
principali di un “sistema intelligente” sono: sensori,
conversational assistants, dispositivi per il monitorag-
gio della salute, eccetera. L’insieme di queste compo-
nenti fornisce non solo i servizi necessari per l’osser-
vazione dell’ambiente e dell’assistito, ma anche tutte
le funzionalità necessarie per la partecipazione proatti-
va nella vita quotidiana. In generale, e per i propositi
di questa trattazione, definiremo queste componenti
come applicazioni che offrono servizi.
Una delle difficoltà maggiori, che si incontrano
quando diversi servizi vengono integrati, riguarda il
problema del coordinamento. In un sistema come
quello in esame, servizi multipli possono essere at-
tivati concorrentemente e la combinazione di questi
può risultare piuttosto complessa e apparentemente
ingestibile.
Ogni servizio corrisponde ad un embebbed agent, i
cui task sono dinamicamente allocati in funzione dello
stato corrente dell’ambiente e della persona assistita;
a questo punto, il servizio di coordinamento può essere
ridotto ad un Multi-Agent Coordination (MAC).
Lo schema generale dell’approccio MAC-based è
rappresentato in figura:
4 DCOP PER SMART HOMES
dove le applicazioni nell’ambiente fisico (parte [a]
della figura) sono avvolte dagli agenti software, la
cui partecipazione nell’infrastruttura di coordinamen-
to distribuita (parte [b]) definisce il modo in cui
vengono invocati i servizi.
Nel caso in esame, come già accennato, il coordina-
mento dei servizi è compiuto mediante la riduzione del
problema MAC ad un DCOP, estensione del classico
constraint reasoning problem. Quest’ultimo, come no-
to, è definito da una tupla < V, D, C > dove vi ∈ V è
una variabile che può essere scelta nel dominio Di ∈ D
e C è un insieme di vincoli.
Nei CSP (Constraint Satisfaction Problem), un vin-
colo su un sottoinsieme di variabili {vi ...vj } ⊆ V è una
funzione fvi ...vj : Di × ... × Dj → {true, f alse} espri-
mendo il concetto che certi assegnamenti di variabili
possano essere ammissibili o meno. Per quanto riguar-
da invece COP (Constraint Optimization Problem), i
vincoli sono espressi mediante una funzione
fvi ...vj : Di × ... × Dj → N esprimendo il fat-
to che un determinato assegnamento di valori per
le variabili produce un intero (il costo dell’assegna-
mento); la problematica dei COP riguarda quindi la
ricerca della soluzione ottima (che minimizza il costo
dell’assegnamento).
Ricerche sui sistemi distribuiti hanno portato alla
definizione di una nuova branca di constraint reason-
ing conosciuta come Distributed Constraint Reason-
ing (DCR); quest’ultima focalizza la propria atten-
zione su algoritmi per la risoluzione di Distributed
CSP e COP (DCSP/DCOP). Per queste categorie di
problemi definiamo le caratteristiche generali: le vari-
abili sono controllate fisicamente da agenti e i vincoli
sulle variabili diventano vincoli sugli agenti; inoltre,
la conoscenza è distribuita, ma gli agenti conoscono
solo i vincoli sulle variabili associate. La presenza di
vincoli inter-agenti comporta la necessità di comuni-
cazione per l’inoltro delle loro decisioni ad altri agen-
ti con cui condividono un vincolo, e per l’accordo su
assegnamenti che soddisfano (in DCSP) o minimiz-
zano il costo (in DCOP) dei vincoli di cui non sono a
conoscenza. Per la natura distribuita del sistema, gli
5
The RDE Project
algoritmi di risoluzione DCSP/DCOP (vedasi Adopt
nel paragrafo successivo) devono occuparsi anche del-
la minimizzazione degli scambi di messaggi fra agenti
(che è esponenziale nel caso peggiore).
L’approccio adottato nel nostro caso, per la
risoluzione del coordinamento multi-agente è basato
sull’algoritmo (ottimo e asincrono) Adopt-N per l’ot-
timizzazione di problemi distribuiti. La parte (b) del-
la figura precedente mostra una descrizione ad alto
livello della problematica DCOP: ogni applicazione è
controllata da un agente sw che partecipa al decision
making distribuito attraverso una serie di variabili vin-
colate (caratterizzanti, appunto, un DCOP). Chiami-
amo Api il generico sottosistema intelligente integrato
nella smart home. Ogni applicazione Api fornisce un
servizio Si . Entrando nei dettagli del sistema, ogni
applicazione gestisce una o più variabili attraverso un
agente che ne costituisce l’interfaccia con il meccanis-
mo di coordinamento sottostante. Per esempio, l’ap-
plicazione che provvede al servizio di localizzazione
può scrivere attraverso il suo agente la variabile che
rappresenta la posizione corrente dell’assistito e questa
potrà essere letta da tutte le applicazioni che provve-
dono a servizi richiedenti la posizione corrente del
soggetto assistito. In generale, alcune variabili che
rappresentano l’input di una data applicazione pos-
sono essere l’output di altre. Le relazioni funzionali
tra i servizi sono modellate come vincoli tra variabili.
Nel complesso, la rappresentazione constraint-based
fra variabili codifica il comportamento desiderato del
sistema. Quando Adopt-N è in funzione, gli agenti
cooperativamente convergono sull’assegnamento delle
variabili che rappresenta un possibile comportamen-
to del sistema in una certa situazione. Le variabili
che costituiscono DCOP possono essere raggruppate
in due tipologie: variabili input (Vin ) che modellano
la conoscenza esterna acquisita dai sensori ambientali,
e variabili output (Vout ) che rappresentano il risulta-
to del processo di coordinamento distribuito: il loro
valore è determinato mediante l’algoritmo Adopt-N e
può costituire l’input di altre applicazioni (attuatori).
4.2 Risoluzione Cooperativa del Coor-
dination Problem
Indichiamo con S la situazione corrente (stato dei
servizi e della persona assistita), e sia St la situ-
azione al tempo t. Se St 6= St−1 gli agenti devono
inoltrare una “istanza di coordinamento” con cui de-
cidono l’assegnamento A che rappresenta l’attivazione
dei servizi desiderati.
La componente del sistema che si occupa di man-
tenere una schedulazione compatibile con le esigen-
ze della persona assistita è l’Activity Monitor e la
sua attività può richiedere la combinazione di sem-
plice propagazione temporale, ri-scheduling ed altre
procedure complesse.
In generale, è impossibile avere garanzie sulla stret-
ta reattività degli agenti; infatti, anche se l’algorit-
4.3 Adopt-N Algorithm
mo Adopt-N è asincrono, la procedura risolutiva deve
essere iterata in maniera sincrona.
Più specificatamente, Adopt-N viene utilizzato nel
RDE come descritto in Algorithm 1, ed invocato solo
Algorithm 1 Sincronizzazione di ogni agente a di
Adopt-N in RDE
iter ← 0
Siter ← getSensoryInput(Vin a
) 4.3
while true do
Siter−1 ← Siter
{Wait until (current input has changed) OR
(someone else has started)}
while (Siter = Siter−1 ) ∧ (iter ≥ a0 .iter, ∀a0 6= a)
do
a tensione di Adopt. La limitazione di Adopt è infat-
Siter ← getSensoryInput(Vin )
end while
iter ← iter + 1
for all di ∈ Dv∈Vina ∪V a do
out
lb(di ) ← 0 {Reset lower and}
ub(di ) ← ∞ {upper bounds}
end for
A|Vout
a ← runAdopt()
a si basa Adopt analizziamo lavori precedenti e i prob-
triggerBehavior(Vout )
end while
quando St 6= St−1 . Il metodo getSensoryInput() dello
pseudocodice cattura lo stato dell’ambiente tramite le
variabili di input dell’agente a. Tutti gli agenti, con-
correntemente, invocano Adopt-N quando rilevano un
cambiamento di stato o un altro agente ha iniziato
l’iterazione di solving. Quando un agente rileva una
differenza fra le sue variabili di input, la sua decisione
di eseguire l’algoritmo di coordinamento viene propa-
gata in cascata ad altri agenti secondo un priority tree
(si veda la condizione del ciclo while interno).
Il valore delle variabili di input è vincolato a ri-
manere fisso durante l’esecuzione del processo deci-
sionale dell’algoritmo. Questo avviene per mezzo di
una procedura di controllo dei vincoli unari, per la
quale ogni attribuzione di valore diverso dal valore
percepito deve essere fissato a ∞, cosicché non venga
mai esplorata dall’agente di controllo della variabile.
Si noti che è anche possibile modificare il valore di
queste variabili, modificando il problema prima di ogni
iterazione. La strategia di constraint checking è impie-
gata per facilitare rappresentazione e riuso del codice.
Infatti, per DCOP non è mai necessario cambiare il
valore delle variabili tra le iterazioni e questo permette
di minimizzare la fase di ri-inizializzazione fra le iter-
azioni. Entrando maggiormente nei dettagli, la fase di
ri-inizializzazione si verifica in Adopt-N “resettando”
il costo globale determinato da ogni agente, e inducen-
do nuovamente la procedura di ricerca distribuita per
l’assegnamento di costo minimo. Dato che Adopt-N
non si basa sulla comunicazione sincrona tra agenti, il
trasferimento di messaggi avviene con una certa du-
rata temporale casuale, ma comunque finita. Questa
caratteristica ha reso possibile l’adozione dell’algorit-
6
The RDE Project
mo per RDE, senza modificarlo internamente. Inoltre,
mentre gli algoritmi più diffusi per il distributed rea-
soning sono impiegati nella pratica come thread con-
correnti su una singola macchina, la caratteristica di
asincronia di Adopt-N facilita fortemente il passaggio
a una distribuzione reale, dove i ritardi per il message
passing sono maggiori per ampiezza e casualità.
Adopt-N Algorithm
In queste pagine verrà descritto Adopt (Asynchronous
Distributed OPTimization)[6] un algoritmo per l’ot-
timizzazione di vincoli binari distribuiti. L’algoritmo
utilizzato in RDE è Adopot-N (Asynchronous Dis-
tributed OPTimization fon n-ary constraints), un es-
ti la sola possibilità di utilizzare vincoli binari fra le
variabili che è stata rimossa in Adopt-N permettendo
l’utilizzo di vincoli n-ari. In questo paragrafo verrà
proposto Adopt, dato che la conversione di vincoli n-
ari in vincoli binari può essere fatta senza modifiche
sostanziali dell’algoritmo.
Prima di vedere le caratteristiche vincenti sulle quali
lemi che si incontravano nell’implementarli. I lavori
presenti in letteratura prima di Adopt sono i seguenti:
ˆ Asynchronous Backtracking (ABT) (Yokoo92)[7]:
limitato solamente a problemi di soddisfacibilità
booleana;
ˆ Synchronous Branch and Bound (SynchBB) (Hi-
rayama97)[7]: che era proibitivamente lento e
richiedeva una comunicazione sincrona tra gli
agenti oltre che una conoscenza totale del sitema;
ˆ Iterative Improvement (Yokoo96)[7]: Non garan-
tiva la terminazione.
Ciò che si è imparato dal passato è che l’ostacolo
principale per la risoluzione di un DCOP è combinare
l’ottimalità della soluzione con la comunicazione as-
cincrona e con una conosconza locale (che permette
di abbassare lo spazio richiesto). I precedenti approci
hanno fallito perchè è difficile assicurare un backtrack-
ing di ricerca sistematico quando gli agenti modificano
le loro variabili in modo asincrono, inoltre, tutti gli
algoritmi proposti in letteratura utilizzavano il back-
tracking solamente quando erano sicuri di essere ar-
rivati ad una soluzione che non conduceva a quella
ottima.
Date le caratteristiche generali del sistema già spie-
gate, Adopt deve basarsi sulle seguenti metodologie:
ˆ Ogni agente deve poter ottimizzare una funzione
globale comunicando solo localmente con i propri
vicini. Non sarebbe accettabile che ogni agente
parlasse con un unico agente centrale pre-eletto;
ˆ Deve trovare la soluzione velocemente permet-
tendo ad ogni agente di lavorare in modo asin-
corno. Non sarebbe infatti accettabile una co-
municazione sincrona in cui ogni agente resta in
4 DCOP PER SMART HOMES The RDE Project

uno stato di attesa ad aspettare un particolare
messaggio da un vicino, dato che, questo tempo
perso, potrebbe essere utilizzato per fare ciò di
cui l’agente si occupa.
Adopt ha cercato di risolvere questi problemi
basandosi su 3 idee chiave:
1. Ogni agente ha la possibilità di cambiare l’asseg-
nazione della sua variabile non appena ha trovato
una soluzione migliore di quella corrente. Questa
strategia richiede che il sistema sia asincrono dato
che ogni agente non richiede informazioni globali
per fare le proprie decisioni.
2. Il punto 1 permette di abbandonare soluzioni
parziali per altre subottime, quindi deve es-
sere data la possibilità all’agente di riverificare
soluzioni scartate tenendo una complessità di
spazio lineare. Questo è stato fatto tramite le
backtrack threshold.
3. Provvedere a un meccanismo di terminazione in-
terna all’algoritmo. Prima di adesso infatti ogni
algoritmo richiedeva un algoritmo esterno di ter-
minazione da chiamare indipendentemente e che
richiedeva un’inutile scambio di messaggi. Og-
ni agente termina quando threshold = 0 (la
procedura verrà spiegata meglio nel seguito).
ˆ Iterativamente vengono scambiati, tra i nodi vici-
ni nell’albero, informazioni sull’attuale lower-
bound, upper bound, threshold e sul valore del-
la propria soluzione tramite messaggi: Threshold
messagge, Value message, Cost message (come
rappresentato nella figura precedente parte (b));
ˆ Ogni volta che un nodo ha delle nuove infor-
mazioni ricalcola il costo dei vincoli in cui è impli-
cato fino a quando trova un valore della propria
variabile che porta il valore del vincolo sotto il
lower bound precedentemente calcolato. A questo
punto si è trovata una soluzione subottima, il
lower bound viene sovrascritto e la precedente
soluzione scartata;
ˆ Ogni nodo oltre al lower bound (lb) calcola anche
l’upper bound (ub). Nel momento il nodo root
ha le informazioni di tutti i nodi e il backtracking
non migliora la soluzione (threshold = 0) i nodi
possono terminare l’esecuzione.

Si rende noto il fatto che DCOP è un noto proble-

ma NP-Hard. La soluzione ad ogni istanza del proble-
ma in tempo polinomiale non è quindi possibile, dato
che esisteranno sempre istanze che metteranno in crisi
qualsiasi algoritmo. Adopt, nel caso di una soluzione
ottima non calcolabile in tempi limitati, da la possi-
bilità del calcolo di una soluzione approssimata. La
complessità di spazio richiesto per ogni singolo agente
4.4 Agenti, Variabili e Vincoli in RDE
è lineare come è lineare il numero di messaggi inviati. La modelizzazione dei componenti presenti in RDE
L’idea di funzionamento dell’algoritmo è la seguente: DCOP è stata fatta suddividendo il sistema in agenti,
variabili e vincoli secondo l’immagine di seguito.
ˆ la rete viene modellata in un albero, in base al
grafo dei vincoli, in cui ogni nodo contiene una
singola variabile e può avere più figli ma un solo
genitore;

ˆ Ogni nodo assegna alla propria variabile un valore Le variabili sono suddivise in variabili di input (fornite
tra quelli del dominio. dai sensori) e variabili di output (scritte da Adopt-N).

7

Per esempio il vincolo cerchiato in rosso nell’immagine
ha 2 variabili di input (PLTState che da informazioni
riguardo alla stanza in cui si trova la persona assisitita
e PRState che da informazioni sulla posizione attuale
della persona assistita) e una variabile di Output (Ac-
tivity in cui viene memorizzata l’attività che la per-
sona assistita sta facendo in quell’istante). Ad ogni
coppia PLTState e PRState è associato un costo fV 2 .
Adopt-N ha il compito, ogni qualvolta cambia il valore
associato alle variabili di input, di andare a modificare
la variabile di output in base al costo. Nell’esempio
seguente tutti i costi sono tenuti a zero dato che non
esistono coppie di valori di variabili di ingresso uguali
e quindi la discriminazione dell’attività corrente può
essere fatta senza modificare i costi.
PRState PLSTate Activity fV 2
Sitting Kitchen Eating 0
Standing Kitchen Cooking 0 Il problema che tratteremo ora riguarda la gestione e
Laying Kitchen Emergency 0 la modifica di uno schedule in esecuzione in un am-
Standing Bathroom hand washing 0 biente reale o simulato, nel quale è presente un certo
Dato che la rilevazione dell’attività eseguita non è
di facile determinazione (ci possono essere più azioni
che l’assistito può eseguire nella stessa stanza e nella
stessa posizione) si è pensato di aggiungere agli ogget-
ti utilizzati dalle persona anziana un chip RFID. Og-
ni qualvolta la persona sta maneggiando l’oggetto, il
chip RFID comunica con il RFID reader al braccio
dell’assistito. L’attività eseguita sarà associata univo-
camente alla funzione dell’oggetto utilizzato. A livello
di modello viene aggiunto il seguente blocco
in cui compADL associa ad ogni oggetto un costo fv3
che sarà inversamente proporzionale al livello di “con-
fidenza” delle informazioni, cioè alla bontà delle infor-
mazioni ricevute. Ciò che Adopt-N esegue ogni volta
per determinare l’azione eseguita è la minimizzazione
della funzione: fV 2 (P RState, P LT State, Activity) +
fV 3 (Object, Activity) con fV 2 ∈ {0, ∞} e fV 3 ∈ N.
L’attività eseguita è quindi determinata da Adopt-n
in base all’azione che minimizza la funzione cioè quel-
la in cui le informazioni trasferite hanno confidenza
massima . In questo esempio:
8
The RDE Project
Object Activity fV 3
Remote Television 20
Stove Dinner 10
Cofee Breakfast 12
BreadKnife Launch 30
Oltre a questa soluzione si possono adottare alle
strategie quali: (1) discriminazione dell’attivita’ in
base all’orario, (2) studio di algoritmi di Posture
Recognition piu’ efficaci.
Oltre a questo vincolo ci sono anche altri vincoli
che Adopt-N andrà a valutare ogni qualvolta si verifi-
cano dei cambiamenti nella variabili di input, andan-
do a modificare le variabili di output e, nel caso, lo
scheduling delle attività di O-Oscar.
5 L’architettura di scheduling
O-OSCAR
grado di imprevedibilità e incertezza. Dato un insieme
di attività/task, l’obiettivo iniziale è di trovare uno
schedule, ossia una collocazione temporale che soddisfi
due aspetti fondamentali della consistenza:
ˆ Resourse Consistency: non è possibile eseguire
operazioni quando le risorse non sono disponibili;
ˆ Temporal Consistency: rispettare tutti i vin-
coli temporali dei vari task, come release time,
deadline ecc..
Durante l’esecuzione di uno schedule, il verificarsi di
un evento esogeno potrebbe minacciare la consistenza
e quindi portare alcune attività a violare vincoli tem-
porali o a richiedere risorse già allocate. Per questo
motivo è necessario revisionare la soluzione temporale
in esecuzione ogni volta che si verifica un evento es-
terno al fine di mantenerne la consistenza. Uno dei
problemi chiave da risolvere è la qualità delle soluzioni
trovate. La nuova soluzione, a fronte di una manca-
ta consistenza, deve essere il più vicino possibile al-
la precedente in modo da mantenere una certa conti-
nuità temporale. Tradizionalmente esistono due ap-
procci a questo problema, il Predittivo, in cui lo
schedule è robusto e capace di assorbire i “distur-
bi” causati dall’evento esogeno, e il Reattivo, che
modifica la soluzione ogni volta che è necessario man-
tenere la consistenza dello schedule. Quest’ultimo ap-
proccio è implementato dall’O-OSCAR [6] grazie al-
l’Execution Monitor. L’EM è capace di realizzare
una sorta di comportamento reattivo e conveniente-
mente riaggiustare lo schedule mediante la procedu-
ra ISES (Iterative Sampling Earliest Solutions), un
metodo costraint-based sviluppato per risolvere prob-
lemi RCPSP/Max (Resource Constrained Project
5 L’ARCHITETTURA DI SCHEDULING O-OSCAR
Scheduling Problem with Time Windows). Lo sched-
ule Execution Monitor è stato sviluppato come un’in-
tegrazione di O-OSCAR, una architettura software
costraint-based utile per la soluzione di problemi di
scheduling complessi. Inoltre, è stato sviluppato an-
che il Contingency Simulator, un modulo esterno
che simula eventi inaspettati e mette cosı̀ alla prova
l’intero O-OSCAR. Il CS, in particolare, tenta di ri-
tardare attività, variarne la durata o rendere le risorse
non disponibili. Ciò simula situazioni che potrebbero
succedere realmente e quindi utili per testare l’oper-
atività dell’ Execution Monitor. Il cuore di tutto il
sistema è il Representation Module, i cui compiti
sono:
ˆ Domain Representation: descrizione di tutte le
caratteristiche rilevanti del mondo e i vincoli che
regolano la sua evoluzione dinamica tramite un
symbolic language;
ˆ Problem Representation: descrizione dei goal in
termini di stati desiderati da raggiungere a partire
da uno stato iniziale.
O-OSCAR utilizza un approccio CSP (Con-
straint Satisfaction Problem) come tool di
modellazione base per la risoluzione dei prob-
lemi di scheduling. Per questo, tutte le infor-
mazioni mantenute nel Representation Module
devono essere organizzate in termini di vincoli.
Tutti i dati necessari per la risoluzione dei problemi
di schedule sono memorizzati e mantenuti in costante
aggiornamento nel CDB (Costraint Data Base). Esso
offre un servizio attivo che mira a far rispettare, quan-
do è possibile, i vincoli che rappresentano il proble-
ma. In particolare, il CDB è responsabile dei seguenti
aspetti:
ˆ Domain and Problem Representation: il domain
Representation Language permette la rappresen-
tazione di classi di problemi nonché dei vincoli
relativi ad ogni classe.
ˆ Solution Representation and Management: la
rappresentazione di una soluzione in O-Oscar è
costruita in cima a due specializzati Costraint
Reasoners, ognuno responsabile di un partico-
lare aspetto del dominio. I due filoni di infor-
mazione più importanti da mantenere sono tem-
poral features del dominio e resource availability.
9
The RDE Project
I Costraint Reasoners sono richiamati ogni volta
che qualche cambiamento influenza la descrizione
attuale legata alla soluzione corrente.
I due Constraint Reasoners sono: il Temporal
Constraint Management, che memorizza e analizza
le informazioni temporali usando una Temporal Net-
work risolvendo il problema come un Simple Temporal
Problem, e il Resource Consistency, che mantenen-
do per ogni risorsa un Resource Profiles, mantiene in-
formazioni sul livello di consumazione della risorsa e
sulla sua consistenza. Un certo numero di servizi attivi
possono essere implementati sfruttando prontamente
il Representation Module, come l’Automated Problem
Solving Module detto anche SOLVER. Quest’ultimo
guida la ricerca della soluzione basandosi sull’ISES al-
gorithm [11]. Tale procedura greedy opera al fine di
trovare una soluzione consistente e rispettosa di tutti
i vincoli esistenti, evitando che si creino dei conflit-
ti tra risorse e che le attività non rispettino i vin-
coli temporali. Una volta che una soluzione iniziale
per un dato problema è ottenuta, l’Execution Con-
trol module è responsabile di distribuire le attività
pianificate per l’esecuzione e di monitorare lo stato
di esecuzione dei task e degli aspetti rilevanti dell’
ambiente. Le informazioni contenute nel CDB ven-
gono cosı̀ continuamente aggiornate, mentre l’ Exe-
cution Monitor rileva le eventuali inconsistenze che
si possono creare. Quest’ultimo reagisce riportando lo
schedule indietro in uno stato consistente. L’azione di
riparazione viene eseguita sfruttando le capacità del-
l’algoritmo ISES, che è utilizzato come “black box ”; in
altre parole, le revisioni dello schedule vengono trat-
tate come un ri-scheduling globale, senza concentrarsi
solo su una piccola finestra temporale della soluzione.
Lo pseudo-codice che vediamo di seguito descrive l’al-
goritmo seguito dall’Execution Control. All’inizio, la
variabile temporale T è inizializzata a zero e la vari-
abile execSchedule riferisce allo schedule in esecuzione.
Ad ogni ciclo, l’ambiente è osservato per identificare
una differenza tra la situazione che ci si aspetta e l’at-
tuale. Se un evento inaspettato viene rilevato, la rapp-
resentazione della situazione contenuta nel CDB viene
aggiornata e si procede con il controllo della consisten-
za temporale e di risorsa. Se non sorgerà nessun tipo
di conflitto allora l’esecuzione dello schedule può con-
tinuare, altrimenti uno schedule revision deve essere
eseguito per eliminare le varie inconsistenze, sia di tipo
temporale che di contesa di risorse.
Come menzionato precedentemente, l’approccio us-
ato nell’Execution Monitor può essere considerato
globale, nel quale la procedura di revisione accetta
lo schedule nel suo complesso, tenta di risolvere tutti
i conflitti presenti e ritorna la soluzione. Come con-
seguenza di ciò l’unico modo a nostra disposizione di
esercitare controllo sulle attività è di farlo in maniera
preventiva, prima della ISES procedure e quindi pri-
ma che quest’ultima manipoli lo schedule. Tale con-
trollo è necessario per almeno due motivi: il primo è
che vogliamo mantenere la soluzione fisicamente con-
RIFERIMENTI BIBLIOGRAFICI
Algorithm 2 L’Algoritmo di scheduling
T ←0
execSched ← Schedule0
while (Schedule NOT executed) do
ENVIRONMENT SENSING
if Unforeseen Events then
UPDATE REPRESENTATION
if (NOT Temporal Consistency) then
EXIT WITH FAILURE
else
if (NOT Resource Consistency) then
SCHEDULE REVISION
end if
if (Conflicts NOT eliminated) then
EXIT WITH FAILURE
end if
end if
else
T =T +1
end if
end while
sistente in ogni istante, il secondo è che vogliamo con-
servare la possibilità di soddisfare un set di preferenze
date dall’utente. E’ desiderabile che, a fronte di pos-
sibili eventi esogeni durante l’esecuzione dello sched-
ule, la nuova soluzione rimanga il più vicino possibile
alla soluzione iniziale. La continuità dello schedule
può essere controllata inserendo o togliendo vincoli di
precedenza inseriti nell’ultima esecuzione della ISES.
In conclusione, l’attuale sistema è stato implementato
e testato con un set preliminare di 15-30 job. I risul-
tati ottenuti sono molto incoraggianti: nonostante le
inconsistenze di diversa natura che sono state iniettate
nell’ambiente il sistema è riuscito a lavorare veloce-
mente creando nuove soluzioni consistenti. Per esem-
pio, è stata testata l’abilità del sistema nel recuperare
da improvvisi ritardi di una o più attività di differente
gravità o da indisposizioni di risorse in vari momen-
ti dell’esecuzione. Per dare un’idea delle performance
raggiunte, il sistema riesce a rischedulare un proble-
ma RCPSP/Max di 20 attività e 3 risorse in un tempo
medio di 190 millisecondi, durante l’esecuzione.
Riferimenti bibliografici
[1] Amedeo Cesta, Alfredo Milani Planning and
Scheduling. In Intelligenza Artificiale (Ital-
ian Journal on Artificial Intelligence), Spe-
cial Issue for the 50th AI Anniversary, 3(1-
2):35-41, Marzo-Giugno 2006. Reperibile in
http://pst.istc.cnr.it/∼amedeo/papers.php
[2] Amedeo Cesta, Gabriella Cortellessa, Riccardo
Rasconi Monitoring Ederly People with the Robo-
Care Domestic Environment Synthesis and User
Evaluation. ISTC-CNR, Comunicazione Privata
con Amedeo Cesta (amedeo.cesta@istc.cnr.it).
10
The RDE Project
[3] Amedeo Cesta, Luca Iocchi, Riccardo Leone,
Daniele Nardi, Federico Pecora, Riccardo Ras-
coni Robotic, Sensory and Problem-Solving In-
gredients for the Future Home. ISTC-CNR, In
D. Monekosso, P. Remagnino, and Y. Kuno
(Eds.), “Intelligent Environments: Methods, Al-
gorithms and Applications”, pp.67-87, Springer,
DOI 10.1007/978−1−84800−346−05 (published
on-line September 2008). Comunicazione Privata
con Amedeo Cesta (amedeo.cesta@istc.cnr.it).
[4] Federico Pecora, Amedeo Cesta DCOP for Smart
Homes: a case study. ISTC-CNR, In Compu-
tational Intelligence, An International Journal,
23(4):395-419, 2007. Comunicazione Privata con
Amedeo Cesta (amedeo.cesta@istc.cnr.it) .
[5] Riccardo Rasconi, Amedeo Cesta Execution Mon-
itoring and Schedule Revision for O-OSCAR:
a Preliminary Report. ISTC-CNR, In Pro-
ceedings of Online-2003 (Online Constraint
Solving: Handling Change and Uncertain-
ty), A CP-03 Workshop, Kinsale, Ireland,
September 29, pp. 9-23, C. Beck, K. Brown
and G. Verfaillie (Eds.), 2003. Reperibile in
http://pst.istc.cnr.it/∼amedeo/papers.php
[6] Pragnesh Jay Modi, Wei-Min Shen, Milind
Tambe ADOPT: Asynchronous Distributed Con-
straint Optimization with Quality Guarantees.
University of Southern California, In Artificial
Intelligence Journal, (AIJ) 2005. Reperibile in
http://www.cs.cmu.edu/∼pmodi/
[7] Amedeo Cesta, Gabriella Cortellessa, Riccardo
Rasconi, Federico Pecora User-oriented problem
abstractions in scheduling. ISTC-CNR, In In-
novations in Systems and Software Engineer-
ing, 2(1):1-16, 2006. Comunicazione Privata con
Amedeo Cesta (amedeo.cesta@istc.cnr.it).
[8] S. Bahadori, L. Iocchi, G. R. Leone, D.
Nardi, L. Scozzafava Real-Time People Lo-
calization and Tracking through Fixed Stereo
Vision. In Industrial and Engineering Appli-
cations of Artificial Intelligence and Expert
Systems (IEA/AIE), Bari, Italy, 2005. Reperi-
bile in http://www.dis.uniroma1.it/∼iocchi-
/publications/iocchi-ieaaie05.pdf
[9] S. Pellegrini and L. Iocchi. Human Posture
Tracking and Classification through Stereo Vi-
sion and 3D Model Matching. PEURASIP Jour-
nal on Image and Video Processing. vol. 2008 pp.
1-12.ISSN:1687-5176 doi:10.1155/2008/476151.
[10] Amedeo Cesta, Angelo Oddi, Stephen F. Smith
An Iterative Sampling Procedure for Resource
Constrained Project Scheduling with Time Win-
dows. IP-CNR, In Computational Intelligence,
An International Journal, 2006. Reperibile in
http://pst.istc.cnr.it/∼amedeo/papers.php