[Bioperl-l] Bio::Robotics namespace discussion
Chris Fields
cjfields at illinois.edu
Fri Aug 7 02:30:09 UTC 2009
Jonathan,
Just to make sure you aren't accidentally 'warnocked' by the core devs:
Your code sounds quite nice! However, we will begin the process of
massively restructuring bioperl pretty soon, so I don't think it's a
good idea to gear your code towards fitting directly into core. The
best alternative should be fairly obvious, which is to release it to
CPAN listing BioPerl 1.6.0 as a dependency if it is required.
Your modules may or may not need the Bio* namespace (that's up to you,
actually); there are several non-bioperl modules that also share the
Bio* namespace, and I believe there are modules that aren't Bio* that
use BioPerl (Gbrowse comes to mind). If you're focusing on
interaction with robotics, Robotics::Bio::X might be a better
namespace for instance (b/c you could expand later into other possibly
non-bio robotics interfaces).
The cpan-discuss list is probably a good place to ask, or (after you
register on PAUSE) you can register the module namespace and see if
there are any objections to the request.
chris
On Aug 2, 2009, at 10:32 PM, Jonathan Cline wrote:
> 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.
>> =
>> =
>> =====================================================================
>>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
More information about the Bioperl-l
mailing list