Archive for the Agent Category

Time to choose

Posted in Agent on November 4, 2017 by asteriondaedalus

Having played with Profeta, eJason and now Astor I think the time has come to settle on one.

eJason is a great idea, especially as it is built on erlang, but it is knobbled as it is a partial implementation.  It has .send so can talk between agents running in the vm but does not to distributed agents.  You don’t have sensors and actuators.  All that could be added but there isn’t enough design info and pulling apart the codes would be fun but a major project in itself.

Astor is a great evolution of AgentSpeak, especially as it tries to readily incorporate the imperative side.  That is, however, already tackled in Profeta.   Astor is build with Java so has that in its favour, if you were a Java clone.

So, Profeta seems the BDI tool for me.  But it doesn’t do distributed agents.  That is, I suspect, where SPADE comes in.  However, some work involved.  Profeta assumes one environment so the PROFETA class is a singleton.   To run in the SPADE environment that design assumption may need be broken.  Also, the PROFETA class has its own execution loop, it may want a single step to be driven by a SPADE tick event.

Not much work but now having gotten over the distraction of the options I can focus.


Posted in Agent, Erlang, Python RULES!, RabbitMQ, XMPP on June 8, 2015 by asteriondaedalus

So, sorted the BlackWidow and likely the YellowJacket connectivity. The socket approach seems to be the better option, and that is TCP based, so porting of mqtt code might still be possible – although the application is simple enough so a Python adaptor on the host between the boards and the mqtt server would do just as well.

Now, the other side is that I opted for moving from emqttd to RabbitMQ as the mqtt broker.  This is due to the fact that there is likely a way to get RabbitMQ talking to Spade agents via XMPP (with some work).  This might be a way of integrating Profeta agents into the picture without deep integration into Spade that I have been currently investigating.

Not to mention likely being able to use the same inter-agent communication for eJason base experiments.

Essentially using mqtt as a ‘blackboard‘.

Belief Desire Intention

Posted in Agent, Python RULES! on February 18, 2014 by asteriondaedalus

Now I did promise to focus on my Master’s work – my last subject in fact before the Dissertation – but doodling helps clear the head.

I have mused a bit about Jason the Agent Speak language and dabble in that to master the BDI concept.

Now the porting of Spade2 to my Android devices stalled a bit because my tablet got flogged at work.  However, the basic examples were running so I was more or less to move onto the BDI agents in Spade2.  Quite apart from the manual site going down (grrrrr), the BDI approach left me a little cold.

The reason I like Jason is because of Orientedness.  A term I invented (I know because the spell checker is set to American and they make up new words whimsically it would seem and the spell checker balked so I first … so there).

In any event, Orientedness.  Consider, UML.  First reaction is that it is Object Oriented. But that is misleading.  

Class diagrams are an expression of OO but are activity diagrams?  Are sequence diagrams?  Many of the diagrammatic styles actually are trying to express the things OO cannot (though some of the lexicon of OO infects them).

Consider event driven programming.  Is it OO?  No, Event driven paradigm certainly can be facilitated in OO languages but its Orientedness is something different to classes, methods, etc.  It is events (yes insert inversion of control and/or dependency injection if you must), and probably some temporal or state (or stateless) aspects.

Jason presents an Agent Oriented programming language where the Agent Orientedness is expressed in the syntax of the language.  Not to say you can’t do agent “stuff” in Java (JADE, JACK, Cougar, etc.) but, I guess the way to explain it, is that the Agent Orientedness expressed in Java based technologies is obfuscated.  Much the same way OO obfuscates the functional design/model (yes we want to argue for UML again but case tools don’t sit on that many desks, I mean how many of the trillion and one opensource projects out there have a case model as part of a release … no really don’t, or you’ll get my sequence diagrams and activity diagrams are the expression of the functional model that OO claims is an anti-pattern stance).

So, we were talking about the BDI model in spade2.  It sorta kinda reeks of the obfuscated approaches of JADE and JACK etc.

I came across two alternative approaches, one in process and one potentially to provide a server based solution.

In process candidate is Pyke.  This approach “cooks” python code from logic programming expressions that have a similar flavor to the why beliefs and desires are expressed in Jason.  It also has Plans (so-called).  So, a little side experiment between study sessions is look at using Pyke in place of the “native” BDI solution in spade2.  Now if it isn’t itself really BDI note you can code up a BDI model in Prolog which is a logic programming language – so if you need to be pedantic you might port the prolog BDI model to Pyke, for a laugh.

The other interesting approach is Fuxi.  Loosely, RDF based RETE rule engine but interesting.  The analogue here is the oro server.  Now first iteration would be to hook into an oro server, but down the track a full python port???

Toying with …

Posted in Agent, Android, Python RULES! on September 4, 2013 by asteriondaedalus

The tail end code fragment in the (POSH) file gave me an idea … well it came to me in the car on the way to work, you all know how those problems simmer in the darkest deepest reaches before peculating up.

loops_running = 1
while loops_running > 0:

loops_running = 0
for agent in agents:

if agent.loopStatus()[0]:
loops_running += 1

This is the main (simple) loop that runs until all agent plans are spent.

What occurred to me was that I was looking at how to eventually meld the POSH plan engine into SPADE (some old how).  Currently the POSH agents appear to want to work in the same scope so either a SPADE behaviour (Cyclic and Periodic)  for performing repetitive tasks might be the shot.  Could also be a One Shot in place of the while loop and the SPADE agent sends message to itself to recall the One Shot behaviour if agent.loopStatus()[0]==TRUE.

The thing is, of course, there is some likely confusion in using SPADE AGENTS+BEHAVIOUR as well as POSH AGENTS+BEHAVIOUR.  I am not thinking, for example, there needs be a one-to-one mapping – though it might a side effect of only creating one POSH agent per SPADE agent.  Still, the POSH agent approach seems a neat way to build vehicular components (thus running on on machine) and the SPADE agents can be the communal aspect of a multi agent team.

In any event  the simplest thing might end up multiple inheritance and …

Lunch time poking around …

Posted in Agent, Python RULES! on August 13, 2013 by asteriondaedalus

… it pays to dream.

I mentioned the idea of using petri-net based plans as part of mission planning for my vehicles previously.  The idea was based on papers on ways AUV were controlled.  I found a python based petri-net library but there appeared to be some effort to sort out a graphical editor.

I lucked into find on Behavior Oriented Development and an idea called POSH which takes a plan in lisp like language.  I further lucked into a python based POSH engine.  Moreover I found a POSH editor, though it didn’t reverse engineer POSH files into their graphical representation, but it did help me start to understand the syntax.

The image above is my reverse engineering of one of the examples from the jyPOSH distribution, namely:

Which becomes (in the source file window of ABODE):

Any way, the gist is you draft the plan in POSH and then code a plan agent in python that executes the plan, thus:


ACTIONS and SENSES are just methods on the Behaviour class.  This makes sense to me (also have played with LISP – including writing LISP-like extensions to FORTH) so I am going to work on this in the background and see about how this might be integrated into SPADE agents – even if it is just a plan execution service.

So, in short  it requires a modular behavior library in any OO language, and a version of POSH action selection for that language (aka jyPosh).

Clearly the SENSES and the ACTIONS can talk to a robotic vehicle.

It may even make sense to make this the vehicle AGENT and use it for the reactive planning and then use the SPADE agents as higher level agents.

One of the “SENSES” could be receipt of commands from a port – for example.  A couple of the examples do this so no reason why this could not be to a XMPP chatter server say AUML centric as used in SPADE.  Could also be ZeroMQ or ZeroRPC as well.

All good. Options are good.

Well that about wraps it up for ROS …

Posted in Agent on August 6, 2013 by asteriondaedalus

… more or less.

The gist is I have been looking at ways of building a mission management system for my UAV/UUV/UAS/AUV in and around Python.

Various tools that I have been playing with include SPADE which is an Agent based tool kit for Python.  This has an interesting range of base Agent types including BDI agents (or here if you aren’t afraid).

Still, there was still a need of a central server and that’s okay.

I found that the ROS server could be supplanted by using ZeroMQ/RPC as it had examples of a data service that could pass for the features of the ROS server.  Between the SPADE and the ZeroMQ/RPC things started to come together.

Still, while you can, to some degree, paint missions with a BDI approach I felt that Agents should have generic Actions and internal Goals and let external Goals be set by some other semantic.

I liked the mission planning side of Savage’s AUV Workbench.  Especially the AVCL, which is an <XML> Autonomous Vehicle Command Language </XML>.

So much so I looked for tools to create Python bindings, so with PyXB in hand I took the schema and built bindings.  The idea is to use the AUV Workbench to build missions and then to have it run on a Python engine on the vehicle.  That is still in work as I have to pour over the AVCL interpreter, written in JAVA, to port it in between other fun (including next lot of Master’s course subjects starting September).

The other option was to tear the interpreter out of the simulation environment to run it in Java on the vehicle.  I played with that for a while cheap Android PC were being used as the “brains”.  However, the Beaglebone Black (2 in drawer) and the Python environment for Android loosened that goal from its rafters.

Still, there was another approach, that was being used (in principle) in both AUV and UAV.  Namely petri nets for mission planning and execution.

That appealed as I am playing with Coloured Petri Nets to become a better System Safety Engineer.  But how do you build a Petri Net based planner in Python?

Answer is two fold.

First with Snakes!  A full blown Petri Net library for Python.  Not only that you can have nets of nets which is powerful in itself but is also means you can have plans on how to use plans.

Coding Petri Nets isn’t fun, especially if they get large, so you need an editing environment and Viola!  An eclipsed based Petri Net editor, Snake Friendly (almost), of course as it produces PNML.  Snake is a bit behind the PML standard (apparently) so may not help that for generating documentation and perhaps “fragments”.

Of course, the other idea might be to take AVCL files and use a xlst file to convert them to PNML – or even just use an ETL tool.

Would you believe …

Posted in Agent, Android, Linux on July 21, 2013 by asteriondaedalus

would you believe

I spent a little time tonight looking at how to port the agent oriented framework SPADE2 onto my ACER Iconia 500 as a prelude to dropping it onto a spare Android phone.

You’ll recall the jottings on Agent Oriented as an approach on one of the pages attached to this blog.

After a little fiddling I got the Iconia running an agent while talking to the SPADE server on my desktop machine.

I am fairly chuffed about getting this going as I was prompted to pair it up with ideas from the CellBot python libraries to have a Android phone/Arduino pairing.  However, I have a Romeo all in One on my Dog Chaser, and should be able to get the phone to talk to the 10DOF controller through the MAV link messages which have a companion Python library.


Seek and you shall …

Posted in Agent, Arduino, Prototyping, Software on December 4, 2011 by asteriondaedalus

… well, find Seek.

A pivotal paper on avatar behaviors caught my attention (see here).

I started to look at pulling the basics out of the C++ templates and work it into basic behaviors for use on Arduino/Processing, then came across someone who had already “ported” it (see here).

Ideally then, ignoring the graphics and using “real” sensor input (rather than simulated) one should have a basic set of vehicular behaviors (running, say, on the Romeo) with the Jason app, running on the Android phone, selecting behaviors.

Work to go but things falling into one’s lap to spur one on what!