Biology-friendly robot programming language: Training your robot the PaR-PaR way

Oct. 23, 2012 — Teaching a robot a new trick is a challenge. You can't reward it with treats and it doesn't respond to approval or disappointment in your voice. For researchers in the biological sciences, however, the future training of robots has been made much easier thanks to a new program called "PaR-PaR."

Nathan Hillson, a biochemist at the U.S. Department of Energy (DOE)'s Joint BioEnergy Institute (JBEI), led the development of PaR-PaR, which stands for Programming a Robot. PaR-PaR is a simple high-level, biology-friendly, robot-programming language that allows researchers to make better use of liquid-handling robots and thereby make possible experiments that otherwise might not have been considered.

"The syntax and compiler for PaR-PaR are based on computer science principles and a deep understanding of biological workflows," Hillson says. "After minimal training, a biologist should be able to independently write complicated protocols for a robot within an hour. With the adoption of PaR-PaR as a standard cross-platform language, hand-written or software-generated robotic protocols could easily be shared across laboratories."

Hillson, who directs JBEI's Synthetic Biology program and also holds an appointment with the Lawrence Berkeley National Laboratory (Berkeley Lab)'s Physical Biosciences Division, is the corresponding author of a paper describing PaR-PaR that appears in the American Chemical Society journal Synthetic Biology. The paper is titled "PaR-PaR Laboratory Automation Platform." Co-authors are Gregory Linshiz, Nina Stawski, Sean Poust, Changhao Bi and Jay Keasling.

Using robots to perform labor-intensive multi-step biological tasks, such as the construction and cloning of DNA molecules, can increase research productivity and lower costs by reducing experimental error rates and providing more reliable and reproducible experimental data. To date, however, automation companies have targeted the highly-repetitive industrial laboratory operations market while largely ignoring the development of flexible easy-to-use programming tools for dynamic non-repetitive research environments. As a consequence, researchers in the biological sciences have had to depend upon professional programmers or vendor-supplied graphical user interfaces with limited capabilities.

"Our vision was for a single protocol to be executable across different robotic platforms in different laboratories, just as a single computer software program is executable across multiple brands of computer hardware," Hillson says. "We also wanted robotics to be accessible to biologists, not just to robot specialist programmers, and for a laboratory that has a particular brand of robot to benefit from a wide variety of software and protocols."

Hillson, who earlier led the development of a unique software program called "j5" for identifying cost-effective DNA construction strategies, says that beyond enabling biologists to manually instruct robots in a time-effective manner, PaR-PaR can also amplify the utility of biological design automation software tools such as j5.

"Before PaR-PaR, j5 only outputted protocols for one single robot platform," Hillson says. "After PaR-PaR, the same protocol can now be executed on many different robot platforms."

The PaR-PaR language uses an object-oriented approach that represents physical laboratory objects -- including reagents, plastic consumables and laboratory devices -- as virtual objects. Each object has associated properties, such as a name and a physical location, and multiple objects can be grouped together to create a new composite object with its own properties.

Actions can be performed on objects and sequences of actions can be consolidated into procedures that in turn are issued as PaR-PaR commands. Collections of procedural definitions can be imported into PaR-PaR via external modules.

"A researcher, perhaps in conjunction with biological design automation software such as j5, composes a PaR-PaR script that is parsed and sent to a database," Hillson says. "The operational flow of the commands are optimized and adapted to the configuration of a specific robotic platform. Commands are then translated from the PaR-PaR meta-language into the robotic scripting language for execution."

Hillson and his colleagues have developed PaR-PaR as open-source software freely available through its web interface on the public PaR-PaR webserver http://parpar.jbei.org.

"Flexible and biology-friendly operation of robotic equipment is key to its successful integration in biological laboratories, and the efforts required to operate a robot must be much smaller than the alternative manual lab work," Hillson says. "PaR-PaR accomplishes all of these objectives and is intended to benefit a broad segment of the biological research community, including non-profits, government agencies and commercial companies."

This work was primarily supported by the DOE Office of Science.

Share this story on Facebook, Twitter, and Google:

Other social bookmarking and sharing tools:

Story Source:

The above story is reprinted from materials provided by DOE/Lawrence Berkeley National Laboratory.

Note: Materials may be edited for content and length. For further information, please contact the source cited above.

Journal Reference:

Gregory Linshiz, Nina Stawski, Sean Poust, Changhao Bi, Jay D. Keasling, Nathan J. Hillson. PaR-PaR Laboratory Automation Platform. ACS Synthetic Biology, 2012; : 121009112212000 DOI: 10.1021/sb300075t

Note: If no author is given, the source is cited instead.

Disclaimer: Views expressed in this article do not necessarily reflect those of ScienceDaily or its staff.

View the original article here

Space travel with a new language in tow

ScienceDaily (Oct. 1, 2012) — September 28, for the first time ever, SES, the Luxembourg-based satellite operator, has allowed an Ariane 5 rocket to transport a TV satellite into space, which is made by Astrium and runs entirely on latest generation software. Every single one of the programs used to operate the satellite was written in the new satellite language SPELL. The acronym stands for "Satellite Procedure Execution Language & Library."

What we are talking about here is a new standard, which will help the many different programming languages that were previously used to operate satellites and their subsystems to be unified under one roof. The University of Luxembourg's Interdisciplinary Centre for Security, Reliability and Trust (SnT) has contributed substantially to SPELL's being adopted in the operations of Astrium satellites. To this end, SnT scientists took an existing mathematical tool and refined it getting it ready for practical application, with whose help the procedures written in different native languages can now be translated into SPELL using a fully automated process.

SES is one of the world's biggest satellite operators with a vast fleet of satellites in orbit. The satellites and their technical components are produced by different manufacturers who each use their own programming language. "Because of the complete and utter lack of common standards up until now, we used to have to make a big production out of operation and maintenance of the machines," explains Martin Halliwell, Chief Technology Officer at SES. "Our operators were working with a number of different programming languages to help us control our SES fleet through space." Which is problematic as the machines don't easily forgive programming errors. Says Halliwell: "If a single error is made, it may result in our satellite getting lost in space. Which, for us, literally means incurring millions in losses."

Which is why SES decided a while ago now to develop the open-source software, SPELL. SPELL allows for the careful execution of every imaginable navigational procedure from any given ground control system for all potential satellites in the fleet. In other words, maximum flexibility with maximum security. "There is, however, a catch to the whole thing," concedes Dr. Frank Hermann, SnT scientist. "All the various control procedures that exist in different programming languages and that are being used must be converted over to SPELL. If that does not happen automatically and is one hundred percent error-free, it quickly turns into very resource-intensive and error-prone undertaking."

Together, SnT's Frank Hermann and his collegues, in close collaboration with SES automation specialists, have tackled the problem head-on using a methode known as triple graph transformation to automatically translate the programming languages employed by the new satellite's subsystems into the common language SPELL. According to Hermann, " triple graph transformation is a mathematical tool that has been the focus of active research since the 1990s. Along with other mathematical tools, it represents the ideal instrument for combining different programming languages under SPELL."

What's special about the new translation process is that it does not require any source code programming. "We are working with a visual development setting, which records translation rules in a graphic user interface," explains Hermann. These rules are automatically executed by specialized transformation tools. Quality assurance happens through consistency checks, which are automated as well. "Their efficacy has been documented through multiple formal mathematical proofs," says Hermann. If the translation runs smoothly, every piece of information from the original language is first converted into a graph. "This creates a network made up of many different nodes on the graphic interface," explains Hermann. The network is then read and translated into target graphs for the target language SPELL. "Every single bit of information in the original language has a corresponding SPELL counterpart."

The SES validation teams have confirmed that the translation is highly precise. "This was a prerequisite for being able to unanimously program our new satellite's systems using SPELL," says Martin Halliwell. SnT's Vice-Director, Prof. Thomas Engel, is very pleased with the SnT scientists' performance specifically and with the SES/SnT collaborative in general: "The new satellite and SPELL will now have to prove themselves in space. If everything runs smoothly -- which we are quite certain that it will -- our basic science research will have made an important contribution to increasing SES's performance and to making Luxembourg more competitive in this area."

Share this story on Facebook, Twitter, and Google:

Other social bookmarking and sharing tools:

Story Source:

The above story is reprinted from materials provided by Université du Luxembourg, via AlphaGalileo.

Note: Materials may be edited for content and length. For further information, please contact the source cited above.

Note: If no author is given, the source is cited instead.

Disclaimer: Views expressed in this article do not necessarily reflect those of ScienceDaily or its staff.

View the original article here

Writing graphics software gets much easier: New programming language yields code that’s much shorter and clearer -- but also faster

ScienceDaily (Aug. 1, 2012) — Image-processing software is a hot commodity: Just look at Instagram, a company built around image processing that Facebook is trying to buy for a billion dollars. Image processing is also going mobile, as more and more people are sending cellphone photos directly to the Web, without transferring them to a computer first.

At the same time, digital-photo files are getting so big that, without a lot of clever software engineering, processing them would take a painfully long time on a desktop computer, let alone a cellphone. Unfortunately, the tricks that engineers use to speed up their image-processing algorithms make their code almost unreadable, and rarely reusable. Adding a new function to an image-processing program, or modifying it to run on a different device, often requires rethinking and revising it from top to bottom.

Researchers at MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) aim to change that, with a new programming language called Halide. Not only are Halide programs easier to read, write and revise than image-processing programs written in a conventional language, but because Halide automates code-optimization procedures that would ordinarily take hours to perform by hand, they're also significantly faster.

In tests, the MIT researchers used Halide to rewrite several common image-processing algorithms whose performance had already been optimized by seasoned programmers. The Halide versions were typically about one-third as long but offered significant performance gains -- two-, three-, or even six-fold speedups. In one instance, the Halide program was actually longer than the original -- but the speedup was 70-fold.

Jonathan Ragan-Kelley, a graduate student in the Department of Electrical Engineering and Computer Science (EECS), and Andrew Adams, a CSAIL postdoc, led the development of Halide, and they've released the code online. At this month's Siggraph, the premier graphics conference, they'll present a paper on Halide, which they co-wrote with MIT computer science professors Saman Amarasinghe and Fredo Durand and with colleagues at Adobe and Stanford University.

Parallel pipelines

One reason that image processing is so computationally intensive is that it generally requires a succession of discrete operations. After light strikes the sensor in a cellphone camera, the phone combs through the image data for values that indicate malfunctioning sensor pixels and corrects them. Then it correlates the readings from pixels sensitive to different colors to deduce the actual colors of image regions. Then it does some color correction, and then some contrast adjustment, to make the image colors better correspond to what the human eye sees. At this point, the phone has done so much processing that it takes another pass through the data to clean it up.

And that's just to display the image on the phone screen. Software that does anything more complicated, like removing red eye, or softening shadows, or boosting color saturation -- or making the image look like an old Polaroid photo -- introduces still more layers of processing. Moreover, high-level modifications often require the software to go back and recompute prior stages in the pipeline.

In today's multicore chips, distributing different segments of the image to cores working in parallel can make image processing more efficient. But the way parallel processing is usually done, after each step in the image-processing pipeline, the cores would send the results of their computations back to main memory. Because data transfer is much slower than computation, this can eat up all the performance gains offered by parallelization.

So software engineers try to keep the individual cores busy for as long as possible before they have to ship their results to memory. That means that the cores have to execute several steps in the processing pipeline on their separate chunks of data without aggregating their results. Keeping track of all the dependencies between pixels being processed on separate cores is what makes the code for efficient image processors so complicated. Moreover, the trade-offs between the number of cores, the processing power of the cores, the amount of local memory available to each core, and the time it takes to move data off-core varies from machine to machine, so a program optimized for one device may offer no speed advantages on a different one.

Divide and conquer

Halide doesn't spare the programmer from thinking about how to parallelize efficiently on particular machines, but it splits that problem off from the description of the image-processing algorithms. A Halide program has two sections: one for the algorithms, and one for the processing "schedule." The schedule can specify the size and shape of the image chunks that each core needs to process at each step in the pipeline, and it can specify data dependencies -- for instance, that steps being executed on particular cores will need access to the results of previous steps on different cores. Once the schedule is drawn up, however, Halide handles all the accounting automatically.

A programmer who wants to export a program to a different machine just changes the schedule, not the algorithm description. A programmer who wants to add a new processing step to the pipeline just plugs in a description of the new procedure, without having to modify the existing ones. (A new step in the pipeline will require a corresponding specification in the schedule, however.)

"When you have the idea that you might want to parallelize something a certain way or use stages a certain way, when writing that manually, it's really hard to express that idea correctly," Ragan-Kelley says. "If you have a new optimization idea that you want to apply, chances are you're going to spend three days debugging it because you've broken it in the process. With this, you change one line that expresses that idea, and it synthesizes the correct thing."

Although Halide programs are simpler to write and to read than ordinary image-processing programs, because the scheduling is handled automatically, they still frequently offer performance gains over even the most carefully hand-engineered code. Moreover, Halide code is so easy to modify that programmers could simply experiment with half-baked ideas to see if they improve performance.

"You can just flail around and try different things at random, and you'll often find something really good," Adams says. "Only much later, when you've thought about it very hard, will you figure out why it's good."

Share this story on Facebook, Twitter, and Google:

Other social bookmarking and sharing tools:

Story Source:

The above story is reprinted from materials provided by Massachusetts Institute of Technology, via EurekAlert!, a service of AAAS.

Note: Materials may be edited for content and length. For further information, please contact the source cited above.

Note: If no author is given, the source is cited instead.

Disclaimer: Views expressed in this article do not necessarily reflect those of ScienceDaily or its staff.

View the original article here