A Native for the LEGO MindStorms RCX CO620 Final Year Research Project

Jon Simpson Computing Laboratory, University of Kent [email protected] The Big Three • Who? • Jon Simpson (undergraduate) • What? • A small and maximally concurrent occam-π operating environment for the LEGO MindStorms RCX robotics platform. • Why? • Interested in the use of concurrency for robotics. • Previously explored methodologies for designing concurrent robotics programs with occam-π on a large mobile robot platform. • J. Simpson, C. L. Jacobsen, and M. C. Jadud. Mobile Robot Control: #e Subsumption Architecture and occam-pi. In F. R. M. Barnes, J. M. Kerridge, and P. H. Welch, editors, Communicating Process Architectures 2006, pages 225–236. IOS Press, September 2006. • To gain experience with low-level hardware programming and C. • Get more involved with the Transterpreter project.

2 LEGO MindStorms RCX • 16 MHz, 16-bit Hitachi H8/300 CPU • 16kB of ROM • 32kB of RAM • RCX ‘executive’ loads into RAM from ROM at power on. • Once uploaded, programs and executive share space in RAM. • 3 input ports with A/D conversion • 3 output ports • Speaker • Timers • Infra-red port (used for program upload)

3 The Transterpreter (TVM) • A portable interpreter for the extended Transputer instruction set (occam-π) written in ANSI C. [1] • Support for: • Mac OS X (PowerPC, Intel) • (, MIPS) • Windows (x86) • LEGO MindStorms (H8/300) • Existing support removed in late 2004, due to growing problems with memory space on the LEGO & keeping feature parity with the main version of the interpreter for all other platforms. • A renewed LEGO port of the TVM that solves these problems would facilitate continued concurrent robotics explorations with occam-π.

4 Space, the final frontier

ROM 2k (RCX executive)

ROM (16k) RAM (32k)

5 Space, the final frontier

ROM ROM 2k use (RCX executive) (4k)

ROM (16k) RAM (32k)

6 Space, the final frontier

ROM ROM BrickOS 2k use (RCX executive) (12k) (4k)

ROM (16k) RAM (32k)

7 Space, the final frontier

ROM ROM BrickOS TVM 2k use (RCX executive) (12k) (4k) (8k)

ROM (16k) RAM (32k)

8 Space, the final frontier

ROM ROM BrickOS TVM Byte 2k use code (RCX executive) (12k) (4k) (8k) (3k)

ROM (16k) RAM (32k)

9 Space, the final frontier

ROM ROM BrickOS TVM Byte Free 2k use code (RCX executive) (12k) (4k) (8k) (3k) (3k)

ROM (16k) RAM (32k)

10 The Problems of Space • #e small amount of available memory restricts the kinds of programs that can be written. • #e original port of the TVM supported occam 2.1, but the dynamism of occam-π [3] is desired. • #e dynamism introduced into occam-π is of limited use given so little free memory. • Free memory is reduced yet further by adding and including support for these extended π features of the language.

11 VM Growth • #e TVM is cross-platform and has many di$erent target applications (from embedded platforms, all the way up to MPI clustering) • As functionality has been added to cater for these applications, and been integrated into the main line of development, the interpreter size has increased. • Having to maintain a separate, limited branch of the VM for the LEGO would not be ideal. • Some of these new features are useful for robotics (e.g. BARRIERs) • From previous experience, space for future growth is important! • If we update the size of the virtual machine on the memory diagram to be current..

12 VM Growth • TVM (late 2004)

ROM BrickOS TVM Byte Free 2k use code (12k) (4k) (8k) (3k) (3k)

RAM (32k)

13 VM Growth • TVM (late 2004)

ROM BrickOS TVM Byte Free 2k use code (12k) (4k) (8k) (3k) (3k)

RAM (32k)

• TVM (February 2007)

ROM BrickOS TVM Byte 2k use code (12k) (4k) (11k) (3k)

RAM (32k)

14 Something’s got to go... • #ere’s absolutely no free space for this stack of so%ware to run. • Can’t do anything about the reserved and ROM function memory. • Need the TVM and bytecode. • BrickOS can go! • But it’s being used to interface with the hardware from the TVM. • We’ll need to create a new set of ‘OS’ services for the TVM to use when interacting with the hardware.

15 A Solution Appears

ROM ROM Byte Free TVM code (RCX executive) 2k use (4k) (11k) (3k) (12k)

Total ROM (16k) Total RAM (32k)

• #e RCX executive in ROM contains &rmware functions for interacting with the hardware at a basic level, and they are available to us already.

• #e functions in ROM are wrapped in a C library (librcx[2]), which can be used in the C code of the TVM. • Can access the C functions from occam-π through use of the Foreign Function Interface [4].

• #e RCX’s hardware is memory mapped, so we can PLACE variables at those addresses in occam code to manipulate it directly.

16 On Endianness

• #e virtual machine is little-endian, but the RCX is a big-endian architecture. • Calls to C functions require their parameters to be byte-swapped in and out, if the values are to be read and written correctly on both ends. • #e values of memory addresses read or written directly from occam (via PLACEd variables) will need to be swapped. • #ere are some complications with arithmetic shi%s and possibly other operations.

17 New Requirements

• BrickOS will no longer bring up and initialise the hardware, the TVM must now do it. • Including memory, the timers and any interrupts. • #e ROM &rmware functions provide much lower level functionality than BrickOS previously did to the TVM. • Interfaces to the Sensors, Motors, LCD, Buttons, Sound and Power status are required, for programming the RCX. • #e RCX Executive loads at power on, and will accept an initial &rmware image (the TVM, in this case) over IR. • Transputer bytecode can be compiled directly into the VM, and uploaded with the initial &rmware image. • Subsequent code uploading will have to be done in the TVM, as BrickOS no longer provides this functionality.

18 Maximally Concurrent

• Using the FFI and PLACEd variables, we can write almost all of the the now missing functionality in occam, running inside the TVM. • A minimal initialisation in C brings up the VM, then the processes containing the operating environment are loaded & run. • Bene"ts • Uni&ed scheduler (as much processing inside the VM as possible). • Safe concurrency down to the hardware level, for writing these system level processes. • Makes it more straightforward to expose natural process and/ or channel interfaces for the hardware to the programmer.

19 The debug.man

20 Ground Up Concurrency: Advantage

• Whilst writing small test programs, it was hard to see when the VM was running, or if it had crashed or deadlocked. • Ideally it would be good to signal to the user that the program is running. • #e RCX has a &gure on the display in the shape of a person, which can be either walking or standing. • Initially, a small test process (debug.man) which used this &gure had been written when debugging the timer. • Running this process in parallel with any other code that is running gives us an instant indicator that the VM is running, and scheduling processes correctly. • Doing this with C threads would have been prohibitively complex for this purpose.

21 Parallelism as a Debug Aid

... -- Display a running man with the segments of the display PROC debug.man () TIMER tim: INT t: SEQ tim ? t WHILE TRUE SEQ lcd.set.segment (LCD.STANDING) tim ? AFTER t PLUS (500 * MILLIS) tim ? t lcd.set.segment (LCD.WALKING) tim ? AFTER t PLUS (500 * MILLIS) tim ? t : -- Main PROC, must have the three top level channels PROC my.test.program (CHAN BYTE kyb?, scr!, err!) PAR debug.man() foo() -- Could be any number of processes being tested. :

22 Difficulties • Working through issues of endianness between the virtual machine and the hardware. • Blind debugging, no printf, just a 4 digit LCD display. • #ere are also many ways the RCX can crash that will leave no way to put debug output to the screen.

23 The High-level View

FFI Here be occam-π dragons C

24 Endianness (C FFI) void ffi_function (int *w) { int value.location; value.location = SwapTwoBytes(w[0]); /* do something to value.location */ *(int *)SwapTwoBytes(w[3]) = SwapTwoBytes (value.location); }

Getting this swapping right is HARD for complex functions, which may have any combination of arrays, VAL TYPE or TYPE parameters

25 Problems • If address values are swapped (or not) incorrectly, the resulting memory accesses will very likely cause crashes (hard to debug!). • Variables that go through the FFI to C and back multiple times (say, in a loop) must be properly returned to the occam environment each time. • Some values go into the FFI and are not returned, so they do not have to be swapped back. • #e solution to these problems would be a big endian interpreter for this platform, avoiding swapping. • One exists, but there are problems with the big endian bytecode generation.

26 Results • A working virtual machine port that runs without any underlying support OS, and provides a large amount of free space for programs.

ROM ROM Byte Free TVM code (RCX executive) 2k use (4k) (11k) (3k) (12k)

Total ROM (16k) Total RAM (32k)

• High-level occam processes for interfacing to all of the major hardware functionality (Sensors, Motors, LCD, Buttons, Sound)

27 Future Work (>1 Month)

• Bytecode uploading to the running VM and execution along with processes in a single virtual machine instance. • Design of the embedded OS network, and its process API for programmers. • Sample robot programs, OS and API documentation.

prefix delta to.lcd lcd.out.int (n)

upload.handler succ numbers TVM

28 Future Work

• Introduction of subsumption architecture primitives. • A visual concurrent robot programming tool (RoboLab esque). • Potentially, combining the robotics API with Adam Sampson’s LOVE or Christian Jacobsen’s POPExplorer. • Having the TVM run big-endian on the RCX. • Would clean up the code dramatically, but is dependent on external limitations in the . • A comprehensive series of exercises to introduce programmers to concurrency via robotics with the MindStorms RCX. • Would facilitate use for concurrency teaching purposes. • Implementation of memory management, to allow the dynamic features of the language to be enabled.

29 References

• [1] C. L. Jacobsen and M. C. Jadud. #e Transterpreter: A Transputer Interpreter. In Communicating Process Architectures 2004, pages 99–107, 2004. • [2] Kekoa Proudfoot, librcx, A lowest level driver for the RCX. http://graphics.stanford.edu/~kekoa/rcx/tools.html • [3] P. Welch and F. Barnes. Communicating Mobile Processes: introducing occam- pi. In A. Abdallah, C. Jones, and J. Sanders, editors, 25 Years of CSP, volume 3525 of Lecture Notes in Computer Science, pages 175–210. Springer Verlag, Apr. 2005. • [4] D. C. Wood. KRoC – Calling C Functions from occam. Technical report, Computing Laboratory, University of Kent at Canterbury, Aug. 1998.

30 Acknowledgements • My sincere thanks to Matt Jadud & Christian Jacobsen , who have both given large amounts of their time to both advising me with this project and aiding me with additional research work carried out over my undergraduate career. • #anks to Damian Dimmich for exploration of the big-endian Transterpreter, pointers and encouragement. • And &nally, thanks to David Wood for agreeing to supervise this project.

31 Questions? Thank you End of presentation.