[Tiny-tux] Weevils, TEND, Swarm, Arc-hive, what's next? Autonomy for Robotic performance art

[Corey McGuire]

Who's ready for the next autonomous robotic performance art project?

I am working on a platform that allows people to create their own vision of
a robot and include it in an ad hoc swarm of robots created by other
people.  However, there is no reason this system couldn't be used for
swarms of similar robots with a singular vision, aesthetic, or purpose.

Another design goal is to make this as off the shelf as possible so we
leverage mature, community supported platforms.  Of course, there are
critical components that will not be off the shelf, namely, the swarming
software components.  I want to keep OUR work focused to that.


I have had success with the control solution portion of the complete Rover
swarming system.  At this moment, I can script anything to follow
designated way points with purely off the shelf equipment.

Let's talk about the current state of my work.  The components required for
an "Off the shelf" rover are as follows:

   - Rover (two channel drive platform with control over throttle and
   steering, so a differential drive system like a tank will require a two
   motor speed control that handles channel mixing, such as the Sabertooth
   used in the Weevils:
   http://www.dimensionengineering.com/products/sabertooth2x60)
   - Ardupilot Mega 2.5 (same as the 2.0 but a more streamlined design) or
   Mav Link compatible autopilot.
   - XBee's, preferably 900Mhz (to avoid interfearence with other 2.4Ghz
   signals which may be utilized for remote control and administration)
   - Three Channel (or more) Hobby Radio transmitter and receiver.  Three
   channels are for throttle, steering, and a 3 position "mode" (Manual Drive,
   Program Waypoints, Follow waypoints)
   - Laptop
   - Mission Planner
   - Optional Sensors (dead-reckoning or "flow sensors" and sonar)

The Ardupilot is configured and provides telemetry over the XBee connection
to the laptop.  The Laptop runs the mission planner which has a comfortable
interface for observing the state of the rover, handling "flight planning",
updating software, and tuning the behavior of the rover.

Talking to the Ardupiolt (or, indeed, select other auto pilots) is
standardized using a common protocol called MAV-Link (
http://qgroundcontrol.org/mavlink/start).  It is stateless and fairly
robust, but it primarily deals with waypoints and not much else.


*Going forward:*

None of this is true autonomy.  This is, purely, a control bundle awaiting
commands from a brain such as to brains in our heads...or a brains we
create.  What obviously comes next is a brain which takes in choreography
as inputs for behaviors and give coordinates as outputs.

Choreography could simply be an extension to the mission planner, or the
Swarm Timeline concept.  What is more important is how we handle
coordination and behavior.  There are two modes:

   - Mother node
   - Locally

We could create a mothernode that handles the execution of choreography and
runs the behaviors centrally, then issues commands remotely, or we can
upload choreography to the constituent rovers which coordinate in realtime
and execute behavior locally.

There are arguments for either, but I feel we don't have to choose.  If we
opt to make this system modular, there isn't any reason that we can't
seamlessly move execution from remotely to locally.

Attached is the diagram for the proposed "Weevils".  Right now, we have
completed the "Drone Phase".  From the drone phase, we could begin
developing the Mothernode to begin remote execution of the Rovers.

Here is what I propose for the platform going forward:

   - Consider an embedded hardware platform we can develop on for Localized
   Behaviors (Currently, I am favoring the BeagleBone
   http://beagleboard.org/bone)
   - Select a tool chain which allows common code to run on the mothernode
   or on the embedded system (Currently, I am favoring JAVA since bytecode
   should be executable on both platforms without cross compiling and it
   should perform much better than python.)
   - Getting our hands very dirty with XBee. How do we make this a robust
   protocol for bidirectional communication from a number of nodes?  This is
   the next piece of the puzzle for me and I have begun to work on this
   problem this week.
   - Begin evaluating the state of the Swarm timeline software,
   the extensibility of the Ardupilot Mission Planner, or rolling a new
   solution (which might not be too hard, since mission planning can be
   handled with embedded hardware http://www.youtube.com/watch?v=cy2BE3Dzl3s
   )
   - Begin developing the mothernode solution


One important question that might beg some consideration, however, is
"Who's got ideas for a project that might utilize these tools?"  It would
be great if we had a cohesive project that would allow us to make proposals
for burningman, robodock, awesome foundation, kickstarter, etc.
 The vision of a multicultural robot swarm is great, but it would be easier
to promote a cohesive project, first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.noisebridge.net/pipermail/tiny-tux/attachments/20121121/11d78445/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Weevil.png
Type: image/png
Size: 28894 bytes
Desc: not available
URL: <http://www.noisebridge.net/pipermail/tiny-tux/attachments/20121121/11d78445/attachment-0002.png>