[Bioperl-l] Bio::Robotics namespace discussion

Jonathan Cline jncline at gmail.com
Thu Jul 30 02:06:38 UTC 2009

I am writing a module for communication with biology robotics, as
discussed recently on #bioperl, and I invite your comments.

Currently this mode talks to a Tecan genesis workstation robot (
http://images.google.com/images?q=tecan genesis ).  Other vendors are
Beckman Biomek, Agilent, etc.  No such modules exist anywhere on the
'net with the exception of some visual basic and labview scripts which I
have found.  There are some computational biologists who program for
robots via high level s/w, but these scripts are not distributed as OSS.

With Tecan, there is a datapipe interface for hardware communication, as
an added $$ option from the vendor.  I haven't checked other vendors to
see if they likewise have an open communication path for third party
software.  By allowing third-party communication, then naturally the
next step is to create a socket client-server; especially as the robot
vendor only support MS Win and using the local machine has typical
Microsoft issues (like losing real time communication with the hardware
due to GUI animation, bad operating system stability, no unix except
cygwin, etc).

On Namespace:
I have chosen Bio::Robotics and Bio::Robotics::Tecan.  There are many
s/w modules already called 'robots' (web spider robots, chat bots, www
automate, etc) so I chose the longer name "robotics" to differentiate
this module as manipulating real hardware.  Bio::Robotics is the
abstraction for generic robotics and Bio::Robotics::(vendor) is the
manufacturer-specific implementation.  Robot control is made more
complex due to the very configurable nature of the work table (placement
of equipment, type of equipment, type of attached arm, etc).   The
abstraction has to be careful not to generalize or assume too much.  In
some cases, the Bio::Robotics modules may expand to arbitrary equipment
such as thermocyclers, tray holders, imagers, etc - that could be a
future roadmap plan.

Here is some theoretical example usage below, subject to change.  At
this time I am deciding how much state to keep within the Perl module. 
By keeping state, some robot programming might be simplified (avoiding
deadlock or tracking tip state).  In general I am aiming for a more
"protocol friendly" method implementation.

To use this software with locally-connected robotics hardware:

    use Bio::Robotics;

    my $tecan = Bio::Robotics->new("Tecan") || die;
    $tecan->attach() || die;
    $tecan->pipette(tips => "1", from => "rack1");
    $tecan->pipette(aspirate => "1", dispense => "1", from => "sampleTray", to => "DNATray");

To use this software with remote robotics hardware over the network:

  # On the local machine, run:
    use Bio::Robotics;

	my @connected_hardware = Bio::Robotics->query();
    my $tecan = Bio::Robotics->new("Tecan") || die "no tecan found in @connected_hardware\n";
    $tecan->attach() || die;
    $tecan->configure("my work table configuration file") || die;
    # Run the server and process commands
    while (1) {
      $error = $tecan->server(passwordplaintext => "0xd290"); 
      if ($tecan->lastClientCommand() =~ /^shutdown/) { 

  # On the remote machine (the client), run:
    use Bio::Robotics;

    my $server = "heavybio.dyndns.org:8080";
    my $password = "0xd290";
    my $tecan = Bio::Robotics->new("Tecan");
    $tecan->connect($server, $mypassword) || die;
    $tecan->pipette(tips => "1", from => "rack200");
    $tecan->pipette(aspirate => "1", dispense => "1", 
    	from => "sampleTray A1", to => "DNATray A2",
    	volume => "45", liquid => "Buffer");
    $tecan->pipette(drop => "1");


## Jonathan Cline
## jcline at ieee.org
## Mobile: +1-805-617-0223

More information about the Bioperl-l mailing list