Back from the APL meeting in Hamburg, where my C3Pi made it’s first appearance on German soil (and a few days meeting with APL users in Milan). I’ve extended the control program which was used to make last week’s figure 8 video to give me some “hand controls”. I do appreciate that it is inadvisable for humans to control motor vehicles directly, but in the privacy of my own home I have risked a little careful driving:

The APL Code

You can see the latest code at https://github.com/APLPi/APLBot. However, beware that significant changes will be made next week – both to the APL code and the Arduino / I2C interface layers. We will be adding support for our first sensor – an Infra-Red sensor that will allow us to measure the distance to the nearest obstacle (in front of the ‘bot) – and this requires some extensions.

The APL code currently consists of three files: I2C.dyalog, DyaBot.dyalog and DrivePi.dyalog. These need to be placed in the same folder on your C3Pi.

The I2C.dyalog file relies on the library lib2c-com.so, which will be installed along with Dyalog APL for the Pi when this becomes available.

The final piece of the puzzle is the control program for the Arduino. That’s in APLPi/I2CArduinoComm. Install it by following the relevant part of Jason’s instructions on building your own C3Pi.

The three APL code files implement the following layers:

I2C: A namespace which loads libi2-com.so and makes four interface functions available in the active workspace. Strictly speaking, this file belongs in the libi2c-com repo, and will move there when I have time to co-ordinate rewriting some test cases with Liam.

DyaBot: A class, built upon I2C, which allows APL applications to control the robot by setting a field named “Speed” to a 2-element vector containing values between ¯100 (full reverse) and 100 (full speed ahead) for each of the 2 wheels.

DrivePi: A namespace, built upon DyaBot, containing a function Run which provides a very simple “game interface” for driving the C3Pi, and a function Play which accepts 3-column matrices of (Right Wheel Speed, Left Wheel Speed, Duration) records, which are “played back”.

What next?

The ultimate goal of our project is to write some code which allows the C3Pi to perform Simultaneous Localization and Mapping (SLAM): The robot should be able to examine its surroundings, build a map, and accept high-level instructions to move from point to point, avoiding obstructions. As mentioned above, we’ll be addding the first collision-avoidance sensor next week. Once that is done, I’ll be back to discuss the other sensors that we are planning to add to the C3Pi in the coming weeks. I hope that some of you will join us in building your own robots and helping write the software!

Follow

APL on the C3Pi

One of the biggest joys of being the CTO of Dyalog is that you get to write code to help evaluate prototypes of proposed language features, or new tools and tutorials that we are planning to make available. This past week has been one of the most exciting for a very long time, because it started with Jason and Liam presenting me with the first fully-assembled Dyalog-built C3Pi clone!

Jason Rivers has been constructing the hardware, and Liam Flanagan is responsible for the port of Dyalog APL to the Raspberry Pi, which will be the seat of the “brains” of the robot. We have been talking to the folks at Quick2Wire over the winter about this project, primarily with Romilly Cocking, who is one of those select individuals who can boast that he has already achieved the dream of every programmer.

This week, all the bits came together:
• Jason finished assembling the first C3Pi mockup (we are building 4 units to play with, while we wait for the finished item from Quick2Wire).
• The CTO purchased and charged two sets of six AA batteries.
• Dyalog APL version 13.2 (Unicode edition only) passes our tests on the Pi, except for an issue with de-normal floating-point numbers caused by a known issue in the Linux kernel. We aim to officially release a free non-commercial version for the Raspberry Pi by mid-May, contact us for an advance copy if you can’t wait.
• Liam has built a shared library which interfaces APL to the I2C bus which is used to make life a little easier for an APL developer trying to use I2C. We use I2C talk to the Arduino which controls up to 11 outputs and 6 inputs, if I am reading the specification correctly. At the moment, we use three outputs for each of two motors: One analog output to control the speed and two digital outputs to activate the motor going either forwards or back.
• Liam has also constructed some temporary code we are using while we wait for the updated Quick2Link code to become available: This is a “command interpreter” running on the Arduino which accepts 3-byte commands {pin type, pin number, output value) over the I2C interface, providing a very easy mechanism for APL to drive the Arduino outputs.

Now, that’s a pretty exciting package to find on your desk on a Monday morning! OK, Monday afternoon, to be honest – the morning was spent with Fiona Smith, our first full-time Technical Writer – another person who will soon be contributing to our “Pi” project. Needless to say, I shortened every meeting for the rest of the week by 5 minutes, and thus managed to find the time to write some APL code capable of driving the robot (press “play” below).

We’ll be keeping the various bits of code up-to-date in repositories under https://github.com/APLPi. If you think you might want to build your own hardware and play along with us, Jason will soon be starting his own series of blog posts about how to build a C3Pi. I will write a bit more about the APL code, and the longer term goals of this project, in my next post.

Follow