C3Pi Opens Eyes at the APL Moot

The "Three Blind Mice" at the APL Moot at the YHA in the Lee Valley

Sam Gutsell, Shaquil Sidiki and James Greeley (aka “Three Blind Mice”) at the APL Moot at the YHA in the Lee Valley

This weekend, the Dyalog C3Pi reached the final stop on the European spring tour, attending the British APL Association’s Annual General Meeting and “Moot” just north of London, where the robot met the famous mice from Optima. The day before, the C3Pi also travelled to an OSHUG meeting in London on Thursday, where Romilly Cocking was talking about quick2link. Alas, poor C3Pi was confined to a cardboard box due to problems with wiring up its new “eyes”:

Sharp "GP2Y0A21YK0F" IR sensors attached to the Dyalog C3Pi

Resistance is Futile!

Asimov’s third law of robotics states that a robot must protect its own existence. Thanks to the addition of a SHARP infrared distance measuring sensor, our robot is now capable of at least not running head first into walls or other obstructions (and if the obstruction is a spectator, we’re also providing some support for the first law)!

first-third-laws

C3Pi obeying the First and Third Laws of Robotics

Connecting the Sensor to the Raspberry Pi

The sensor is attached to an analog input pin on the Arduino (we picked pin #0). Our Arduino command interpreter, which allows APL on the Rasperry Pi to use the Arduino as a “controller” for analog and digital I/O, was extended with an “Analog Read” command consisting of the letter “a” followed by a byte giving the pin number and a dummy pad byte in order to ensure that the command length is 3 bytes (the fixed length simplifies the interpreter). Thus, if APL transmits (97 0 0) to address 4 on the I2C bus, and then issues an I2C read command, it will receive a string containing the current voltage (up to 5v, in 1024ths) measured – for example “a0:480;” if the input is 2v. We elected to include a confirmation of the pin number in the result, and separators which will allow us to send several sensor input values in a single string, as we add more sensors to the robot.

In the APLBot GitHub Repository, The DyaBot class has been extended to run a background thread which updates the value of a new property called “IRange”, every 100ms (a public method UpdateIRange can be called at any time to refresh the value). The input voltage is converted to a distance in centimetres, using the tables from the sensor datasheet. The next blog post will illustrate some of the data that we are now able to collect from the sensor.

The DrivePi game code also runs a background thread which monitors the value of IRange, and stops the wheels if the measured distance drops below 20cm – but this code still needs some testing and tweaking.

Accelerometer and Gyro on the Way

My experience to date is that controlling the robot is a little bit tricky, because the output of the wheels seems quite variable (changes from day to day, and from hour to hour). Determining the position of the robot using “dead reckoning” based on the voltage applied to the wheels seems unlikely to succeed. We either need to find some more reliable wheels – or find some sensors that can help us understand what is going on.

I have been able to lay my hands on an MPU-6050 motion tracking device from InvenSense. We’ll be trying to wire this up over the next couple of weeks and see whether it allows us to accurately track the motion of the robot. We will also soon take delivery of an ultra-sonic sonar mounted on a servo, so we can start measuring longer distances accurately (the IR sensor is really only suitable for collision avoidance). Once these are wired up, all we have to do is write “a little” APL code to do the localization and mapping!

Driving my Pi

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!

APL – Coming to a Robot Near You

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!

The first Dyalog-build C3Pi CloneJason 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.

GSE & APL Germany in Hamburg, 29th&30th April 2013

Gitte Christensen and Morten Kromberg will be attending the “GSE Arbeitsgruppe APL” meeting on April 29th, and speaking at the “APL Germany e.V.” meeting on April 30th, at ERGO Versicherungsgruppe AG. The key topics are likely to be performance, new language features proposed for version 14.0, and controlling robots using APL. Check out the complete agenda for the two days.

Ladies and gentlemen, boys and girls, welcome to “Dyalog blog”!

There are so many new activities at Dyalog, and so many new people taking a look at Dyalog APL – many of whom do not have the opportunity to attend traditional “APL User Meetings” – that I am starting a “blog” in the hope that this will provide the required bandwidth. The intention is to post regularly about activities at Dyalog – in particular in the development team – as seen through the eyes of the current CTO.

Coming Up Next…

OK, I do understand that modern blogs are supposed to at least appear spontaneous, but old habits die hard: I have a list of topics that I am currently writing up and hope to publish in the near future. I am hoping to strike a reasonable balance between discussing topics of interest to established APL developers writing and maintaining production applications, and newcomers who only just heard about APL.

I look forward to your feedback on how to prioritise the proposed topics, add to or delete from the list – or any other comments that will help me make this blog more useful – either in the form of public comments on this site or, if you prefer, private e-mail.

Posted in CTO