We have been tearing things apart in the Plumbing libraries over the past two weeks. Specifically, we’ve been separating out concerns – we keep asking “is this code architecture specific, or platform specific?” This is a hard question, as we’re trying to cleanly support multiple platforms (Arduino, Arduino Mega, Seeeduino Mega, and the ArduPilot Mega) while also supporting multiple architectures (The ATmega328 and ATmega1280).
Drew and Radu recently worked out servo control via PWM. This lets us set up servos, set their position, and then “walk away.” While it limits the number of servos we can control on a given platform, it does mean that we get robust control of the servo without a lot of work on our part.
A servo, or tiny motor.
Here’s some example code Drew committed to the repository to demonstrate usage (and test his implementation a bit).
PROC main()
CHAN SERVO s:
SEQ
digital.mode (9, OUTPUT)
PAR
heartbeat ()
servo (9, s?)
SEQ
s ! min ; 650
s ! max ; 2350
s ! div ; 4
s ! pos ; 0
s ! start
delay (2000)
WHILE TRUE
SEQ
SEQ i = 0 FOR 4
SEQ
s ! pos ; i
delay (1000)
SEQ i = 0 FOR 4 STEP -1
SEQ
s ! pos ; i
delay (1000)
:
In parallel, Drew is executing three processes. First is the hearbeat() process. This blinks the Arduino’s LED on and off, letting us know nothing has crashed. (All robots should have a heartbeat.) The second process running is the servo process, which takes two parameters: a pin and a channel. Drew has declared the channel s as being of type SERVO, which we defined as a command channel to carry messages and data to the servo process.
Then, the third process is written in-line as a sequence of steps (SEQ) followed by an infinite loop (WHILE TRUE). He starts by sending a sequence of four command messages to the servo process:
s ! min ; 650
This sends the min command with the additional value of 650 to the servo process. This means that the minimum pulse width for driving the servo should be 650 μsec.
s ! max ; 2350
This says to set the max pulse width to 2350.
s ! div ; 4
This says that we want four evenly-spaced divisions in the range (from min to max) that we just defined.
s ! pos ; 0
This sets the servo position to 0.
s ! start
This actually turns on the servo.
This process then delays for two seconds, and falls into an infinite loop. (There’s infinite loops in heartbeat() and servo()… you just can’t see them.) In this loop, Drew goes from position 0 to 4, and then back down. All he does is send the position number to the servo over the channel s.
What’s nice about this is that we can later stop the servo, update the values for the minimum and maximum, change the number of divisions (the servo process defaults to 180 divisions – in fact, all of the values have sensible defaults), and send a start message again.
Perhaps this looks complicated. Personally, I think it’s a very powerful interface to servo control, and because we encapsulated servo control in a parallel-safe process, we can easily control multiple servos at the same time, doing some cool synchronous (or asynchronous) things with our tiny little motors of goodness.
I’ll try and get some video up tomorrow. Note, also, that everything described here might change… but it certainly seems like a really nice way to do servo control.
Omer and Adam spoke at OSHUG, the Open Source Hardware Group, in London this week. Check them out talking with DJ Walker-Morgan about the concurrency.cc board.
I’m very jealous. You see, I’m in Meadville, Pennsylvania. This is a very nice town, but it isn’t London. Having lived in Canterbury for five years, I kinda miss my friends overseas, and I do miss a decent pub with good ale. Sigh
Keep an eye on the blog and our Twitter stream (http://twitter.com/concurrencycc); we’re gearing up for OSCON, and have been making some big changes. In terms of platforms, we have support for the Arduino Mega (yay!), the ArduPilot Mega (yay!), and 8MHz variants of the Arduino (untested! yay!). In terms of libraries, we have servo control sketched in, a nascent implementation of TWI (or I2C), and … one or two more goodies may make it in before “release.” I have crude Debian (.deb) and Fedora (.rpm) packages rolling, so if you’re brave, and want to give things a go, send me a note. (It stuffs a few things in /opt, so it doesn’t really require that much bravery.) We don’t have our Windows installer done yet, but that’s still on target for late July. (A lot of this is motivated right now by a student-run UAV project, hence the ArduPilot Mega.)
Awesome-awesome. I love the smell of software projects coming together…
If you keep your eyes on this blog or our Twitter stream, you’ll hear when our Windows installer is ready, and when packaging is nice and clean for both Ubuntu/Debian and Fedora.
We’re always happy to support new people exploring new languages; please feel free to join our mailing lists and ask questions. We’re here to help!
First, we’re slowly working towards making the site easier to navigate. Our main page now prominently features “Downloads” and “Community,” which should improve things.
Second, we’re still working on completing builds for all platforms – several of us are college faculty, and we’re pretty slammed this time of year. We’ll get there, though, since we want everything nice and pretty for OSCON in July.
Third, we have some nice progress on the hardware front, but I can’t speak at length about it. I will say that I need to get an order for bits and bobs on the way so that I can build some of our test boards, and once that is done we can start considering some large orders. Mostly, I want to survive the semester…
On the hardware front, though, I can safely say that the Cardboarduino was a complete success. Student after student have been finishing their board, plugging in their Atmega328p, and things Just Work. The students working with them had little to know prior experience with electronics, and we have seen success after success roll in. From the professor’s point of view, that’s wonderful.
I’ll post pictures once I have them… and, in case you were wondering: yes, the Cardboarduino is programmed using the Plumbing libraries.
No Google Summer of Code interns for concurrency.cc this year, but that did not
come as a great surprise. This years application was in large motivated by us
having talked about submitting to GSoC for a few years, but never actually
doing it. We have never really had enough time to do the application and we
have not seen ourselves as an organisation with the right profile to get
accepted. However, without submitting an application there is no chance of
getting accepted and this year we decided to just do it. We did, did not get
accepted, and now have some time to reflect on what would make us more
attractive as a mentoring organisation for GSoC in the future. Building a
bigger and more active community is probably a good start in this respect.
So, while we’re not going to get any Google Summer of Code interns this year,
that should not stop anyone from downloading the software, joining
the mailing lists, and doing awesome stuff.
