The concurrency.cc Blog

Semester Coming to an End

Chad Peruggia, Renaldo Pierre-Louis — Wed, 28 Nov 2012 00:00:00 -0800

Concluding the Semester

This semester has been full of headaches and annoyances, but after much head banging and hard work we were able to accomplish minor goals. Although we didn’t accomplish everything we had wanted to, we feel that the progress we made was significant for the time we had. We took pre exsisting python code, rewrote it into ruby follwing OOD, organized it, heavily commented it, as well as fixed the fishtailing issue that taking place with the old code.

With the progress we made obtaining level flight without the dolphin kicks that were previously present, the next step of GPS waypoints is obtainable and the code can be transfered safely to occam-pi and placed on a physical device. We feel that these are the next logical steps for the project.

Goals

We have a week left of class, and we would like to try and tie in our heading into our pitch so it can turn as well as change altitude at the same time. If we can accomplish this, the plane will behave as a “real” plane flies. We are unsure if we can accomplish these goals with such a short period of time, but its worth a try.

Did You know?

There is now a robot, called the HyTAQ hybrid that can travel by air and land! Its pretty cool.

Please look here to see the video and article.

http://www.engadget.com/2012/11/28/hytaq-hybrid-quadrotor-robot-travels-by-air-and-land/

Success ? Maybe so!

Chad Peruggia , Renaldo Pierre-Louis — Mon, 19 Nov 2012 00:00:00 -0800

Updates

So after our meeting with Dr. Jadud, we found that we needed to incorporate a rate of climb to control our pitch. Today we started on trying to implement this, and we feel that we have succeeded! Our plane is able to obtain our desired alititude (+-25 ft). This is a major breakthrough for us because we haven’t been able to obtain such success yet. We were able to test decreasing and increasing altitude and all worked as desired. Although it does go down a bit fast, it doesn’t fall out of control, and everything went well.

Whats next?

Our next goal is to fine tune our controls a bit more, and then try to implement GPS. Although we only have 2 weeks of class left we are setting high goals to motivate ourselves, I mean who else would go to class till midnight on their own?

Did You know?

Thanksgiving fact! Why is it always on the last Thursday of November?

Abraham Lincoln issued a ‘Thanksgiving Proclamation’ on third October 1863 and officially set aside the last Thursday of November as the national day for Thanksgiving.

Analyzing the ArduPilot

Renaldo Pierre- Louis , Chad Peruggia — Mon, 12 Nov 2012 00:00:00 -0800

Update

We have decided to go through our code and compare it to one that is known to work, the ArduPilot. Since we have known issues with our pitch controller, we decided to look there. At first we were confused, as this is a rather large program with many files, and we had to figure out where variables were coming from and where they were being set. We had to understand the parameters of the functions before we can figure out how the functions work.

About an hour later, we feel like we have a good understanding of how they work and where we went wrong.

Our Errors

Currently our Pitch PID is not using the constraints to properly set which is what is causing our plane to stall when changing altitudes. We have come to the realization that our PID is returning the value that is similar to the contrain value mentioned in the psudocode above. If we send the values that we are currenlty obtaining to a PID, we might be able to achive our desired outcome.

The biggest difference between our approach and the approach of the Ardui Piolot is the use of a timing method. We need to figure out how to implement this into our Ruby scripts.

Once we cal the Pitch PID and the throttle PID, we can send these commands to the plane and it should fly as desired…. hopefully.

Did You Know

That we didn’t physically meet for class today? But we used teamViewer to have a video meeting and shared our desktop!! HOW AWESOME!

Rewrite Completed (Sort of)

Renaldo Pierre- Louis , Chad Peruggia — Wed, 31 Oct 2012 00:00:00 -0700

Updates

We have finished our rewrite of the old python control to our ruby class model. Everything seems to work, but there is something wrong with our Pitch controller. We can’t seem to figure it out. Our plane flies and doesn’t crash, but it doesn’t change altitude as we desire. The plane cannot descend, it simply falls when we try to do this, but when it needs to go back up, it works as desired. We have a bug in our algorithm, and we need to fix it.

SMALL VICTORY!

Although it might not seem like much, this was a pretty large step forward for us, and we are proud of our progress so far. We wish we could’ve gotten more done at this point, but we are moving at a good pace, and hopefully we can start to get our GPS working before Thanksgiving break.

Did You Know?

That the pitch levels are reverse of what you would think? A positive pitch means the plane is going down, and a negative pitch means the plane will ascend.

Python to Ruby Continued

Renaldo Pierre-Louis, Chad Peruggia — Mon, 29 Oct 2012 00:00:00 -0700

Current Progress

We have continued our desire to rewrite past code from python to ruby, and we have the PID fully rewritten, as well as a class written for the controls of the plane. We did make slight changes to the structure of the code, as well as a plan to fix the elevation change.

New Elevation Controller

We are planning to change the elevation of the plane by using a proportional control method. The method itself will take the current altitude from the desired altitude, and we convert it to a number that we can use to adjust the pitch. We refer to this value as the desired pitch. We have a max pitch to prevent the plane from going out of control, and this value is used in the pitch PID.

We feel that this will give the plane a more realistic and faster accent / decent to desired altitudes.

Complications

We ran into a small error when converting the Python to Ruby due to syntax differences. We were missing and end statement, and we couldn’t figure out why. This was causing errors with our class functions when we tried to call them , since the methods were being created in an If / Else statement. Once we found this error, which took forever, it was smooth sailing to get the code to run.

Whats Next

In order to finish in time, we figured we need to meet more during the semester since we need access to the simulator. We are discussing these plans, and something will be worked out soon.

Our next step in our development plan is to finish getting the ruby working, then we plan to try and implement the GPS, but we are unsure due to time constraints.

Did You Know?

We don’t have anything, since we don’t know anything either to share!

Setting the Pitch

Chad Peruggia , Renaldo Pierre-Louis — Wed, 24 Oct 2012 00:00:00 -0700

Discoveries

Previous PID Issues

So, we previously explained that the current autopilot code would “fish-tail” its way up to the desired altitude. Today, we believed that we found out why it was behaving in such ways. Initially, we researched and brainstormed to gain a better understanding how this PID thing really worked. After reading a couple of papers and discussing them, we arrived to the understanding that what we needed to control was the Constant multipliers in the PID controllers.

Consequently we altered values being passed to the PID class to see the effect it would have on the flight. Miraculously, decreasing the P constant from 0.38 to 0.15 resulted in the plane making a smoother change in altitude (no fish-tailing). Yay!!!

However, upon further discussion, we came to the conclusion that this was not enough and could be done more efficiently. The plane was taking an eternity to climb the desired altitude since the pitch was only being adjusted by really small values.

The behavior that we would like is to have a steep ascent or descent that would decrease as we approach the desired value. So, we investigated more.

Pitch and Altitude

Since pitch and altitude are directly related, we believe it to be a great idea if the code reflects this. At the moment, it does not.

Plans

We plan to try and use the pitch to figure out the angle of which the plane is ascending / descending, and compute the change in vertical distance based on the velocity of the plane. We will then be able to adjust the pitch accordingly as time changes to obtain the desired altitude. We feel that if we eliminate the PID in regards to Pitch and altitude, and use simple math, we will have more control over how the plane is reacting to the changes. The black box method here does not seem to be ideal.

Did You Know?

That in a PID controller, the D, or the derivative responds poorly to noise in the data and can effect the controller greatly. That is why many PID’s don’t use the D, they are simply referred to as PI’s.

Renaldo likes pizza.

Ruby Rewrite PID

Renaldo Pierre-Louis, Chad Peruggia — Mon, 22 Oct 2012 00:00:00 -0700

Rewriting is FUN!

We have continued our progress into rewriting the old python scripts into ruby following our object model. We have started to try and decipher the PID controller and how it is interacting with the data from the simulator, some of it makes sense, parts of it don’t, mostly what a set_point is. We can’t seem to figure out what this is, or what its purpose is, or why it is always 0 to start.

Due to this, we decided to give ourselves homework, yes you read that correct. We are going to do some more research into PID’s and how they work, then we will attempt to plan out our PID regarding the plane’s heading. This should give us a head start into our class time on Wednesday.

Challenges

As previously stated, we can’t figure out what the set_point is or its purpose. This is a small challenge, but it is important that we understand all aspects of these controls before we move forward with our plans. Once we grasp PID’s and how they work, we should make steady progress. We plan to overcome these challenges via homework and personal research.

Did You Know?

That self is needed in python and not ruby! This might not seem like much, but saving all that time from that four letter word can add up to minutes!

For example:

Ruby:

class myClass
    def myFunc(name)
        @name = name
    end
end

Python:

class myClass:
    def myFunc(self, name):
        self.name = name

For more information read here

Ruby Re-Write

Chad Peruggia , Renaldo Pierre-Louis — Mon, 15 Oct 2012 00:00:00 -0700

We have decided to re-write the old code regarding auto-pilot in Ruby. Today was our first day actually coding in regards to this project, so it felt nice to see that we are moving forward with our goals. We decided to re-write the old code so we can have a better understanding of how it worked, and then address the issue of the dolphin tailing when changing altitude.

Current Progress

We have written the code so far in OOD, where prior it was done functionally. We feel that this will give us, as well as future extensions of the project a more maintainable code base, which is ideal for research projects.

We have the Ruby code working with a UDP socket class, then creating a class of ControlPanel, which allows us to separate the data coming out of the simulator into useable member variables which we plan to use later on in development. Even though this is a small step, it is a step in the right direction.

Complications

We have yet to begin our research into PID’s as well as the previous algorithm in the autopilot.py. We feel that we will be able to overcome these challenges within a reasonable time frame and hope to fix the dolphin tail issue well before Thanksgiving break.

Did You Know?

That the UDP set up is very similar in Ruby as well as Python. Also, Ruby did a lot of the work for us when we needed to split the string of data, as well as the accessor functions can be written with little code compared to other, more complex languages. This was a relief.

Workstation, Finally!

Renaldo Pierre-Louis , Chad Peruggia — Wed, 10 Oct 2012 00:00:00 -0700

So, after a slight delay in our class, we have finally been able to get Dr. Jadud to set up the iMac workstation. We couldn’t be more ecstatic!

In our class tonight, we sat down with Dr. Jadud to go over some basics regarding UDP port setup as well as running python scripts with the simulator. We found this brief session very helpful.

Dr. Jadud demonstrated the auto-pilot script which was written by as previous student of his, and we have found an area where we can start improving it. Currently, the auto-pilot’s flight leveling system behaves in a strange way, where it seems to dolphin tail to maintain a level flight rather then just remain constant. This area is where we plan to make our first improvements on past work, as it will be the gateway, and a necessary fix before we can implement our plans for GPS waypoint navigation.

We went over some information regarding PID controllers, what they were and how they work. There needs to be further research done regarding the controllers so we can have a better understanding on how they work and how to implement them in our future scripts.

After further discussion, we are considering working in either Python or Ruby. It will be decided at a later date.

Did you know?

It takes 341 licks to reach the center of a tootsie pop? AMAZING! I am kidding, that was a little easter egg for our readers.

Setting up a UDP port is similar in almost every language. We saw two examples today and they were almost identical in syntax and complexity. This gives us hope that regardless of what language we decide to use, the complexity will be on par with other languages.

Flight Simulator Setup

Chad Peruggia , Renaldo Pierre-Louis — Wed, 19 Sep 2012 00:00:00 -0700

After our meeting with Dr. Jadud and Dr. Pearce to go over our semester goals, we decided that setting up our simulation environment was the next step required for progress. Dr. Jadud informed us of FlightGear, a sophisticated, professional, open-source flight simulator. So, we decided to give it a try. The plan was to figure out how to fly a plane, and receive flight data via UDP. This did not happen.

Challenges

Due to the slow wireless network connection on campus, the downloading and installation took longer than expected. But we overcame this challenge by bringing out the ethernet cable. The program was an easy installation once downloaded. However, running it was a different issue.

We have two different laptops (4gb of ram, dual core), and one of them could not run it at all (Dell Latitude E5410) - graphics card not powerful enough, the other(Latitude E6400) could barely run it - it would freeze shortly after.

Still, we managed to get the plan in the air for a few seconds (before crashing or computer being frozen).

Solutions

We are planning on getting a Mac workstation, which should be more than enough to run this software and anything else that we will need to run. So, those issues of not having powerful enough hardware will not be repeated. Hopefully, we will have that set up by next week so we can begin learning the simulator and transferring flight data via UDP.

Planning & The Transterpreter

Chad Peruggia , Renaldo Pierre-Louis — Mon, 17 Sep 2012 00:00:00 -0700

Today, class did not proceed as planned from last class period. We had planned on working with the Arduinos, unfortunately, some guy name Matt Jadud locked the Arduinos in his office. Consequently, today consisted of redefining the direction we want this course to go in. We have have decided that we should:

Have a simulation environment set up that can occam runtime. We figured this is essential to any future progress so we can test code rather than just throwing it on a plane and praying for the best.
Once we get the simulation set up and working, we would like to have a plane to fly, even if it means using the kit so we can see some code in life rather than just a simulation.

The remaining time was spent reading about the background of the Tranterpreter and about its structure and performance. Of course, writing this blog post was also part of the class. :p

The Transterperter

From our understanding of the reading, we were able to see that the Transterpeter still has room for improvement in speeds, but it provides a substantial boost in speed (10%) when running PAR. Based on our understanding of what we will be using occam-pi and the Transterperter for, this is essential. Due to us being limited in our hardware, we need to be able to have programs that have small footprints, and yet can be run at high speeds in PAR.

Did You Know

Using Occam and the Transterpreter is an excellent choice for introductory robotics programming in LEGO MindStorms Kit because:

It is a better introduction to programming than Robolab
The syntax is easy to understand
It runs smoothly on the hardware

Occam Pi Basics

Chad Peruggia , Renaldo Pierre-Louis — Mon, 10 Sep 2012 00:00:00 -0700

So, today we started with the basics of Occam-pi - the parallel processing language that we will be using to automate our “Flying Mountaineer.” We first downloaded the IDE and uploaded the “Transterpreter” to enables us to run Occam-pi on the Arduino. The Transterpreter actually just provides an illusion of parallel processing, since the Arduino only has a single processor. This illusion is called “concurrency” (hint: the name of the blog :D).

Trying Occam-pi

We decided to try by making three LEDs blink in parallel (concurrently to be more accurate). This is a trivial task that does not really test our programming skills, but more our abilities in circuitry. It was a nice refresher of how to build parallel and series circuits.

See this cool video below.

Did You Know

The onboard LED is actually the same as pin 13. We found this out when we were blinking our LED on pin 13, and realized the onboard LED was also blinking, and we were not sure why, since we did not intend for it to. So, if you are wondering why you onboard LED blinks when you did not want it to, this is probably the reason.

Contemplating Flying

Chad Peruggia , Renaldo Pierre-Louis — Wed, 05 Sep 2012 00:00:00 -0700

So, after being presented with the idea of taking an Advanced Robotics, we decided to accept the challenge and see what innovations we could make to Dr. Jadud’s and his previous students “Flying Gator” project. We are going to be branching off this project and now code naming it the “Flying Mountaineer”, how original.

We have read the paper on the past work, and we have a good understanding of what was done with the project, and where we plan to take it by semesters end.

Past Work

Dr.Jadud and his students managed to get a plane in the air, controlling linear flight by reading sensors. The plane was able to maintain flight, which is a huge step in the progress, but what they didn’t have time to do was enable GPS waypoint navigation and ground radio communication. These are the two features that we plan to concentrate on throughout the semester.

Reading into the way that they made the plane fly, we learned the about the type of hardware they were using, an ATmega1280, and software written in occam-pi. They used a series of loops rather than the single loop in the open source program ArduPilot control system, which enabled them to have many process running at the same time.

This method of control allowed them to keep the plane leveled by reading in sensor data at the same controlling motor speed during turns. Sensor data that was important to the flight of the plane was from the Gyroscope as well as the Accelerometer. They combined the data from the two sensors to maintain a level flight. Past Work

First Steps

We plan on learning how to interact with the Arduino micro-controller before moving forward with the project. We need to have an understanding of the hardware and its limitations so we can devise a well planned design and approach to planned innovations.

Did You Know

In our first session of Arduino Learning, we managed to alter the “Fade” demo, to include a blink to the LED. Once the light would fade on, we would blink off, blink on, then fade out. Although this is simple, we had trouble figuring out where to place the code as we aren’t used to programming in a loop type structure that the Arduino uses.

Here is a code snippet of how we got it to work.

/*
Fade

 This example shows how to fade an LED on pin 9
using the analogWrite() function.

 This example code is in the public domain.
*/

int led = 9;           // the pin that the LED is attached to
int brightness = 0;    // how bright the LED is
int fadeAmount = 5;    // how many points to fade the LED by

// the setup routine runs once when you press reset:
void setup()  { 
  // declare pin 9 to be an output:
  pinMode(led, OUTPUT);
} 

// the loop routine runs over and over again forever:
void loop()  { 
  // set the brightness of pin 9:
  analogWrite(led, brightness);    

  // change the brightness for next time through the loop:
  brightness = brightness + fadeAmount;
  
  if (brightness == 255){
    analogWrite(led, LOW);
    delay(500);
    analogWrite(led, HIGH);
  }
  
  // reverse the direction of the fading at the ends of the fade: 
  if (brightness == 0 || brightness == 255) {
    fadeAmount = -fadeAmount ; 
  }     
  // wait for 30 milliseconds to see the dimming effect    
  delay(30);  
}

CCC Hackathon: occam-pi on the Raspberry Pi

Christian Jacobsen, Omer Kilic and Jon Simpson — Tue, 12 Jun 2012 00:00:00 -0700

So, after a long time with nothing here goes…

It seemed inevitable to us after reading about the Raspberry Pi that it and occam-pi had to be brought together, and as fate would have it several of us were able to get together in London and hack for a few days on the project in general, and the Raspberry Pi in particular during the Jubilee 4 day weekend.

Website

After a long hiatus in posting to or updating the website, we’ve finally made the move to Github Pages. We’re really excited about this, as it means we’ll eventually have a single, straightforward way to contribute either code or documentation to the project (more on this below). This also means that the code is open to all – see the project page for the gory details. Stay tuned for more website and documentation updates - pull requests welcome!

Git Repository

Another less glamorous activity which received attention at the hackathon is a move of the KRoC repository to Git to facilitate a move of the project sources to Github. We’re keen to reduce any barriers to entry for new contributors, and Github has built up a fantastic set of infrastructure and processes to aid projects. Unfortunately, there are some difficulties in conversion particular to the KRoC repositories, which have absorbed a lot of effort so far (gory details follow below).

The KRoC Subversion repository started out containing sub-projects for each of the individual components (such as occ21, ilibr, etc; as can be seen in early revisions of the repository), and at some point in the history these were (almost) all moved in under one project (as can be seen in the current trunk).

A simple svn2git import fails to keep the history before the different sub-projects were consolidated into the kroc project. There are some recipes for importing complex repositories available (Simeon Pilgrim and Graham Knop have both written some lengthy blog posts on the subject) but it looks like it could be a pretty time consuming activity to ensure that the full history of the KRoC repository is available. Once we figure out whether it is worth trying to keep the full history or leave the sub-projects history out (and refer to the original Subversion repository) then the repository will appear on Github as one of the Concurrency organisation’s repositories and will be available for general cloning.

Raspberry Pi

The Raspberry Pi is a Linux computer (just a very small one) so compiling the tools was a reasonably straightforward task. We left it compiling for some time while we sampled a few different beers and when we got back we had a full toolchain built and ready for use. Unlike some platforms (like Arduino), our port to the Raspberry Pi is ‘self-hosted’, in other words, we can compile and run occam-pi code on the Raspberry Pi directly (in fact, this has been our preferred way of working with it so far, over SSH)

Being an embedded platform, interfacing with hardware peripherals on the board is quite important. There are abstractions we can use, such as the GPIO modules contained in the kernel (that we use for the current version of the digital.module) but having a unified way of setting up/using these peripherals seems like a better way in the long run so we will look into ways we can remove some of these abstractions and do things directly from within the occam-pi modules. This is very much a work in progress though, so keep an eye out for latest updates.

Here are some obligatory concurrent blinkenlights for your viewing pleasure:

occam-pi Blinkenlights on the Raspberry Pi from clj on Vimeo.

We don’t actually have stuff where they should be with the impending repository move on the horizon so drop an email to our developers’ list if you’d like to learn more.

It’s something of a tradition to run a simple occam-pi program called commstime.occ on any new port, which does nothing particularly useful other than calculate context switch times. For posterity, we’ll report those numbers here:

Sequential delta? yes
Last value received = 1000015
Time = 10686591 microsecs
Time per loop = 10686 nanosecs
Context switch = 2671 nanosecs

In conclusion the hackathon has been a great success – much (awesome) beer drunk, port completed, website ported and blinkenlights err… blinked. If you’re interested in getting involved at the (inevitable) next one, or with the project in general the best place to start is sending a mail to developers list and introducing yourself.

Arduino Uno Support!!!

Christian Jacobsen — Thu, 04 Nov 2010 00:00:00 -0700

After having had an Arduino Uno sitting on my desk happily accepting programs from my development build of the Transterpreter, I thought it was finally time to get the binaries with Arduino Uno released into the wild.

Knight Rider on the Arduino Uno - concurrency.cc from clj on Vimeo.

Quick demo showing a concurrent program running on the Arduino Uno doin’ Knight Rider like awesomeness…

The reason that getting the binaries out took so long is that various other bits have gotten in the way. Changes were required to be able to build 32 bit versions of the tools on Snow Leopard; the website has moved to a new host; the Sparkle feed infrastructure (for the Mac) has been updated to include a changelog; and building software on Windows is just never fun.

But now the Arduino Uno support is finally here. Mac OS X and Windows versions should update themselves, otherwise you can download the packages from the download page. The Ubuntu packages have not yet been updated, but this should happen at some point in the future (pester Matt about this). Any problems with the packages should be reported on one of the mailing lists.

Arduino Uno support is available starting with these versions of the Transterpreter:

Mac OS X 20101103.1423 (dev)
Windows 20101104.0001 (dev)

Ubuntu packages ready for testing

Matt Jadud — Sun, 18 Jul 2010 00:00:00 -0700

I can’t say that they’re perfect, nor can I say that they would make it into the Ubuntu repository. I made these packages, and by “made” I mean “hammered them out of a block of granite until they were so many tiny little shards of granite all over the place.” They are not art, they are not to be admired.

But, they do seem to work on the one virtual machine that I have tested them on over and over. And, so far, I haven’t removed anything from my system or left it in an inoperable state. Yet.

To use this thing of beauty

Under Ubuntu, you should be able to install our package and have all requirements automatically installed. Java, some tools for Arduino programming, and a number of other packages end up being installed. To get started, you need to add our dev repository to your apt sources:

sudo vim /etc/apt/sources.list

(Feel free to use your editor of choice.) Next, you need to add our repository. This depends on your version of Ubuntu; you can find out what to use by running the following:

uname -a

~~Lucid Lynx (10.04), amd64~~
~~This is a 64-bit version of the most recent Ubuntu. Add this line:~~
deb http://download.transterpreter.org/files/dev/ubuntu/lucid/amd64 binary/
64-bit packages will be updated after OSCON.
Lucid Lynx (10.04), i386/686
This is a 32-bit version of the most recent Ubuntu. Add this line:
deb http://download.transterpreter.org/files/dev/ubuntu/lucid/i386 binary/
Jaunty Jackalope (9.04), i386/686
This is a 32-bit version of the last version of Ubuntu. Add this line:
deb http://download.transterpreter.org/files/dev/ubuntu/jaunty/i386 binary/

After you add that to your sources.list, you should be able to run:

sudo apt-get update

You can install our meta-package, which will pull in several more:

sudo apt-get install occam-pi

This pulls in packages for a native version of occam-pi, a version running on our virtual machine (called the Transterpreter), a version for the Arduino, and a plug-in for jEdit that we call occPlug. they are all prefixed with the name occam-pi, so they are easy to find if you want to get rid of them.

Note: We will, someday, be updating these packages, or even (hopefully) getting source packages into the Ubuntu repositories. When that happens, the repository you just added will need to be removed. But, we don’t expect that to happen before the new year, so rest easy.

Using occam-pi

On the command-line, type:

jedit

Now, go to the Plugins menu, find occPlug, and say Start occPlug. After it opens up, close jEdit.

After you have started the occPlug, and closed jEdit, go ahead and open it again and continue. (The first time you run the occPlug, it does some configuration that we shouldn’t do in the package.)

At this point, you can start exploring the book… but, note, it needs some updating. That’s next on the list as we finish getting ready for OSCON. In the meantime, you can look at the examples in our OSCON examples directory, which all work against the newest versions of Plumbing.

Let us know how you get on on the users mailing list; your feedback is very welcome.

Driving a servo with Plumbing

Matt Jadud — Thu, 08 Jul 2010 00:00:00 -0700

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 talk about the ccc board

Matt Jadud — Fri, 02 Jul 2010 00:00:00 -0700

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.

Adam Sampson and Omer Kilic talking with Dj Walker-Morgan after #oshug from Matt Lucht on Vimeo.

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 I²C), 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…

Slashdot!

Matt Jadud — Wed, 16 Jun 2010 00:00:00 -0700

We got picked up by Slashdot today. Wootness.

We’re currently in a fast-and-furious hack mode leading up to OSCON. If you’re interested in trying out our tools, you can grab our book and download a Mac version of our development environment (friendly-friendly), build from source under Linux, or (if you want to live dangerously), join our users list, introduce yourself, and ask nicely if you can try (the currently very ghetto) Debian binary package.

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!

Web updates, c.cc hardware, and the Cardboarduino!

Matt Jadud — Sat, 24 Apr 2010 00:00:00 -0700

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

Christian Jacobsen — Thu, 18 Mar 2010 00:00:00 -0700

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.

Congrats to all the organisations that did get accepted.

Mailing list and archives fixed

Matt Jadud — Thu, 18 Mar 2010 00:00:00 -0700

For a long time, there weren’t many “new” people working with our tools. Therefore, our lists lived behind an https:// address with a self-signed certificate. This caused problems for many people. If nothing else, it threw big scary warnings claiming Bad Things were about to happen.

I’ve moved things around. Our lists are now completely open.

Our list for users of process-oriented programming (things like Plumbing, or JCSP, etc.) is users@concurrency.cc.
Our list for developers working on these kinds of tools (contributing to Plumbing, etc.) is developers@concurrency.cc.

You can join either list from our mailing lists page. Please join in the fun. I’ll try and get another post up over break about things that are going on with the team. (Also, we’ll know whether we’re a GSoC participant!)

Google Summer of Code

Christian Jacobsen — Sat, 13 Mar 2010 00:00:00 -0800

Yesterday we submitted an application for the 2010 Google Summer of Code. You can find our application and ideas right on this site. We won’t know if we have been accepted as an institution until the 18th of March, but if you are interested in doing a Google Summer of Code project with us it is probably worth contacting us about it now. Even if we don’t get accepted as a mentoring institution, we would of course still be more than happy for anyone to come and join the project and do cool stuff!

If you want to get in touch with us about Google Summer of Code and projects, join the developers list and drop us a note.

Around the WWW

Matt Jadud — Sun, 07 Mar 2010 00:00:00 -0800

This is the first of a series of posts where we point to things we’ve found on the WWW, and do our best to address some questions/share some thoughts about our tools.

To answer the question that we’ve received several times and seen in a number of places, Windows is coming.

The St. Louis Area Robotics Group

A few weeks back, a thread was started on the St. Louis Area Robotics Group forums regarding our libraries and the Arduino/robotics.

The original poster (gifted) pointed out that while the native Arduino programming environment provides threading via protothreads, it doesn’t necessarily make it easier to handle multiple events taking place simultaneously. This past week, I had students working on a challenge involving three LEDs fading in and out on three PWM channels; as each finished its fade cycle, it would “ask” for a new reading from an ADC channel. I encourage students working with dataflow languages like occam to first draw a picture of their program:

We call this a “dataflow” language because the entire basis for programming in occam is one where we are communicating data from one parallel process to another. Hence, it is useful to think of values “flowing” from one process to the next. I’ll break things down fully here:

Step 1

The fader process gets done bringing it’s specific LED (in this case, the LED on pin 11) to full brightness and back. At this point, it wants a new reading from the ADC to determine how fast or slow it should fade. So, fader signals the switch process that a new reading is desired. (So you know, the fader process does not know who is listening—it just knows that it wants a new reading, so it sends out a SIGNAL.)

Step 2

The switch process grabs the SIGNAL and then signals the adc process that a new reading is desired. From the point of view of adc, it has been sitting quietly doing nothing, simply waiting for someone to ask for some data.

Step 3

The adc takes a reading from pin 0.

Step 4

The adc process communicates its reading down the adcResp channel, and proceeds to begin waiting again.

Step 5

The switch process takes the value it received from adc (it was waiting), and sends that on to the fader process (who is also waiting).

There is a 1:1 correspondence between this diagram and the code we write. If you want to see an implementation of this tri-LED fader, you can see it in our repository. I’ll eventually write this up as a sequence of short chapters in the book, but I simply haven’t had time yet. (And, actually, that code needs some comments. I use replicated syntaxes to keep it short, but those should probably be explained.)

Plumbing is for concurrency

So, yes… we think this is good for robotics, because a lot of robotic control is about reading from and reacting to sensors. We <3 the Arduino because it is a low-cost microcontroller that lots of people use for exactly these kinds of applications—but we think it’s too difficult to manage this kind of complexity in C, especially for programmers just starting point.

And, for tmaiden on the St. Louis robotics forums: we use the word parallelism to denote when things happen “at the same time,” and use the word “concurrency” to mean “the appearance of simultaneity.” I don’t know if others make this distinction, but we do… because when we use our tools on multicore devices, we get parallelism. When the Arduino goes multicore, our domain will be technically incorrect, and we’ll have to go get parallelism.cc.

And those .cc domains are expensive.

Did I write that?

Matt Jadud — Sun, 14 Feb 2010 00:00:00 -0800

Meredeth Patterson (maradydd)¹ commented on the preface to “Plumbing for the Arduino”:

This is how you write an introduction that makes people care about what your project does. This is how you take a specialty solution, heretofore useful to and understandable by only people who already understood process algebra and the pi-calculus, and present it as another tool for people’s toolboxes right alongside hammers and screwdrivers. If you want to drive a nail, get a hammer; if you want to do parallel tasks in real-time, get occam-π.

The hard thing about giving your work away is not knowing whether it has value. I know there are bugs in the book (Zoro Feigl already found one…), and I know it can be improved. That’s the nice thing about getting it out there for people to use—they can push back, and we can improve our software and our text.

And that really makes me feel good.

There’s a few other people who found our project in the past week or so and started exploring it. I’ll point to those over the next couple of days. The early adopters—people exploring something new—really are exciting to work with. You can see learning taking place as well as more work piling up, because you now know you’ve got more things to improve and more documentation to write. (I happen to think that’s a good thing.)

You have to pronounce “maradydd” in the Welsh.
↩

Mailing lists and updates

Matt Jadud — Fri, 12 Feb 2010 00:00:00 -0800

Tap tap

I have no idea if this blog is read by anyone, but hopefully you put our RSS feed in your reader if you were interested in news and updates.

Twitter

We created a dedicated Twitter feed for the site. You can follow concurrencycc for updates. For example, when the book updates, or the blog, we’ll write a short note. All signal, no noise. I hope. I’m not a Twitter expert.

Mailing Lists

We have two new mailing lists:

users@concurrency.cc
developers@concurrency.cc

You can join either or both of these lists using the details on our mailing lists page. (Or, if you want, drop matt at concurrency dot cc an email.)

These are not strictly limited to people exploring occam on the Arduino. Our long-term goal is that people exploring process-oriented programming find a home for their projects under this domain. If you start exploring Plumbing and have questions, that is a great place to ask. Everyone involved in the creation of Plumbing (and, for that matter, everyone working on occam-π) can be found there.

If you’re interested in contributing to the Plumbing libraries (or, the virtual machine underneath it), or you want to help bring occam to another hardware platform, join developers@concurrency.cc. That is the space where we discuss the tools that make things like Plumbing possible. Again, we’re all there.

Book Updated

Two (three?) new chapters appeared last weekend. Also, Zoro (who seems to do some very cool art) dropped an important note to bookbugs.

Every program you write for the Arduino that uses Plumbing needs to start with this line:

#INCLUDE "plumbing.module"

This line of code brings in all of the support you need to program the Arduino in occam. Our intention is that the tools you use for programming the Arduino will ultimately insert that line automatically. (Or, perhaps we’ll change our minds about that.) Either way, I’ve updated the first chapter so that it is included there. I am not going to update all of the code examples in the book at this time, simply because that will 1. take longer and 2. upset my pagination. Also, the group needs to discuss (on developers) whether we’re going to make that line go away or not.

Summary

We have a new Twitter feed, new mailing lists, and updates to the book (now on revision 2010-02-12). Enjoy!

The website goes live

Matt Jadud — Sun, 31 Jan 2010 00:00:00 -0800

While we’ve had concurrency.cc for a while, we haven’t actually loaded content into the site.

Now, we have links to the book we’ve started, hardware developed by members of the group, a blog (including Atom and RSS feeds), and… who knows what else!