KAREL Programming

I received a question via email the other day where someone wanted to know how to log timestamped position data to a file. As luck would have it, I’d been meaning to write a post about something like this for quite a while now.
This application ends up being a great example that covers a broad range of KAREL programming fundamentals:
KAREL variables, constants and data types Custom ROUTINEs String manipulation Bitwise operations TPE parameters Error-checking and the status convention File operations File pipes (the PIP: device) Data formatting Let’s get started by considering our desired TPE interface.

I’m currently working on a project where two separate tasks need to pass data to eachother. How do we do that in KAREL? Enter the pipe PIP: device.
The concept of a pipe has been around since the early 1970s, originating as a crucial part of the Unix operating system. Pipes simply provide a mechanism for data to travel from one process to another.
While the KAREL manual does a pretty good job of describing how pipes work and how to use them, I ran into a couple of issues while implementing the provided example.

I was working on a KAREL project the other day where I really wanted to use an associative array to store some key => value pairs. While a STRUCT would be appropriate if my keys were known ahead of time, there’s no data type for mapping unknown keys to values…
…so I built a hash table implementation that you can use in your own KAREL programs. The source is available here: https://github.

I’m happy to share a real open source project that I’ve been working on: KUnit. The source code is available on GitHub: https://github.com/onerobotics/KUnit.
Coming from a Ruby background where automated unit testing is common-practice, it’s frustrating to come work on a robot where tools for automated testing don’t exist. No matter how careful I am when making changes to my code, I always feel a little bit exposed without a comprehensive set of unit tests making sure I didn’t break something.

You can do just about anything with FANUC’s TP programming language, but there are some things it just can’t do. Enter KAREL.
KAREL is a lower-level language very similar to Pascal. It features strongly typed variables, constants, custom types, procedures, functions, and gives you access to all sorts of useful built-ins for things you may not be able to do with TP. (By the way, if you’re interesting in TP programming, please check out the book I wrote on programming FANUC robots.

UPDATE 2014/02/27: If you’re looking for a how-to guide on FANUC KAREL programming, you’re probably better off reading my Introduction to KAREL Programming article.
One of the things I love about the Ruby community is its dedication and support for testing. Having very little formal computer science education, concepts like unit testing and integration testing were completely foreign to me. After first ignoring everyone’s advice to test now and test often, I eventually forced myself to learn out of necessity and now advocate the practice to anyone who will listen.