Paper presented at the III Workshop on Engineering Multi-Agent Systems (EMAS) - AAMAS 2016 - Singapore - 09/05/2016
Veja mais trabalhos em: fb.com/turingproject
Instagram: @prof.pantoja
%in Soweto+277-882-255-28 abortion pills for sale in soweto
ARGO - A Customized Jason Architecture for Programming Embedded Robotic Agents
1. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 1
ARGO: A Customized Jason Architecture for
Programming Embedded Robotic Agents
1. Instituto de Matemática e Estatística (IME), Universidade de São Paulo (USP), Brazil
2. Escola Politécnica (EP), Universidade de São Paulo (USP), Brazil
3. Centro Federal de Educação Tecnológica (CEFET/RJ), Brazil
4. Universidade Federal Fluminense (UFF), Brazil
Laboratório de Técnicas
Inteligentes - LTI
Carlos Eduardo Pantoja 3,4
Márcio Fernando Stabile Junior 1
Nilson Mori Lazarin 3
Jaime Simão Sichman 2,1
III Workshop on Engineering Multi-Agent Systems
EMAS@AAMAS 2016
Singapore
09/05/2016
2. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 2
ARGO
The Argo
by Lorenzo Costa
Argo was the ship
that Jason and
the Argonauts
sailed in the
search of the
golden fleece in
Greek mythology.
3. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 3
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
4. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 4
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
5. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 5
Motivation
MAS
A robot is a physical
entity, composed by
customized hardware,
sensors and actuators
How can we program
and control a robot
including reactive and
goal-directed
behaviours? .
6. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 6
BDI model
[http://www.inf.ufrgs.br/prosoft/bdi4jade]
7. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 7
Jason
[Bordini et al. 2007]
8. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 8
Motivation
Programming robotic agents using Jason has
revealed to be a difficult task
• Bottlenecks can occur
» high cost of processing perceptions
» large intention stack is generated
• Integration with hardware is not implemented
• Hence, the robot may not succeed !
9. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 9
Motivation
Javino [Lazarin and Pantoja 2015]
• middleware for communication between Java and
microcontrolers (Arduino)
• However, using several sensors may compromise the
robot execution time
Perception filters [Stabile Jr and Sichman 2015]
• filters are able to improve Jason agent's performance
in a significant way
10. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 10
Motivation
Instead of taking into account all perceptions ....
MAS
11. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 11
Motivation
One can filter perceptions!
MAS
12. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 12
Objectives
ARGO provides a customized Jason
architecture for programming embedded robotic
agents
• Javino + Perception filters
Layered robot architecture
Experiments using a ground vehicle platform in
a real-time collision scenario
Evaluations of filters impact
13. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 13
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
14. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 14
Jason [1]
• AgentSpeak Interpreter [2]
[1] [Bordini et al. 2007] [2] [Rao 1996]
15. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 15
Jason [1]
• AgentSpeak Interpreter [2]
Most time-
consuming
processes
[1] [Bordini et al. 2007] [2] [Rao 1996]
16. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 16
Profiling
86% of total processing time
17. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 17
Profiling
99% of total processing time
18. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 18
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
19. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 19
Perception filters
[van Oijen and Dignum 2011]
• Integrating agents (2APL, Jadex and Jason) to
computer games;
• Middleware responsible for perception filtering;
• Interest Subscription Manager.
[Bordeux et al. 1999]
• Extend AGENTlib with a perception mechanism;
• Perception filter types:
» Range filter;
» Field of view filter;
» Type detector filter.
20. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 20
Perception filters
Example of Jason perceptions
• List of annotated literals
temperature(right,36)
temperature(back,38)
light(left,143)
distance(front,227)
distance(right,30)
22. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 23
Perception filters
Example of filter change internal action
• Name of file passed as parameter
+!carry_to(R)
<− ! take (object, R);
.change_filter(search);
−object (r1);
!!search(slots).
23. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 24
Perception filters
[Bordini et al. 2007]
24. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 25
Perception filters
[Bordini et al. 2007]
25. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 26
Perception filters
Changes in Agent class
public void buf(List<Literal> percepts) {
if (percepts == null) {
return;
}
int adds = 0;
int dels = 0;
long startTime = qProfiling == null ? 0 : System.nanoTime();
filter(percepts);
Iterator<Literal> perceptsInBB = getBB().getPercepts();
while (perceptsInBB.hasNext()) {
...
26. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 27
Perception filters
Changes in Agent class
private static void filter(List<Literal> percept) {
if(currentObjective==null){
return;
}
Iterator<Literal> it = percept.iterator();
while (it.hasNext()) {
if (remove(it.next())) {
it.remove();
}
}
}
27. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 28
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
28. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 29
Javino
Javino is a protocol for exchanging messages:
• between low-level hardware and a high-level
programming language
• double-side library for communication
• provides error detection
29. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 30
Operation modes
Listen mode
• only from hardware to software
AGENT
send a message in
every loop
get when it
wants
30. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 31
Operation modes
Request mode
• from software to hardware;
• the hardware answers.
AGENT
request a message
answer with a message
31. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 32
Operation modes
Send mode
• from software to hardware;
• the hardware executes an action.
AGENT
send a
message
execute a low-
level command
32. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 33
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
33. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 34
ARGO is:
• a customized architecture for Jason
• employs both Javino middleware and perception
filters
» Javino provides a bridge between the intelligent agent
and the robots sensors and actuators
» Perception filters act blocking specific perceptions in
runtime
ARGO aims to be a practical architecture for
programming automated embedded agents
using BDI agents
ARGO
34. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 35
It directly controls the actuators at runtime
It receives perceptions from the sensors
automatically within a pre-defined time interval
It enables changing filters at runtime
It enables changing accessed device at runtime
ARGO agents may communicate with others
Jason Agents
It enables to decide when to perceive the real
world at runtime
ARGO overview
36. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 37
Overview of Robot’s Architecture
37. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 38
Receiving percepts
Sensors capture raw data from
the real world and send them
to the microcontroller
employed.
38. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 39
Receiving percepts
In the firmware layer, raw data
is transformed into perceptions
based on the AOPL chosen.
39. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 40
Receiving percepts
Javino is responsible for
sending the percepts to the
reasoning layer using serial
communication
40. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 41
Agent’s reasoning
The agent is able to reason
with percepts coming directly
from real world and the MAS
can be embedded in single-
board computers (Raspberry,
etc.) or a computer with USB
interface
41. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 42
Executing an action
Agent deliberates and if an
action has to be executed, an
action message using Javino
is sent.
42. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 43
Executing an action
Javino sends the action
message to the microcontroller
connected in the USB port
described in the message.
43. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 44
Executing an action
All possible actuator’s
functions are programmed to
be executed in response to
serial messages coming from
Javino.
44. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 45
Executing an action
The actuator is activated.
45. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 46
Jason’s reasoning cycle with filters
51. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 52
Customized architecture
The serial port from which the agent is
receiving perceptions and executing actions.
52. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 53
Customized architecture
Defines if the agent has
to perceive or not the
real world.
53. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 54
Customized architecture
A time interval, in
milliseconds, for the next
real world sensing
54. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 55
Customized architecture
Function responsible for
returning the perceptions from
the real world if:
i) the perceptions is not
blocked;
ii) the time limit was reached;
iii) the agent is an ARGO agent
55. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 56
Customized architecture
Responsible for filtering
perceptions, as stated
before.
56. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 57
Customized architecture
Changes in TransitionSystem class
public boolean reasoningCycle() {
…
ag.buf(this.realWorldPerceptions());
…
}
57. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 58
Customized architecture
New realWorldPerceptions function
public List<Literal> realWorldPerceptions() {
long perceiving = System.nanoTime();
List<Literal> percepts = new ArrayList<Literal>();
if(((perceiving - lastPerceived) < this.limit) || this.blocked)
return null;
lastPerceived = perceiving;
if (this.agArch.getArgo().requestData(this.agArch.getPort(), "getPercepts")) {
String rwPercepts = this.agArch.getArgo().getData();
String perception[] = rwPercepts.split(";");
for (int cont = 0; cont <= perception.length - 1; cont++) {
percepts.add(Literal.parseLiteral(perception[cont]));
}
return percepts;
}
58. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 59
Internal Actions
ARGO Internal Actions:
• .limit(x)
» defines the sensing interval in milliseconds
• .port(y)
» defines which serial port should be used by the agent
• .percepts(open|block)
» decides whether or not to perceive the real world
• .act(w)
» sends to the hardware an action to be executed by a microcontroller
• .change_filter(filterName)
» defines the filter to constrain perceptions in runtime
59. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 60
Limitations
Limit of 127 serial ports
• Due to limitation of USB
Connection to one port at a time
• Avoids competition
• It can be changed at runtime
Only ARGO agents can control devices
• Common Jason agents do not have access to Javino
ARGO agents must be atomic
• Cannot create more than one instance of the same agent
60. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 61
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
61. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 62
Case study
• The robot configuration:
• 4 distance sensors
• 4 light sensors
• 4 temperature sensors
• 1 Arduino board
• 1 Arduino 4WD chassis
• Initial distance of 2m from the wall
• The robot moves at constant speed
• The robot should stop before
achieving a specified desired
distance from the wall
62. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 63
Evaluating the experiment
Experimental design guidelines defined by [Jain 1991]
Essential terms:
Response variable
• Processing time
» from the moment the robot perceives the wall until it stops
• Final distance
» from the position the robot stops to the wall
Primary Factors
• Desired distance
• Perception interval
• Filter
63. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 64
Evaluating the experiment
Essential terms:
• Levels
» Values that a factor can assume
Factor Levels
Desired distance 40 cm 80 cm 120 cm
Perception Interval 25 ms 35 ms 50 ms
Filter No Filter Front Side Front Distance
• Replications
» Three times for each experiment (81 experiments)
64. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 65
Evaluating the experiment
Desired distance
Initial distance
2 m
67. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 68
Evaluating the experiment
Agent code:
68. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 69
Evaluating the experiment
Agent code:
Set serial port COM8.
Arduino device.
69. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 70
Evaluating the experiment
Agent code:
Set an interval of 25ms
for perceiving the real-
world
70. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 71
Evaluating the experiment
Agent code:
Open the selected port
to start receiving
percepts
72. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 73
Evaluating the experiment
Agent code:
Send a message
to the
microcontroller to
move ahead
73. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 74
Evaluating the experiment
Agent code:
Keep moving
ahead while the
perceived
distance is
greater than the
distance limit
74. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 75
Evaluating the experiment
Agent code:
Stop when it
perceives the
wall
75. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 76
Evaluating the experiment
Agent code:
Some additional
plans
76. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 77
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
77. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 78
0
20
40
60
80
100
120
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Desired Distance 40 Desired Distance 80 Desired Distance 120
FinalDistance
No filter
Front Side
Front Distance
Experiments
In all
experiments,
the robot
collided with
the wall!!!
78. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 79
0
20
40
60
80
100
120
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Desired Distance 40 Desired Distance 80 Desired Distance 120
FinalDistance
No filter
Front Side
Front Distance
Experiments
In some
experiments,
the robot
didn’t collided
with the wall!!!
But it stopped
closer to wall
compared to
the front
distance filter
79. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 80
0
20
40
60
80
100
120
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Perception
Interval 20
Perception
Interval 35
Perception
Interval 50
Desired Distance 40 Desired Distance 80 Desired Distance 120
FinalDistance
No filter
Front Side
Front Distance
Experiments
In quite all the
experiments,
the robot
didn’t collided
with the wall!!!
80. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 81
Experiments
The use of the filter was important for obtaining a better
response time
Factor Variation attributed
Distance Limit (L) 1,415%
Perception Interval (I) 0,165%
Filter (F) 88,965%
Interaction between L and I 0,525%
Interaction between L and F 3,715%
Interaction between I and F 0,265%
Interaction between L and I
and F
1,725%
error 3,285%
81. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 82
Outline
1. Introduction
2. Building Blocks: Jason / Perception Filters / Javino
3. ARGO
4. Case Study
5. Obtained Results
6. Conclusions and Further Work
82. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 83
Conclusions
The main contribution of ARGO is to offer an
open architecture that enables Jason agents to
integrate with hardware and to use perception
filters
• Reduction processing
It allows an agent to decide in runtime:
• when to start or to stop perceiving
• the interval between each perception
• which filters to use
83. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 84
Further work
Different filtering methods
Extending ARGO for multi-robot systems
Testing ARGO in different domains
Provide other hardware-side libraries
• PIC16F, Intel and STM32.
84. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 85
References
[Bordini et al. 2007] Bordini, R.H., Hubner, J.F., Wooldridge, M.
Programming Multi-Agent Systems in AgentSpeak Using Jason. John
Wiley & Sons Ltd., 2007.
[Lazarin and Pantoja 2015] Lazarin, N.M., Pantoja, C.E. A Robotic-Agent
Platform For Embedding Software Agents Using Raspberry Pi and Arduino
Boards. In: Proc. 9th Software Agents, Environments and Applications
School (WESAAC 2015), Niterói, RJ, Brazil, 2015.
[Rao 1996] Rao, A.S. AgentSpeak(L): BDI Agents Speak Out in a Logical
Computable Language. In: de Velde, W.V., Perram, J.W. (eds.) Proc. of the
7th European Workshop on Modelling Autonomous Agents in a Multi-
Agent World (MAAMAW 1996). Lecture Notes in Artificial Intelligence, vol.
1038, pp. 42-55. Springer-Verlag, Secaucus. USA, 1996.
[Stabile Jr. and Sichman 2015] Stabile Jr., M.F., Sichman, J.S. Evaluating
Perception Filters In BDI Jason Agents. In: Proc. 4th Brazilian Conference
on Intelligent Systems (BRACIS 2015), Natal, RN, Brazil, 2015.
86. Pantoja, Stabile, Lazarin and Sichman 2016 EMAS@AAMAS 2016, Singapore, 09/05/16 ARGO 87
END
THANKS FOR YOUR ATTENTION
pantoja@cefet-rj.br
mstabile@ime.usp.br
nilson.lazarin@cefet-rj.br
jaime.sichman@poli.usp.br
Notes de l'éditeur
1
Coloquei esse slide caso seja necessário justificar a escolha do nome ARGO.
Uma definição simples de robôs sendo controlados por algum raciocínio (inclusive o uso de Sistemas Multi-agentes).
Dentro do cenário de agentes, surgiu o modelo BDI, que foi criado com base em como os seres humanos pensam. Atribuindo aos agentes crenças, informações sobre o ambiente, desejos, que são objetivos que o agente tem e intenções, que são aqueles objetivos que o agente decidiu que quer atingir e vai agir para isso.
Usar o modelo BDI permite um maior grau de realismo na representação dos comportamentos.
Michael Bratman
E para desenvolver esses agentes, é possível usar o Jason.
É natural utilizar Jason para criar agentes, por que o Jason é um interpretador para uma linguagem de programação orientada a agentes que utiliza o modelo BDI.
Aqui em um exemplo, o agente vai procurar lixo e levar para um incinerador.
A ideia aqui é mostrar a dificuldade de se utilizar o Jason para a programação de robôs.
Em [Lazarin and Pantoja 2015] foi apresentado um protocolo para comunicação entre microcontroladores e linguagens de alto nível. O middleware Javino foi desenvolvido para fazer a comunicação entre placas Arduino e a linguagem Java. O Javino foi utilizado em uma plataforma robótica para “levar” as informações dos sensores como percepções para um SMA desenvolvido com o Jason. Muitos sensores levam ao comprometimento da execução.
Em [Stabile and Sichman 2015] filtros de percepções para o Jason apresentam resultados que melhoram a performance do Jason em sistemas de simulação.
A todo momento, o agente terá que processar todas as percepções que vem do ambiente.
Filtrar as percepções do robô.
The belief update function, which processes the perceptions and the function that unifies the variables in the plans and rules.
Since both their execution times are dependant on the number of perceptions, we researched and found some previous work that aimed to filter perceptions and decided to implement a perception filter on Jason to try to reduce the processing time.
The belief update function, which processes the perceptions and the function that unifies the variables in the plans and rules.
Since both their execution times are dependant on the number of perceptions, we researched and found some previous work that aimed to filter perceptions and decided to implement a perception filter on Jason to try to reduce the processing time.
Fazendo uma análise no código do Jason, descobrimos que um dos métodos que demora mais tempo executando é a função de atualização de crenças, que processa as percepções.
Pesquisando, encontramos alguns artigos que faziam uso de filtros de percepção e decidimos implementar um filtro de percepção no Jason para tentar diminuir o tempo de processamento.
No primeiro artigo, o objetivo do autor é inserir agentes em jogos de computador e ele propõe a criação de um middleware que recebe as informações do ambiente e processa para entregar ao agente somente aquelas percepções que são úteis para ele.
Isso é feito através de um Gerenciador de Assinaturas de Interesse, que são arquivos pré-criados que servem para dizer ao middleware o que é interessante para cada agente.
No segundo, o objetivo é integrar A UMA arquitetura de software chamada AGENTlib um mecanismo de percepção. Junto a esse mecanismo, foram implementados uma série de tipos de filtros de percepção que são usados para saber se a informação sobre um objeto deve ou não ser enviada ao agente.
Alguns desses filtros são o filtro de intervalo, que omite objetos a uma certa distância,
Filtro de campo de visão que simula um campo de visão do agente, e o
Filtro detector de tipo, que seleciona objetos de tipos específicos.
Com isso, conseguimos modelar e implementar um filtro de percepção dentro do ciclo de raciocínio do Jason. Depois do agente receber a lista de percepções e antes de fazer a atualização das crenças, é feito uma filtragem que exclui todas as percepções que não são interessantes para o agente naquele momento.
Para entender como foi feito, primeiro é importante saber como são as percepções no Jason.
Um agente Jason recebe as percepções na forma de uma lista de literais em linguagem lógica como essa, com predicado, termos. E em Jason, as crenças podem ter anotações, que são informações a mais que podem ser utilizadas pelo agente, como por exemplo de onde essa informação veio. Se foi de uma percepção, se foi outro agente que informou ou se ele deduziu sozinho.
Nós especificamos
É feito um matching dos valores do literal com os valores do filtro. Se todos combinarem, é retirada.
Assim, propomos que para cada agente vão ser criados documentos de restrição, que informam ao interpretador quais percepções devem ser descartadas.
Estes documentos de restrição são construídos em formato xml, e podem restringir quaisquer parte do literal.
Para que uma percepção seja excluída, é necessário que todas as condições sejam verdadeiras.
Nesse exemplo embaixo, o predicado parâmetro temperatura, light e distance combinam e fazem parte da expressão regular. A anotação também casa com os valores do filtro source e percept.
Mas, se o operador 1 for diferente de front, como todas as outras regras são válidas, o literal seria excluído.
Caso o operador 1 seja igual a front então esse literal não seria excluído.
Os operadores são usados para comparar o valor do literal com o do filtro
EQ: O valor do parâmetro na percepção deve ser igual ao valor dentro da tag. Que pode ser uma expressão regular para a linguagem Java.
NE: O valor do parâmetro na percepção deve ser diferente valor dentro da tag. Que pode ser uma expressão regular para a linguagem Java.
GT: O valor do parâmetro na percepção deve ser maior do que o valor dentro da tag (inteiro ou de ponto flutuante).
GE: O valor do parâmetro na percepção deve ser maior ou igual ao valor dentro da tag (inteiro ou de ponto flutuante).
LT: O valor do parâmetro na percepção deve ser menor do que o valor dentro da tag (inteiro ou de ponto flutuante).
LE: O valor do parâmetro na percepção deve ser menor ou igual ao valor dentro da tag (inteiro ou de ponto flutuante).
Pode ser que dependendo da situação e do objetivo atual do agente, seja interessante que os filtros sejam alterados.
Para isso, foi incluída uma ação interna {change filter} que pode ser incluída como parte de um plano para alterar o filtro atual. O parâmetro da função vai especificar então um novo arquivo com uma configuração de filtragem diferente que vai ser usada dali em diante.
Então, depois que essa função for chamada, toda vez que o agente receber uma lista de literais como percepção, o filtro vai ver com base nesse arquivo quais literais vão ser excluídos.
O Javino em si é um protocolo de comunicação entre controladores e linguagens de programação de alto nível que provê um mecanismo de detecção de erros. O nome Javino foi criado da junção de JAVa +arduINO, pois foi a primeira implementação do protocolo, feita para essas duas linguagens. Mas o protocolo implementado para o Javino pode ser implementado em qualquer controlador (que tenha no mínimo 256 bytes de RAM) ou linguagem de alto nível. Por exemplo, para controladores PIC16F desenvolvemos o JAVIC.
O protocolo deve ser implementado em duas bibliotecas: uma no lado do hardware e outra no lado do software. A justificativa para isso é que as demais bibliotecas que utilizamos (RXTX, JavaComm, etc.) só provem soluções para um lado. Isso faz com que o projetista do robô tenha que se preocupar com a detecção de erros em um dos lados e implementar mecanismos para isso por conta própria. Como o protocolo foi pensado para usar em SMA a identificação e descarte de uma mensagem com ruídos de transmissão, impede que o SMA pare de executar (no caso do Jason).
Para se trabalhar com o Javino existem modos de operação, que são as formas como um lado pode se comunicar com outro, visto que eles são independentes.
O Listen mode implica que o lado do software fique “ouvindo” a porta serial. O controlador é programado para ficar enviando mensagens a cada loop (controladores executam em laços eternos) e o lado do software “ouve” quando precisar.
No caso do Jason, o agente tenta ouvir o hardware apenas quando chega o passo de perceber o ambiente no reasoning cycle. Esse modo gera um quantitativo de perda de mensagens devido a falta de sincronismo na troca de mensagens (já que um pode tentar ouvir antes do outro ter enviado).
No Request mode, o software faz uma requisição ao hardware, que prontamente responde com outra mensagem.
No caso do Jason, o agente faz uma requisição a cada ciclo de raciocínio no passo de perceber o ambiente. O hardware responde ao agente com uma mensagem com as percepções montadas no formato da AOPL. Esse comportamento do hardware precisa ser programado pelo projetista.
Por fim, o Send mode é o modo de operação onde o software envia uma mensagem para o hardware e este executa uma operação de baixo nível (i.e. ativar um atuador).
No caso do Jason, o agente envia uma mensagem para execução de uma ação e o controlador ativa um atuador. Esse comportamento também deve ser programado pelo projetista.
São as habilidades de um agente ARGO.
Serão explicadas mais a frente.
Um agente ARGO é capaz de controlar vários dispositivos (micro-controladores) através da porta serial. Ele não consegue controlar dois controladores ao mesmo tempo, mas pode, em tempo de execução, escolher qual dispositivo receber percepções e executar ações.
Um agente ARGO pode se comunicar com outros agentes comuns do Jason, e se for o caso, delegar as percepções que recebeu para eles (basta programar para que assim que ele receber a percepção encaminhar para o agente específico) ou então executar ações a pedido de outros agentes.
Todos os agentes, tanto ARGO quanto comuns, tem a habilidade de filtrar percepções. Mas apenas os agentes ARGO recebem percepções dos sensores.
Vários dispositivos podem ser utilizados, até atingir o limite (127 portas USB) de portas seriais.
Essa é a arquitetura da construção de um Robô para ser usado com o ARGO. Ela possui três camadas onde é preciso intervir: Hardware, Firmware e Reasoning.
Na camada de hardware são escolhidos e conectados todos os dispositivos físicos.
Na camada de firmware é necessário a escolha de controladores onde estarão conectados os sensores e os atuadores. A imagem exibe três possibilidades (PIC, ATMEGA e INTEL), mas outros podem ser utilizados, desde que tenham uma implementação do protocolo do Javino no lado do hardware. Na camada de firmware também é feita a preparação das percepções no formato da AOPL a ser utilizada no SMA.
Na camada do reasoning, é escolhida a AOPL do SMA utilizado/desenvolvido e a implementação do protocolo do Javino para o lado do software (no nosso caso usamos a do Java). A camada de reasoning é fisicamente independente da camada do firmware. Os dispositivos podem ser trocados sem problemas. Porém, logicamente dependente pois o firmware tem que estar programado para prover percepções no formato da linguagem do SMA escolhido.
A camada de reasoning deve ficar embarcada em dispositivos com Sistema Operacional e interface USB como placas que são pequenos computadores (Raspberry, BeagleBoard, Galileo, etc.) ou computadores (PC, Notebooks, etc.)
Os próximos slides são uma “animação” de cada camada.
Nessa camada tem que se conectar todos os dispositivos físicos (controladores, sensores, atuadores, boards, plataformas, etc.).
Os sensores captam os dados brutos do mundo real.
Nessa camada, as informações capturadas pelos sensores (dados brutos) são transformadas em percepções baseada na AOPL a ser utilizada.
Aqui ocorre a comunicação serial através do Javino.
As percepções vinda do mundo real chegam diretamente ao agente.
O agente envia uma mensagem para executar uma ação, se este for o caso.
Aqui, caso o agente tente enviar uma mensagem através da porta serial e ele não tem acesso a porta, o Javino responde ao agente que não conseguiu enviar a mensagem para que exista a possibilidade de se abortar o plano.
Contudo se a ação não for executada por falha no efetuador, o agente irá considerar que a ação foi executada. Nesses casos, uma estratégia seria o agente verificar através de percepções do mundo real se a sua ação foi ou não efetiva, ou ainda, pedir a outro agente para fazer essa verificação.
O Javino só transmite novamente.
Ao receber uma mensagem do agente, o controlador reage executando uma ação.
Por exemplo a mensagem “fffe09moveFront”. O controlador vai receber apenas o conteúdo “moveFront” e verificar se tem alguma condição programada que chame algum procedimento em resposta a mensagem.
If(msg==“moveFront”){
turnOnMotors();
}
Essas foram as alterações que foram feitas no Jason. Essa imagem está no artigo que submetemos para o AAMAS mas não está na versão do EMAS, pois eles criticaram a questão de ter dado muita ênfase a implementação. Coloquei para deixar mais claro todo entendimento, se preciso.
Os demais slides fazem uma “animação” por cada implementação.
Essa classe é que representa a arquitetura customizada. A classe ARGO estende a classe AgArch para permitir que sejam definidos no arquivo de configuração do SMA.
Ex.:
MAS argo {
infrastructure: Centralised
agents:
argonaut agentArchClass Argo;
aslSourcePath:
src/asl";
}
Na arquitetura, o Javino foi colocado como atributo para que somente agentes ARGO fossem capazes de perceber o ambiente. Caso contrário, todos os agentes instanciados teriam o Javino, mesmo que não fosse usado.
Função get para retornar a instância do Javino
A porta foi colocada na ArgArch para que em tempo de execução o agente pudesse alterar qual dispositivo estivesse usando.
Essa foi uma implementação que fizemos quando estávamos no laboratório em Outubro passado.
Criamos o comportamento de bloquear ou não as percepções em tempo de execução.
Essa foi uma implementação que fizemos quando estávamos no laboratório em Outubro passado.
Criamos o comportamento de bloquear ou não as percepções em tempo de execução.
O limite é indicado por um valor em ms que indica quanto tempo o agente deve esperar até a perceber o ambiente (mundo real) a próxima vez.
O método responsável por perceber o ambiente.
Essa é a única modificação que modifica o funcionamento do Jason, pois substitui o método de perceber o ambiente simulado (classe Environment do Jason) pelas percepções vinda dos sensores. O ambiente simulado não fica desativado, mas as crenças não são mais provenientes dele.
Desenvolvemos essa função na LTI em Outubro.
O if em vermelho é a implementação do Request mode do Javino. Primeiro é feito um request de percepções (“getPercepts”), o controlador responde e em seguida as percepções são pegas através do método getData().
As percepções vem separadas por “;” e devem ser “divididas”. Ex.: “fffe2atemp(front,3);temp(back,9);light(right,35)”
Essas são as ações internas desenvolvidas para gerenciar todo os comportamentos descritos anteriormente.
No pacote de distribuição do ARGO, as ações internas estão dentro da pasta de ações do Jason (stdlib), então basta usar .limit(1000) por exemplo. Antes teríamos que colocar o nome do pacote javino.limit(1000) ou intact.change_filter(filtro).
Um dos revisores do AAMAS comentou sobre as limitações. Então descrevi aqui algumas que identifiquei.
A plataforma faz uso de comunicação serial via USB. Então ao embarcar um SMA, o limite de dispositivos que podem ser usados é o limite possível que a USB permite (127 dispositivos).
Um agente só pode estar conectado a apenas uma porta por vez. Só existe um atributo port por agente ARGO. Foi uma escolha para evitar conflitos de porta. Caso fosse optado por mais de uma porta, o agente deveria fazer um request para cada microcontrolador da sua lista de dispositivos, o que deixaria o ciclo de raciocínio mais lento.
Não pode existir competição (dois agentes tentando acessar a mesma porta) senão haverá colisão de mensagens e o Javino não irá funcionar. É uma limitação da comunicação serial.
Os agentes em ARGO devem ser atômicos, ou seja, só deve existir uma instância deles. Configurações diferentes geram competições por porta serial.
Ex.:
agents:
argonaut agentArchClass Argo #2;
• Variável de resposta é o resultado de um experimento. Nos experimentos realizados neste trabalho, as variáveis de resposta são o tempo de processamento depois de perceber a parede e a distância que o robô parou da parede.
• Fatores são as variáveis que afetam a variável de resposta. Como um exemplo, o número de percepções afeta o tempo necessário para que um agente possa responder para o servidor. Fatores podem ser primários ou secundários. Fatores primários são aqueles cujos efeitos devem ser quantificados, enquanto fatores secundários são aqueles que impactam o desempenho, mas cujo impacto não estamos interessados em quantificar.
• Níveis são os valores que um fator pode assumir. No caso acima, os níveis do fator “distância“ é a distância que o agente deve parar e os valores utilizados no experimento, são 40cm, 80cm ou 120cm. O fator interval de percepção tem valores 25ms, 35ms e 50ms. O fator filtro tem valores NoFilter, FrontSide e FrontDistance.
• Replicação é a repetição de alguns ou todos os experimentos. Se todas as experiências de um estudo são repetidas três vezes, é dito que o estudo teve três repetições.
Coloquei a imagem desse protótipo com que executamos alguns testes ai no LTI. A imagem ajuda a mostrar a dinâmica dos experimentos. Deixei caso seja necessário.
Coloquei o código do agente que utilizamos nos testes. Os demais slides explicam alguns trechos do código.
Seta a porta serial COM8 no Windows. Se for usar Linux o MAC é só mudar para a nomenclatura de portas do SO usado.
Começa a perceber o mundo real.
Colocamos esses planos de adição de crença para “complicar” o raciocínio do agente e gerar mais eventos.
Coloquei apenas as referências usadas na apresentação.