RaSCL
Give your robot brains!





Quick Links

This software will be available soon; see here for details.

See here for RaSCL developer online resources.












Interested?

Interested in getting an early version of RaSCL?

I could do with some people to give it a try, to see whether it is useful!

If you are interested, drop me a mail!


 Robotics and Sensorial Control Language

 Quick Introduction

RaSCL provides an abstracted interpreted language and associated libraries to allow robotics hobbyists to add complex reactive behaviour to their host controlled robots. The RaSCL core abstracts notions such as resource sharing/locking/deadlock avoidance, multiple thread/job interaction and other programming aspects associated with a multi-threaded control system. This leaves the RaSCL developer to concentrate on high level robot behaviour, rather than low level programming concepts.

In essence, RaSCL aims to provide hobbyists with a development platform they can use to control their robots without the need for extensive programming background, whilst providing an expandable and powerful language that will not limit them as they develop more comprehensive robots.

 What is RaSCL?

  • RaSCL is an interpreted language, which has most similarities with Scheme/Lisp (in terms of basic syntax).
  • Simplifies resource locking/interaction/deadlock avoidance etc
  • Provides multiple job support and job interaction
  • Adds object like behaviour to ease development and understanding
  • Console application on Linux/Windows
  • Intended for those that want a simple but flexible way of getting their robot to do stuff!

 What isn't RaSCL?

RaSCL is not intended for embedded devices, but operates on a Linux or Windows driven device. I believe this addresses a large proportion of robotics hobbyists, who (like myself) may not have the experience or equipment to implement all control behaviour in embedded electronics. However, the major advantage of RaSCL is its ease of development; you can develop the RaSCL control programs on your desktop PC, and know they will execute exactly as they would when running on the robot itself.

In my SlyBot robotics project I intend to run RaSCL on a small Linux powered PDA, allowing for an on-bot control solution but still being powerful and easily configurable.

Goto Top










First version should be available for Windows and Linux in mid to late April!









Excuse the current lack of documentation, more will follow when the first version is released!

 RaSCL Status and Download

RaSCL v0.1a (Initial Alpha Release) for Linux/Windows

Description:

This will be the first release of RaSCL for Windows and Linux. The application still requires significant development, and this is intended as an initial alpha release. It will allow users to define their basic servo/controller set-up and execute simple programs (with no sensor feedback). It includes libraries for servo calibration and wave gait walking.

The release will really act as a scoping experiment, to see whether it really is useful!

Requirements:

  • Windows or Linux PC (or device capable of executing such binaries)
  • Servo/motors driven from one or more RS232 servo controller boards
  • Knowledge of the binary encoding over RS232 between the PC and the controller
  • A bit of spare time as it's still a young application!

Download:

I aim to make v0.1a available during April 2005! Watch this space!


Goto Top




This is only meant as a sneak preview of syntax, not a full guide!

















Slyware Logo
























Data Encodings

I could do with building up a set of controller encodings in the RaSCL libraries.

If you know of some, please forward the details of the controller and its byte stream, cheers!



























Good/Bad Idea?

I'm still experimenting with RaSCL, and developing as I go.

If you've got any comments or suggestions they would be welcomed!














The actual wave gait walking algorithm is pretty simple.

Ignore any RaSCL you can't decipher for now!

 Example Code

The best way to give an insight into how RaSCL works is to give some examples. This will hopefully serve as a little introduction to RaSCL until I get round to writing a proper introduction to go with the first release! Don't worry if it looks complex for now, as the code examples that follow are actually taken from the libraries that come with RaSCL. As a user, you just call these routines. However, they give a pretty good introduction to the syntax.

 The RaSCL Basics

RaSCL commands are enclosed within brackets, and a program consists of a sequence of these commands. For each line, the interpreter will evaluate from the inside out, hence it will evaluate the inner most expression first. All commands are in prefix notation. For example, with the code (+ 50 (* 10 20)) the (* 10 20) will be evaluated first, then the resulting (+ 50 200) giving 250.

 Defining a Servo Controller Object

In this example I assume that the robot has an RS232 servo controller (the one used here is the 'Servo-12 driver board' from Milford Instruments Ltd) to drive the servos. This example will highlight how to represent such a controller in RaSCL.

In RaSCL, controllers are called resource containers; they either control or receive input from a number of resources. Such containers have the property that they can contain resources (such as servos/sensors), and they are in fact resources themselves.

Obviously different controllers will require difference encodings (the way the commands are sent from the host to the controller), so this functionality is defined in RaSCL. In RaSCL, a controller is represented by a resource-object; that is it appears as a resource with various specialised methods.

A resource itself in RaSCL can have any number of properties (such as a servo having a position), and the ability to set and get these values are controlled to avoid two jobs attempting to update the value at the same time. In RaSCL, you can define a resource object simply by specifying a constructor for it:

Defining the Controller Constructor

The first point in the following code to note is that the (::complex_function ...) statement defines a function in RaSCL (as opposed to basic functions, which are not described here). The leading :: simply means let the current job interpret this, and is actually converted to a special pointer called this:: within the interpreter.

  (::complex_function RS232Controller<MFSSBD12> create)
  (::endfunc)
         

Secondly, we define the RaSCL class from which this controller is inherited from; the pre-defined type RS232Controller, which provides basic communications via a RS232/serial port. The MFSSBD12 between the <> signs is the name we give to this new object. Finally we define the function name, which as it is a constructor should always be create. As it happens, our constructor for a controller doesn't do anything; its definition is simply required to define the type to RaSCL.

Defining the Controller Data Encoding

The next task is to define the way the servo ID, target position and required speed are encoded into a piece of data to be sent to the controller. For this, we define a function named encode_servo_command. When this function is called, it is passed a list containing the servo ID, the position and the speed in a RaSCL list (a RaSCL list is represented by data enclosed in curly braces, i.e. { a b c }).

  (::complex_function RS232Controller<MFSSBD12> encode_servo_command)

    # Split out the arguments
    (::= .lID (icar func_args 0))
    (::= .lPos (icar func_args 1))
    (::= .lSpeed (icar func_args 2))

    # Build and return the command
    (::return (list 255 (bit| (bit<< (bit& lSpeed 15) 4) (bit& lID 15)) lPos))

  (::endfunc)
         

Again, the function definition includes the full type name as did the constructor, with the method name of encode_servo_command. The next three lines simply extract the three bits of information out of the passed list (arguments are placed into the variable named func_args). The icar command is an index car primitive; it extracts a single element from a list at the given index. The ::= command sets a variable (the first parameter) to equal a value (the second parameter) within the local function scope (hence the ::'s, as it's calling back to our local job (the leading dot prevents the interpreter from attempted to evaluate the variable, but you can ignore that for now).

The last bit is the meaty bit. First, note that bit&, bit| and bit<< perform a bitwise and, bitwise or and bitwise left shift respectively. The MFSSBD12 controller expects three byte commands, the first contains a synchronisation byte of value 255, the second byte contains the servo ID (low four bits) and the desired speed (high four bits) and the final byte containing the position (see below).

   1        8     12   16          24    (bit) 
   <--sync--> <--byte1--> <--byte2-->    (allignment)
      255     |spd |  ID|     pos        (data)

  (list 255 (bit| (bit<< (bit& lSpeed 15) 4) (bit& lID 15)) lPos)
         

We're now ready to decipher the final command. The result will be a RaSCL list of three bytes (matching the sequence defined above). The first byte (255) is obvious, but the second is a little harder. It is defined as (bit| (bit<< (bit& lSpeed 15) 4) (bit& lID 15)). Looking above you will see that the first four most significant bits are the speed. Therefore, we take the speed from the lSpeed variable, take the four least significant bits (logical AND with 1111 base 2), then shift it left by four. Then we simply logically OR the result with the four least significant bits of the ID to get the complete second byte. Try it in calc!

The final byte is simply the position, so that can be added to the list as is. The last operation is to call list to enclose the result in a RaSCL list, and we're all done!

Hopefully that gave you a small insight into RaSCL and how commands are structured. See some of the examples below for more insights into how it all fits together.

Click here to see the full definition of a controller.

 Definition of a Servo Object

After reading the above, you may be wondering how the controller is used. Well, as with the controller, a Servo is a resource object within RaSCL. It has various properties (such as a position and ID etc) but also has some additional methods. It includes the setpos and getpos methods to control the servo directly. Additionally, it uses normalised position values, which take into consideration the calibration settings (the servos limits). The actual RaSCL code may seem complex initially, but it should be possible to see how the interactions take place.

Click here for the definition of a RaSCL servo and all its methods. Of course, as a RaSCL user you need not be concerned with this, but it gives an idea of the syntax.

 RaSCL code for Wave Gait Walking

If the previous definition wasn't enough, how about the complete definition for wave gait walking in RaSCL! Again, most of syntax may be unclear initially, but its a good overview. Obviously with a correctly set-up bot running RaSCL, you could just call this routine and your bot would start to walk!

Click here to see the definition of wave gait walking in RaSCL.

Then, click here to see a video of it in action (running at slow speed) with an early version of SlyBot I!

Goto Top

 RaSCL Resources

 RaSCL - Code Definition and API

When the first version of RaSCL is released I'll place the API documentation here!

Goto Top