Archive for August, 2013

The first few painful steps …

Posted in Android, Python RULES! on August 30, 2013 by asteriondaedalus

… POSH on Samsung SII

I moved a cut-down version of POSH onto my Samsung SII to see about getting it running.

No joy first up as Python doens’t appear to run from the S4A shell – or at least I am missing something.

No matter, a few tries to get it running from the Python shell convinced me to re-code the Main function as a class and do something relatively simple to call a POSH plan et al.

The code relies on parsing child directories for plans, agent descriptions, behaviours etc and most of the code in Main function is simply dealing with the plethora of command line options when running from an OS shell.

There is no shame in hard coding the dang blasted experiments into an instance of the base class.

Once my “Hello World” application is running I will try some experiments with the Android sensors then I want to try talking to my Romeo All In One on my experimental work horse.  That will need to chat with the Arduino using Bluetooth.

Actually, the neat thing is that the Android library for Python, as it is JSON-RPC based, allows one to run python applications on one’s PC while talking wirelessly to the Android device – so you can prototype the application on your PC before dumping it onto the Android device.  More or less why Bluetooth to the Arduino is a good idea as I should be able to talk across the Android device’s Bluetooth to the Arduino from the PC – neat if it works.

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.

A short experiment while I had a couple of hours…

Posted in AUTOPILOT, Software on August 12, 2013 by asteriondaedalus

… it turned out to be a couple of hours as I found I could connect to the BBB from Winoze box but not from the 64 bit Debian box??

Turned out the BBB, like the BB, is a little dodgy and needs to be reset as you are not guaranteed an Ethernet connection on startup.

Makes it a nuisance I imagine for embedded applications I am guessing.

In any event, finally got around to doing hello world from Eclipse.

helloworld on BBB

Just a start.  Now the fun begins.

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.