Buzz: a Novel Programming Language For Heterogeneous Robot Swarms 30
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.
Re: (Score:2)
They're reposting [quickmeme.com] in case you missed it. And if you don't have time to read it now, you can catch it when they post it again next week.
New Language? (Score:5, Insightful)
I read the story, but I don't see why this needed to be a whole new language, rather than a library.
Re: (Score:2)
Yeah, I looked at the language and there's literally nothing there that requires a new language. Everything could be done easily with a library but some programmers need an excuse to create their own language because, after all, theirs will be better somehow.
Dupe (Score:2)
5 seconds using Slashdot's own search field...
Buzz [slashdot.org]
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.
Re: (Score:2)
Back in the day, my friend wrote a simple search engine that was able to match Alta Vista's searching capability for a small website, but Google's search capability long ago surpassed what any standard website team can do.
Re: (Score:2)
Put the features in libraries, not languages, you morons.
Hand-code all library function calls in binary for best results. Who needs "languages" anyway, if your verbal output is cannot be directly executed by the computer, you should not be a developer.
Why a Language? (Score:3)
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 [wikipedia.org] or Go [wikipedia.org] 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.
Re: (Score:2)
It's rare to find functionality that doesn't fit into a set of functions (woohoo a pun!).
Lead researcher on why they're not just using Java (Score:2)
Last time this project was posted here [slashdot.org] the lead researcher on the project answered questions [slashdot.org], including addressing why they developed their own external language rather than using C/C++/Java/Python:
Re: (Score:1)
Re: (Score:2)
It actually makes it sound like they know very little about the capabilities of modern programming languages. There's no reason that a modern programming language should "get fast very complex, due to the large number of interactions among robots". And they don't define any features in their language not supported in modern programming languages.
Re: (Score:1)
It actually makes it sound like they know very little about the capabilities of modern programming languages.
"Heterogeneous Robot Swarms" and "a collections of autonomous devices" pretty much rules out "modern programming languages".
It also rules out their language.
For the prototype on the bench your ARM-processor or whatever you use is fine. But once you start to get to that heterogeneous part you are going to want to use a lot of low end devices. If battery powered you want them in the microampere range.
At that point the only portable language you can use is C. Sometimes you can use C++ if you limit yourself to
Re: (Score:2)
If battery powered you want them in the microampere range. At that point the only portable language you can use is C. Sometimes you can use C++ if you limit yourself to the subset that C covers and mostly use it for the namespacing that classes provides.
Not really. You generally switch off exceptions and avoid dynamic memory allocation, but other than that, using C++ is fine all the way down. For instance IAR supports C++ on those tiny low power 8051s which come embedded inside bluetooth low energy chips, a
What's all this (Score:2)
... about heterosexual robot swarms? Is this some weird mechanized orgiastic behavior? Is Hedonism-bot involved?
I read the paper. It didn't need to be a language. (Score:2)
Some comments on the feedback (Score:5, Informative)
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.
Leader avoidance, slackers, deserters (Score:2)
How about leader avoidance?
Maybe I want a certain number of slackers and deserters -- free thinkers -- in my swarm army.