Lead and Follow (or, making low-cost robots dance), Part 2

In part 1, I introduced my Edison robots, and my plans to get one of them to lead the other one in a choreographed dance. Now read on… As I was saying, the key to solving this problem is getting the one of the robots to reliably send multiple-byte sequences to the other, which I’ve made responsibility of two methods: sendReliably() and readReliably(). How do we go about doing this?
Read full post gblog_arrow_right

Lead and Follow (or, making low-cost robots dance), Part 1

In some types of partner dance, lead and follow are designations for the two dancers comprising a dance couple. […] The Lead is responsible for guiding the couple and initiating transitions to different dance steps and, in improvised dances, for choosing the dance steps to perform. The Lead communicates choices to the Follow and directs the Follow by means of subtle physical and visual signals, thereby allowing the couple to be smoothly coordinated.

“Lead and Follow”, Wikipedia

(part 2 can be found here)

This is an Edison. Edison is a cheap, rugged, programmable and LEGO-compatible robot.

Edisons have two motors, which can drive the wheels independently, an optical sensor on the base, and an infrared beam and sensor which is used for both obstacle detection and messaging. For output, they have a piezo transducer and two individually controllable LED lights at the front. There’s lots of smart thinking gone into the design of these robots. For example, they come with an in-built program that let them learn the signals from standard remote controls, so use your TV remote to drive the robot around.

There are three ways to write your own programs for an Edison. EdBlocks is a simple drag-and-drop system inspired by Scratch, EdWare is a bit more similar to the LEGO Mindstorms programming tools, and EdPy is a simplified version of Python. These are all available as web-browser-based interfaces.

(UPDATE: Lego’s Robot Inventor now supports Python too!)

Right from the beginning, I’d planned to get two of them, because I figured it would be fun to get them interacting. My son asked if it would be possible to get the robots performing synchronised dance moves. Now, obviously, we could load the same program into both, but I’ve always been intrigued by swarm robotics, so wouldn’t it be more fun if I could get them to self-organise? What if I could get one of them to teach the moves to the other?

This did not go 100% smoothly.

Read full post gblog_arrow_right

You shouldn't unit test (but you have to)

At my work, I’m tasked with being the unit testing advocate: I promote unit testing across the development department, I help solve unit testing problems and I mentor developers who are new to unit testing. This puts me in a funny position because–if I had a choice–I’d tell people not to write unit tests at all. If I had to sum up why, I’d paraphrase Winston Churchill’s quote about democracy:
Read full post gblog_arrow_right

Software development is an optimisation problem

I saw an blog post recently, “The Documentation Fallacy”. Jussi Pakkanen’s position there is that 95% of your code doesn’t need comments, and he said a lot of things that I more-or-less agree with. But, obviously, it triggered some argument when it was posted to Hacker News. When we talk about software, we have a habit of phrasing things in terms of rules, of absolutes. Comments always rot. If you don’t comment your code, you’re lazy.
Read full post gblog_arrow_right