Arduberry for Rasberry Pi



The Arduberry is an Arduino that sits on top of a Raspberry Pi. It connects to the GPIO pins. You can’t see it in the photo, but there is a MEGA328P chip mounted on the bottom of the board. Functionally it works the same as what would happen if you were to hook an Arduino Uno to a Raspberry Pi using a USB connection. By running software like Firmata on the Arduberry and appropriate libraries on the Raspberry Pi, you can send information between the Arduberry and Raspberry Pi.

So why would you want something like this? There are many shields and sensor libraries available for the Arduino family. Also the Arduino provides analog, digital, and PWM pins while the Pi only has digital pins and a single PWM pin. On the other hand, the Pi has significantly more processing power, audio input and outputs, and allows you to use programming languages that aren’t available for the Arduino. For example you could run Scratch, Java, Python, or Racket on the Pi and use it to control the Arduino.

By default the Arduberry is powered by the Raspberry Pi and since it sits on top of the Pi, it has a nice small form factor. The downside is that if you want to use the Pi to upload programs to the Arduberry, you have to be aware that it uses pins 11 and 13 to accomplish this. So if you have anything plugged into pins 11 or 13, when you try to send a new program to the Arduberry, you’ll get an error like this:

avrdude: The AVR device is not responding
avrdude: initialization failed rc=-1
Double check connections and try again, or use -F to override this check.

So for example if you try to use something like an Arduino Motor Shield that uses pin 13, you’ll have to remove it to upload a different program to the Arduberry. If you have an LED plugged into pin 13, you’ll have the same issue until you remove it.

So the Arduberry can be a good choice when the Arduino code is going to remain fairly static or you don’t need to use pins 11 and 13. If you are needing to make a lot of changes to the Arduino code and have a shield that uses pins 11 and 13, you may be better off with a normal Arduino connected with a USB cable.

Agile, Scrum, and Kanban

Agile is a set of principles for creating software. It doesn’t prescribe a specific methodology. So Agile says, “it is good to reflect on how things are going,” but doesn’t say specifically how to do it. Scrum and Kanban on the other hand are methodologies or frameworks for doing the actual work.

Scrum was created out of Agile, while Kanban comes originally from systems developed by Toyota for managing assembly lines starting back in the 1940s. Scrum is based around iterations while Kanban is based around flow. An iteration in Scrum might be a week long and start with a planning phase where the stories for the iteration are selected followed by development and end with a demo and retrospective. These iterations are typically called sprints. The idea is to get a cadence of a set of features being delivered on a regular basis–typically 1 to 4 weeks. The amount of work that can be in process at one time is limited because the number of stories committed to in an iteration is limited.

Kanban’s focus on flow is more concerned about moving stories through to completion smoothly. There are no iterations and work is limited based on the work in process limit placed on the different types of work. So the development column on a Kanban board might have a work in progress limit of 4 which means the team can’t pull another story into development until something gets pulled out of the development column. This is done to make sure that stories flow through the system and don’t get backed up in front of one resource or one type of work. The people responsible for work in one particular column pull in work from the column to their left when they have capacity. This ripples up stream as columns get an empty slot and can pull from their upstream column. In effect, one story being completed sends a signal up stream than another story can be pulled off the backlog and have work started on it.

Scrum has a Story Board with cards moving across it. Kanban has a Kanban board. Both look very similar, but the way they are used is very different. In Scrum the Story Board is a visual representation of what is being worked on where. In Kanban it is a visual representation, but also a control mechanism to manage the flow of the work. It controls how fast work is released from the backlog. In Kanban, it would be common to create another column to start gathering metrics whenever the team finds some type of impediment. That wouldn’t normally happen with a Scrum Story Board.

For an analogy of the differences between Scrum iterations and Kanban’s flow, you might think of Scrum as being similar to carrying a bucket of water between two points. The water represents work and the bucket represents the iteration. In Scrum you take the bucket to the destination and then talk about how you could do it better, then go back and do it again. Maybe this time you use a slightly different sized bucket, etc. Kanban is more like a gutter running between two points. You pay close attention to any areas that start backing up the water and make sure you don’t pour more water in than is coming out the other end to make sure it doesn’t build up and spill at a curve.

The team I’m currently working with is using Kanban so we have continuous flow for the development. However, we still use iterations for things that can benefit from a cadence–most notably the demos and retrospectives. We also continue to have daily standup meetings. So basically what we’ve done is removed the iteration based work from scrum and replaced it with the continuous flow of Kanban while still keeping the other parts of Scrum.

I’ve heard some people refer to this as Scrum-ban. I’m hesitant to use that term because it sounds silly to me…but I suppose no more silly than Scrum or Kanban.