Slashdot Mirror
Buzz: a Novel Programming Language For Heterogeneous Robot Swarms
New submitter pRobotika writes: Designing the behavior of robot swarms is difficult; the larger the group, the more tricky it is to predict its dynamics and the causes of errors. Buzz is a new open-source programming language specifically for robot swarms. It's designed for ease of use and is inspired by well-known programming languages such as JavaScript, Python and Lua. Buzz also includes a number of constructs specifically designed for swarm-level development. The “swarm” construct allows a developer to split the robots into multiple groups and assign a specific task to each. Swarms can be created, disbanded, and modified dynamically. The “neighbors” construct captures an important concept in swarm systems: locality. In nature, individuals interact directly and only with nearby swarm-mates. Interactions include communication, obstacle avoidance or leader following. The neighbors construct provides functions to mimic these mechanisms.
I read the story, but I don't see why this needed to be a whole new language, rather than a library.
5 seconds using Slashdot's own search field...
Buzz
Also, search is stupidly broken. Clicking the title just toggles between expanded and collapsed view, and there's no (obvious) way to read the story.
This seems to be an appropriate use of a DSL, not a new programming language. Just add some constructs to an existing language (Ruby and Lisp are particularly good at making seamless DSLs) embodying the new concepts. A language is a silly way to deal with this... instead, choose a language that supports the features you need and add the concepts to it.
In this case, a language like Erlang or Go might be good choices, both designed for robust, concurrent, and distributed processing. Add in a library to either (or both) that embodies the concept of neighbors and swarms and you get multiple wins: an immediate pool of programmers who already know the language, far fewer bugs in the core language, better performance, dev environments, compilers... a long list of wins right off the start.
There are sometimes good reasons to create a new language. But this is not one of them, in my opinion.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
I read the paper. It didn't need to be a programming language. The paper has three separate parts: a mechanism for adapting standalone robots of multiple designs and with different roles, into a complex, goal-achieving swarm. First, it does this by coordinating tasks and flocking behavior through "virtual stigmergy." Stigmergy is how ants and bees coordinate: they leave traces in the environment that indicate task, distance and direction to task target, and when those traces pass a threshold some or all of the swarm *acts*. It's a cool idea, although flocking and stigmergy can be found in video games as old as the original Pac-Man and Rip-Off. Second, they expose the virtual stigmergy and awareness of swarm membership and swarm member locations through an interface (hardware and software) that sits on top of the usual robot command & control. They've written a VM that handles the real-time data management associated with these new "awarenesses." Third, they write an independent language targeted at their VM, with native access to the swarm(), member(), and stigmergy() objects. The language looks like Javascript. The authors aren't great language writers; they even comment about "the jargon of object-oriented programming." There was another paper: "Micro Virtual Machines as Solid Foundation for Language Development," that they would have benefited much from reading. If they'd targeted their VM to *just* handle the hardware, specialty concurrency issues, and garbage collection, and left everything else up to independent language writers, they wouldn't be asking people to program their robots in two different languages (one for swarm management, one for robot management), and the language people could have created highly optimizing compilers, libraries and languages targeted at doing virtual stigmergy well.
I'm the researcher who designed Buzz. I'd like to explain a few things, since I see that a few reasonable points have been raised by the commenters.
This article is a repost.
The old post was made by us, while this new one wasn't. I'm sorry this happened, but it's out of our control.
This could have been a library.
This is a reasonable proposition, but it misses the point of why we went for a language instead. Buzz is a domain-specific language. The concept that some of its features could have been implemented with a library is correct, but irrelevant. The point is whether a library makes more sense than a dedicated language for the domain under study. In our opinion, a DSL makes more sense. This is our proposition, and the basic point of our work.
In our opinion, the peculiar features of robot swarms (decentralization, locality, self-organization, spatiality) already expose the programmer to a high level of complexity. Using a library can entail significant amounts of overhead we can't afford (e.g., Python with ROS) or expose the programmer to unnecessary details (e.g., memory management in C or C++, node compilation and management in ROS).
On the contrary, a DSL allows one to concentrate only on the concepts that are relevant for the domain. To make a different example, there is nothing one can do with R or Matlab that can't be done with a C/C++ library, or with SciPy. Yet, these languages exist and are used because they allow people to concentrate on the problem they want to solve, and little else. Buzz goes towards this direction.
Personally, I have 10 years of experience programming robot swarms. I have done it mainly in C++, and experienced first-hand how much useless detail goes into this activity. The motivation to design Buzz came from the need to diminish the necessary work to even get to a 'hello world' program, and the observation that students exposed to robot programming lost 90% of their time fixing a segfault or trying to make sense of ROS node management. The choice of a JavaScript-like syntax is done exactly because we want people to think 'I know exactly how this works' (principle of least surprise). Similarly, the choice of the new constructs to add (i.e., neighbors, swarm, and virtual stigmergy) were made with the explicit intention of offering a minimal set of powerful, easy-to-understand, and concise constructs. If you feel you get how to write a Buzz program in 5 minutes, then our work is a success.
There is no need for a new VM.
We developed our own toolchain (parser, assembler, VM) because we intend to study much more than just the language. For us, this is just a small step towards a wider goal - providing a full-fledged, streamlined framework for robot swarms. For instance, among the several research directions we are taking, we are currently working on modifying the byte-code generated by the compiler to allow for transparent mobile code. With an existing VM, this would be extremely complex - we would need to study the internals of the VM, hope it was designed to allow for the changes we want, and then execute the changes.
With a custom VM, instead, we have a piece of software designed in advance for the type of research we intend to pursue. All of the comments neglect the fact that Buzz is a research language, that is, a piece of software intended to conduct research. At its current stage, Buzz is a tool to explore new concepts, not a ready-to-use solution. We hope that, over time, Buzz will indeed evolve into a wide-spread language, but, at the moment, we're not there.
I would like to thank everybody for the comments. I appreciate the time you dedicated to read and criticize our work. I am open to further discussion if anybody is interested.