[Bioperl-l] Bio::Robotics namespace discussion

[Jonathan Cline]

Smithies, Russell wrote:
> I "acquired" an old Biomek 1000 that I'm thinking of modernising. It was originally controlled by a monstrously large but slow pc (IBM Value Point Model 466DX2 computer with Microsoft Windows* Version 3.1)
> My plan is to fit a 3-axis CAD/CAM stepper controller (about $60) and use software like mach3 www.machsupport.com along with G-code to control it.
> I come from an engineering background so it seemed like the easy way to me :-)
>
> Now I just need a bit of free time to get it working...
>
> --Russell
>
>
>   
I agree, that's probably the best way to go.  It's hard to know what
amount of s/w processing was done on the host PC vs. the embedded
controller.  If you were able to connect directly to the robot hardware
with serial port(s) or whatever it's using, it would be tough to find
out the comm protocol unless someone has already reverse engineered it
(which is doubtful).   Also from what I have seen online, attempting to
run the old software under virtual machine is unpredictable due to
timing differences in the serial port communication.   So removal of the
old electronics is probably the best bet.  If it has one arm, then it's
much easier.  

As for robots with working workstation software, it seems the annoyance
factor is that while the scripting languages are powerful (for GUI
scripting that is), they are still relatively low level.  Bio types with
a bit of CS seem to immediately turn to visual basic, labview, or even
excel spreadsheets and macros, in order to provide a higher level
abstraction for the workstation software.   To me, it seems natural that
there should be a "protocol compiler" which takes biology protocols as
input, and gives robot instructions as output (google "protolexer"). 
The huge bottleneck of course is that everyone's robotics work tables
and equipment are somewhat unique to their needs.


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


>> -----Original Message-----
>> From: bioperl-l-bounces at lists.open-bio.org [mailto:bioperl-l-
>> bounces at lists.open-bio.org] On Behalf Of Jonathan Cline
>> Sent: Thursday, 30 July 2009 2:07 p.m.
>> To: bioperl-l at lists.open-bio.org
>> Cc: Jonathan Cline
>> Subject: [Bioperl-l] Bio::Robotics namespace discussion
>>
>> 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->home();
>>     $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/) {
>>         last;
>>       }
>>     }
>>     $tecan->detach();
>>     exit(0);
>>
>>   # 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->home();
>>     $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");
>>     ...
>>     $tecan->disconnect();
>>     exit(0);
>>
>>
>>
>> --
>>
>> ## Jonathan Cline
>> ## jcline at ieee.org
>> ## Mobile: +1-805-617-0223
>> ########################
>>
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>     
> =======================================================================
> Attention: The information contained in this message and/or attachments
> from AgResearch Limited is intended only for the persons or entities
> to which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipients is prohibited by AgResearch
> Limited. If you have received this message in error, please notify the
> sender immediately.
> =======================================================================
>