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'm entirely sure this was posted a week ago.
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.
Already discussed here:
http://developers.slashdot.org/story/15/07/23/1422215/a-programming-language-for-self-organizing-swarms-of-drones
For example: .... ...
"We should create a whole OS that controls Drone Swarms
We'll call it
BeeOS! "
Put the features in libraries, not languages, you morons.
How many autonomous Slashdot articles about this language make a swarm?
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.
Last time this project was posted here the lead researcher on the project answered questions, including addressing why they developed their own external language rather than using C/C++/Java/Python:
And also, another reason:
Building Better Software
This doesn't answer the question at all. The intent of the question is: why won't a language extension or library do? This answer suggests they never even considered the option.
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.
I'll never forget the last thing grandma said to me before she died: "What are you doing in here with that knife?!?"
... about heterosexual robot swarms? Is this some weird mechanized orgiastic behavior? Is Hedonism-bot involved?
#DeleteChrome
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.
If they are determined to create constructs that allow for high levels of abstractions, they should have chosen to use Scala, which has great DSL support. Scala already supports actors and message passing, so extending the existing libraries to support swarms of concurrent executors (i.e. the robots) should be easy and save a lot of time.
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 the subset that C covers and mostly use it for the namespacing that classes provides.
Dynamic memory allocation and garbage collection on a device with 4k ram? It will turn ugly pretty quick.
They should have done a library for C.
It used to be "holy sh* we need a new DBMS for this!", now it is "crazy cow, we need a new language to make this work!". It's a fad thing. They wanted their own language. Generates more hype than just a new library. To some people creating a new language still seems like awesome, whereas every dude can create their own library.
Besides, having looked at the language, it doesn't actually make any sense at all. It is a mixture of Lua, Python and Javascript, and all the "abstractions" they suggest required a new language are essentially a few objects (swarm, neighbours, stigmergy). All they would have had to do in Python was to add `from buzz import swarm, neighbours, stigmergy` and they'd have the same programming experience. Only better. Minus all the overhead of creating your own language and the feature creep that eventually goes with it.
IMHO it's just a bad decision. Sorry guys.
The whole thing actually makes it sound like they know very little about anything they so enthusiastically talk about.
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.
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, and gcc supports it much better on Atmel 8 bitters.
You still get constructors and destructors to keep your invariants invariant. You still get a surprisingly large chunk of the standard library (less in C++11). Everything in algoithm and utility works. The container adapters still work. Even the containers work if you provide a custom allocator which draws from a fixed sized pool.
SJW n. One who posts facts.
'Novel', the most abused word in academic publishing.
How about leader avoidance?
Maybe I want a certain number of slackers and deserters -- free thinkers -- in my swarm army.
-kgj