kent logo

CO538 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for robodeb


Question 98 (2006):

Submission reference: IN1155

How dynamic should our code be? I played around with getting my robot to ajust itself with variable amount depending on its position and current state, but my code works much better if i just hard-code in the values.

For example, if it's to close, turn away at a hard-coded speed and angle. Obviously if I set its speed and direction dynamically and made small ajustments, that would be better. But i can't seem to get it to work as I designed. So I'm curious as to how the marking works in the regard to this?

Should I just talk about this in my report?

Answer 98:

Sounds like you have been thorough. Submit two versions of your system: one with hard-coded values and one that tries to adjust dynamically. In your report, say what you have said here – namely, that the hard-coded version performs better. Say how and how long it took you to settle on those hard-codes values. Speculate on why the dynamic version isn't working. Do all that well and you'll get full marks ... :)

Make sure your hard-coded values are, of course, named VAL constants.

Keywords: robodeb , coursework

Question 96 (2006):

Submission reference: IN1150

Is there a way to extend the buffer or output the occPlug output to a file? If not, getting data is going to be hard :(

Answer 96:

I'm afraid that, right now, there is no way to get a scroll bar on the occPlug run window – nor to divert its output to a file.

However, you can do both these things by running the Transterpreter executable in a Unix command-line window. Getting a scroll bar depends on the terminal emulator for your command window – ctl-right-click often helps!

First, compile your program in the Transterpreter occPlug window in the usual way. Now go to a command window and change to the directory containing your occam source file – say myprogram.occ. After a successful compilation, there will now be a file: myprogram.tbc. This can be run with the command:

    tvm myprogram.tbc

The output appears in your command window, which can have a scroll bar. To redirect this output to a file of your choice:

    tvm myprogram.tbc > <file-name>

Warning: you won't see any output now and the file can receive lots of data much faster than a screen! So, let it run for only a few seconds – then, stop it by keying CTL<c>. Now look at your file with any text editor or the less utility:

    less <file-name>

If you can't get the scroll bar to appear, you can pipe your program output directly through (the Unix) less utility (without writing to a file first):

    tvm myprogram.tbc | less

Only the first screenful is displayed. To see more, press the down-arrow key (for one more line) or page-down (for another screenful). To scroll backwards through the output, press up-arrow or page-up. Note: this assumes your program is generating plain lines of text. It won't work very well for your dining philosophers animation!

Keywords: robodeb , coursework

Question 95 (2006):

Submission reference: IN1142

What size are the grid squares on the worlds?

Answer 95:

You don't really need to know the actual scale. The robot doesn't need to calculate its speed precisely – everything should be relative. If it's going too fast and its controls don't work, slow down. If it's going too slow and nothing much is happening, speed up!

Having said that, the scale depends on the size of the map. Go to the directory holding the world you are using. For example, if you are using the world angles, then in ~/worlds/angles you will find a file called angles.world. Inside that file is a configuration line like:

    size [32 32]

This is the size of the world in meters. A window configuration segment:

      size [520.000 520.000]
      center [0 0]
      scale 0.070

sets the size of the window to be 520x520 pixels. The map.png file that it is using is 509x509 pixels; so that leaves a bit for a border around it. I'm not sure what the scale does option does. A meter on this map should correspond to around 16 pixels (= 520/32). I wasn't able to find out how many pixels wide are the boxes, but they are probably somewhere around 16 pixels again. But I wouldn't use the boxes for any sort of accurate measurement ...

Keywords: robodeb , coursework

Question 94 (2006):

Submission reference: IN1136

Hi. Me and my group member have been working on the assignment, to start we want to simply get the robot walking in a straight line. To do so we have linked the brain stem process up to a follow method which used the two.motors process to send identical ints to both the left and right motot.

However regardless of what values we use the robot always walks in a circle to the left. Why is the robot not walking in a straight line when we give the left and right motor the same values. Our code is as follows:

    #INCLUDE "vehicles.inc"

    -- output speed
    PROC number (CHAN INT output!)
      INT x:
          x := 100
          output ! x

    -- Caution
    PROC follow (CHAN MOTORS moto!, CHAN LASER sick?)
      CHAN INT motor.right:
      CHAN INT motor.left:
          two.motors(motor.left?, motor.right?, moto!)

    -- Main
    PROC main (CHAN BYTE kyb, scr, err)
      CHAN MOTORS moto:
      CHAN LASER sick:
        brain.stem.ML (moto?, sick!)
        follow (moto!, sick?)

Kind Regards.

Answer 94:

To set your robot moving in any direction, you only need to issue the command (i.e. do the communication) once. Your code is continually issuing the command and this is the cause of your problem.

But first, it's much simpler to drive the MOTORS protocol directly, rather than change wheel speeds separately via two.motors – probably. This protocol is defined is section 1.4 of:


To move your robot forward in a straight line, send the message:

    to.motors ! speed; 0; 0

You only need to send it once and speed is in cm/second. For example:

    PROC main (CHAN BYTE kyb, scr, err)
      VAL INT speed IS 50:  -- cm/second
      CHAN MOTORS moto:
      CHAN LASER sick:
        brain.stem.ML (moto?, sick!)
        to.motors ! speed; 0; 0

Driving the wheels independently, your program could be:

    PROC follow (VAL INT speed, CHAN MOTORS moto!, CHAN LASER sick?)
      CHAN INT motor.right:
      CHAN INT motor.left:
        motor.left ! speed
        motor.right ! speed
        two.motors (motor.left?, motor.right?, moto!)

    PROC main (CHAN BYTE kyb, scr, err)
      VAL INT speed IS 50:  -- cm/second
      CHAN MOTORS moto:
      CHAN LASER sick:
        brain.stem.ML (moto?, sick!)
        follow (moto!, sick?)

Your follow process:

    PROC follow (CHAN MOTORS moto!, CHAN LASER sick?)
      CHAN INT motor.right:
      CHAN INT motor.left:
          two.motors(motor.left?, motor.right?, moto!)

has a totally superfluous WHILE TRUE. That's silly since its loop body never terminates – i.e. the loop doesn't loop. That shows misunderstanding of your code, but is harmless for execution.

The big mistake is your number process:

    PROC number (CHAN INT output!)
      INT x:
          x := 100
          output ! x

[Let's ignore the use of a variable and its continual re-assignment to the same value – instead of a single VAL declaration.]

This process continually offers its message (the speed value 100) to its output channel. Poor old two.motors is bombarded with repeated speed messages on both its left and right wheel speed channels!

Now, two.motors services those channels with a simple ALT loop. Every time is starts that loop (probably), speed messages are pending on both channels. But two.motors makes no promise on fair servicing of its input channels when under stress – it picks any ready channel it likes. If both are ready, it is entitled always to pick the same one – and it does! Consequently, one of its speed channels is forever starved – no message is ever taken ... ever ... always, the other is taken! So, one wheel gets its speed set, the other remains with its default speed of zero and the robot goes round in circles.

If the number process that was being serviced continually ... just paused sending momentarilly, the other would get in and the robot would have both wheels moving at the same speed. If you really needed to continually adjust wheel speed, put in a small delay between adjustment signals! But, to keep moving in the same direction, just send the instruction once!

OK – maybe we should have programmed two.motors to service its input channels fairly – so that, no matter how hard it was driven, it never starves either channel. That's actually very easy! It's also essential for good behaviour of real-time systems under stress. For these robots, though, there is no need to put them under the kind of stress imposed by your ever-offering number process.

Note: in your seminar groups this week (the last week of term), we will be getting you to work out how to do fair servicing of channels. The trick is to use a PRI ALT, which is definitely an unfair way to provide service. The curious thing is that, with guaranteed unfairness, we can easilly arrange fairness ... :)

Keywords: robodeb , coursework

Question 93 (2006):

Submission reference: IN1149

Hi, what should happen if out robot is placed facing the wall? Should it reverse or stop? Can it reverse?

Answer 93:

Turn left or right seems a reasonable plan. To reverse, have you tried setting a negative forward speed (using the MOTORS protocol)?

Keywords: robodeb , coursework

Question 92 (2006):

Submission reference: IN1137

Hi, for Question 91 (2006), how can I make the robot turning away from objects? Thanks.

Answer 92:

The LASER data gives you the index (i.e. angle) of the min distance to the beast. That angle is with respect to the robot's current direction of travel (where, I think, 90 is straight ahead and 0 is right and 180 is left).

You control the speed of the robot's wheels. If the beast is on your right, slow down your left wheel (maybe to zero) and increase the right wheel speed, etc.

Or, using the MOTORS protocol, slow down and rotate!

Keywords: robodeb , coursework

Question 91 (2006):

Submission reference: IN1125

I'm working on the diku.occ file and i don't know what to do for fear or distaste. You say implement them but you don't say what they are supposed to do! Or maybe i have missed something? I'm just trying to get up to speed and cover all the material so i can tackle the assessment. Spent so long on the dinning philosophers assessment that I've not had much time for this until now.

Answer 91:

We did answer these questions in the terminal sessions.

"Fear" should speed the robot up the closer it gets to an object. It does not imply any turning.

"Distaste" actually speeds it up and turns it away from objects that it detects.

They are intended to be simple process networks that get you accustomed to using the *.slice methods on the LASER data.

Keywords: robodeb , coursework

Referrers: Question 92 (2006)

Question 90 (2006):

Submission reference: IN1124

I am a bit confused about what data we should record for the robots. Mine pretty much stays a constant distance from the walls and surely the time is dependant on the speed? Also, there is only one command to move the robot, which is used in all cases so I can't really record instructions ...

Answer 90:

Like the pebble disturbs the stillness of the pond, your question perturbs the fabric of the Universe.

There are as many ways to solve this problem as there are leaves on the ginkgo tree. Yet no solution provides shade as effectively.

Consider this as you reflect on your own code, and may it inspire you in your writeup.

These are the words of The Master.

(In other words, "Sure". Your writeup will reflect your particular situation, and it might be that your solution is effective and efficient, your data demonstrates that, and you made minimal or no changes as it developed. Report that your robot stays pretty much at a constant distance from the wall. Make precise that "pretty much"! You could, then, consider under what conditions your code might not work well. Can you break your code?)

Keywords: robodeb , coursework

Question 89 (2006):

Submission reference: IN1123

Exactly what do we have to submit for the robodeb assessment?

Answer 89:

This is all explained in the exercise handout (see Question 88 (2006)) and in several places on these pages. Two things: your report (reflecting your development process and evaluation) and your code. You have been mailed that submission directories are on raptor at:


where <login-name> is your raptor login name! Only you can read/write to your directory. Please copy there your project report on your wall follower program (for the robodeb robot) and occam source(s).

These directories will close at MIDNIGHT next Monday night – that's the midnight between Monday, 26th. March, and Tuesday, 27th. March.

Keywords: robodeb , coursework

Referrers: Question 100 (2006)

Question 88 (2006):

Submission reference: IN1121

Hello, I have done the four processes "caution", "fear", "love" and "distaste" for the robot. But I dont know where to start for the following stages, pleazz help, thanks.

Answer 88:

The exercise is defined by:


I'm afraid most of the assessment is on how you work out how to solve the problem (i.e. how you report and reflect on how you worked out a solution) and on your evaluation of its success.

Having said that, have you studied the exercise handout? At roughly 10 pages, this does say what has to be done – though not, of course, precisley how to do it!

The exercises you have done show:

Once you've analyzed that data (not something that is spelled out in detail), you might make some updates to your code in a justifiable manner based on your analysis.

This is not a plug-and-chug assignment. You are a second-year computer science student. We said when we introduced this lab, and multiple times since then (including, I believe, in answers to other questions about this assignment) that we're interested in seeing you demonstrate your ability to think about this problem and engage in a process of software development, measurement, analysis, and reflection. Unlike other assignments you've had, that does not mean that each problem is a self-contained, nice, neat package with only one answer. Instead, this assignment has a bit of a "real life" flavour, where there are potentially infinitely many solutions. The quality of your writeup (analysis and reflection) are what will determine whether your solution is a good one.

I've just outlined some steps you might take to make some progress. You are welcome to talk with classmates about this problem, and if you discuss it with Peter and Fred, they may (or may not) allow you to work in a pair with a classmate to submit a solution and writeup.

Hopefully, this (and previous answers regarding this question) provide some starting points.

Keywords: robodeb , coursework

Referrers: Question 89 (2006)

Question 87 (2006):

Submission reference: IN1119

Hi, currently I am writing a data monitor process for thresholding the incoming data. Would it be a good way to use SONAR channel as the incoming data? And I am not sure what is the purpose of the data type LASER.

Answer 87:

The data types SONAR and LASER are received from the appropriately named channels from the brain.stem process. They are defined and explained on page 4 of:


They are documented further – with diagrams – at:


Keywords: robodeb , coursework

Question 85 (2006):

Submission reference: IN1114

Is the source for occ_player.so (and other dll) available so that I can use robodeb on an architecture other than x86?

Answer 85:

I believe that occ_player is one of the files automatically generated as part of the Transterpreter build process.

In particular, in the Transterpreter distribution, under


you'll find some ".i" files. These are SWIG wrapper files. (SWIG stands for Simple Wrapper Interface Generator.) What happens, when you have a complete Transterpreter *development* environment, is that these files are parsed by SWIG, and used to generate a C file and an occam-pi file. These provide bindings from occam-pi, through to C, and ultimately into the Player/Stage library.

So, if you want to build these things on a different architecture, I think the easiest approach is to check the Transterpreter trunk out of the Subversion repository and build it.


You will need to follow the build dependencies on that page, and will also need a working SWIG installation as well. (This sounds like a lot, but the commitment to being able to *build* software as opposed to *using* software often is more significant.) For its small size, the Transterpreter is remarkably complex, considering all of the systems and software it interacts with.

So, I think that is a partial answer to your question. While Christian, Matt, and Jon are out of town, Adam or Damian might be able to help you. In particular, if you're trying to build all of this on either Windows (which is possible) or Mac (which might be more possible) so that you have a native big-endian robotics platform.

Note, though, that we've just started working through the endianness issues with what you're attempting (if you're trying for a native Mac PPC build). I'd suggest, if you go this route, that you join the Transterpreter discussion and/or developers mailing list, and ask questions there if you get stuck, as they'll be questions that our archives would benefit from you asking.


Keywords: robodeb , coursework

Question 84 (2006):

Submission reference: IN1112

will there be a model answer to the robotics exercise? I would be interested in such an answer as I think on a different path than I am meant to be with this whole exercise.

Answer 84:

We had not intended to release a model solution. However, if you're willing to wait, we can produce one. We don't have a "model" writeup either ... but that's not really worthwhile since our experiences are all different.

Remember, a significant part of this exercise was getting you to work through a *process*. The successful navigation of this process (of developing, testing, analyzing, and revisiting your code) should have provided material for reflection on the "experimental software process".

I don't mean for that to sound like some kind of hokey deal; a lot of our own explorations are on embedded platforms where we need to evaluate their performance in the real world, under real conditions. So, this is intended to provide a taste for some of that, as well as to get you thinking about how you might represent a solution to this problem in a concurrent process network (which we think is good for robotics).

Keywords: robodeb , coursework

Question 83 (2006):

Submission reference: IN1116

What sort of speeds are we aiming for? Mine works reasonable well at 50, but at 300 staggers around like a drunk and crashes into walls :(

Answer 83:

I forget, off the top of my head, what those speeds map to in the real world. They might be cm/second. At 300 cm/second, that would be 300 * 60 = 18,000 cm/minute ...... or 18,000 * 60 = 1,080,000 cm/hour ...... or 1,080,000 / 100 = metres/hr / 1000 = 10.8 km/hr (or ~7 mph).

Seven miles per hour is a slow jog – a reasonable walking speed is around 4 mph.

All of that, of course, is me just wondering how fast that really is. Assuming, of course, that the simulator maps those numbers through to some measure of centimeters per second.

I think we found that we had to keep the numbers really low with the real robot, or it would move faster than we could safely hit "CTRL-C" on programs that were running on it. For purposes of the assignment, we never considered speed; we were (as is explained in other answers) concerned about the software process you went through, your data, analysis, and changes made based on that data.

So, an interesting paragraph or two in your writeup has to do with your thoughts and reflections on why your robot doesn't seem to work at higher speeds. Is it because the runtime can't keep up? Or, is it something else? Why do you think that?

(Then again, the simulator could just be an inappropriate space for exploring this kind of thing. On the actual Pioneer robot, you have 700MHz dedicated to the processing and handling of events in the world. In the simulator, you are running a complex 2D environment and a client-server protocol, all on a VMWare virtual machine, which you are running in Linux on top of Windows. Therefore, your real-time performance is ... non-existent.)

You see my point? Run the robot at the speeds necessary to do what you need to do, and consider why that might be. We look forward to trying it out on the real thing, but will probably never run it at speed 300... because we're afraid of crashing our 10,000 robot. :)

Keywords: robodeb , coursework

Question 82 (2006):

Submission reference: IN1115

How good does the robot need to be in terms of keeping constant distance? Mine currently finds the distance to the wall when it starts, and keeps within about +/- 10cm of that distance. Is this fine or do we need to do more?

Answer 82:

Looks good to me ...

Keywords: robodeb , coursework

Question 81 (2006):

Submission reference: IN1109

In response to question 79, how do I read these files?

Answer 81:

The files "pioneer.inc", "sick.inc" etc. are plain text occam source codes. Generally, we use ".inc" and ".occ" suffices for occam source.

So anything that displays plain text files will do. For example, you can open it in the transterpreter jEdit window (though, unfortunately, we've not set up jEdit to recognise ".inc" as occam – so, we don't get nice colouring (yet)).

But any text editor will do. If you just want to scroll and browse, Unix provides the command:

    less <plain-text-file-name>

which opens the file and lets you scroll up and down it using the up/down arrow keys and Page-Up/Page-Down.

Keywords: robodeb , coursework

Question 79 (2006):

Submission reference: IN1106

How far apart are sonars 7 and 8? Thanks

Answer 79:

The dimensions of the simulated pioneer robot and the configuration of its sensors is defined in the pioneer.inc file (provided by the Stage simulator). On RoboDeb, the file is located here: /robodeb/local/share/stage/worlds/pioneer.inc.

Following is the relevant extract from the file:

  # define the pose of each transducer [xpos ypos heading]
  spose[0] [ 0.075 0.130 90 ]
  spose[1] [ 0.115 0.115 50 ]
  spose[7] [ 0.075 -0.130 -90 ]
  spose[8] [ -0.155 -0.130 -90 ]

I believe that the unit of xpos and ypos is meters (presumably offset from the centre of the robot). The rest of the dimensions of the robot can also be found in pioneer.inc.

The laser rangefinder is not defined in this file, but rather in: /robodeb/local/share/stage/worlds/sick.inc.

Keywords: coursework , robodeb

Question 77 (2006):

Submission reference: IN1090

I want to use the sonars to detect walls, but I don't get how we access one individually, even after reading:


Is there some easy way to say get the two right sonars, and the numbers that they generate? Thanks.

Answer 77:

You need to use the CHAN SONAR channels from the (various kinds of) brain.stem process and procs like get.min.S. To access these, we just need to have:

    #INCLUDE "player.inc"

at the start of our source code.

Having received a SONAR value from one of those channels (in.sonar below), you can access individual elements by subscripts (e.g. stuff[3]). For example:

    INT special:
    SONAR stuff:
      in.sonar ? stuff
      special := stuff[3]
      ...  etc.

This works as the SONAR type is actually a renaming of an array of integers type. To get the left and right sonar values, we can write:

    INT sonar.left, sonar.right:
    SONAR stuff:
      in.sonar ? stuff
      sonar.left := stuff[0]
      sonar.right := stuff[7]
      ...  etc.

Keywords: robodeb , coursework

Question 76 (2006):

Submission reference: IN1089

For the wall follower, can we assume that the robot will be placed in laser and/or sensor range of the wall? And will it be orientated any particular way, or does it need to orientate itself?

Answer 76:

Yes. Initially the worlds created for the assignment (Straight Wall, Circular Wall, Ninety Wall) starts the robot in sensor range of a wall and with the wall to its right (*I think*). You can assume that the robot will always start up in this position. When you run the robot yourself you might have to move the robot back to this position inbetween runs, either by moving the robot with your mouse or by quitting and restarting the simulator.

You are of course welcome to implement (as a challenge) an algorithm for your robot which can find a wall, when none are in sensor range. For example, just move in a straight line till you see something, assume it's a wall and follow it.

In case you missed the relevant terminal class, to get the worlds for this assignment, change to your home directory (on the Robodeb VM) and do:

    curl -O http://www.cs.kent.ac.uk/people/rpg/mcj4/20070222-co631.tar
    tar xvf 20070222-co631.tar

Now, under... (mercy, I don't have the environment to hand, because I'm in another country)... There's a "BeanCommander" or ... ah! "Commando". It adds some options to launch Stage worlds. (Make sure Stage, the simulator, is not running before doing this.) The worlds "Ninety Wall", "Circular Wall", and "Straight Wall" are the choices for this exercise.

Keywords: robodeb , coursework

Question 74 (2006):

Submission reference: IN1074

I've researched the robotics assessment and I found it would be a good idea to know (by experimentation or other means) the distance between the wheels (or tracks) on the robot, to work out the rate of turn. However, after talking to one of the supervisors I thought I was maybe going down the wrong path?

Answer 74:

Wow! That's impressive; yes, you might want to know that ... but perhaps you're working too hard?

The model is accurate, so that means the wheelbase is roughly 0.3m. You can look at the specs for the ActivRobots Pioneer3 on the WWW:


I don't want to discourage you from good investigations, but I'm not 100% positive you need to go down this path to address the question. That said, if you'd like to, you are welcome either to:

  1. find the information on the website; or
  2. make your best educated guess (note that the robot is to scale in the simulator)

So I hope that helps; it certainly isn't a question we anticipated.

Keywords: robodeb , coursework

Question 73 (2006):

Submission reference: IN1072

With the wall follower, is it meant to follow a wall on just one side? If not, how do we make the robot decided which to follow if there are walls on both sides that it can detect?

Answer 73:

This is a good question. (Actually, almost all questions are good questions, if you've thought about it before asking it. But I digress already.)

Were this an assignment that was primarily focused on your ability to control robots in the wild, we would obviously want your robot to be robust to these kinds of things. That is, we would expect to be able to put it in a hallway, set it running, and have it "figure out" what to do.

In this case, we gave you several environments where the robot is always to the left of the wall – or, if you prefer, the wall is always on the right. You may, for this assignment, make that assumption. In fact, I think we explicitly encouraged this in lab.

The point of the exercise is to go through a process – in this case, an experimental process where you implement an algorithm, collect data on its behavior, analyze and reflect on that data, and then based on your reflections, update your algorithm appropriately. We are not concerned with whether it is the worlds most elegant wall-follower – we're more concerned that you've gone through a critical aspect of the software engineering process, which is the ability to design, implement, analyze, reflect, and repeat.

Hopefully, that helps somewhat. If not, please feel free to ask more questions or make an appointment / mail us directly as necessary.

Keywords: robodeb , coursework

Question 72 (2006):

Submission reference: IN1071

In question 70 I was asking more about #INCLUDE files. I currently have "player.inc" and "pioneerutils.occ" included, but wondered if there were any others I should be using, or whether I should use these in the first place?

Answer 72:

You may use them. They are documented more fully at:


Follow the links to the documentation on that page. We do not believe your solution requires these libraries, but there is ample documented code if you wish to make use of them.

Keywords: robodeb , coursework

Question 70 (2006):

Submission reference: IN1043

For the wall following assessment, what files are we meant to include? Currently I just have vehicles.inc, but I'm guessing there might be others ... ?

Answer 70:

For programming the wall follower, you'll probably need the processes introduced in your early exercises with the robodeb material – for example, those for gathering the laser range finder data, finding the min or max of these, etc. To get those processes, include the files you used then. You may find the following URLs useful (of course, you do already know about them!):


    (look for the link: "All You Need Is Love")

Maybe you are asking about the files to submit for assessment? The handout for the robotics assignment is at:

    (look for the link: "Experimental Wall Following")

This indicates that the majority of your course marks will come from your lab writeup. While this may seem "different" or "uncommon," we are more interested in your writing and reflection on your code than just the code itself. (However, you will need to submit your code along with your report.)

You were encouraged to keep notes as you explored the problem of wall following, and collect data on your robot's ability to follow a variety of wall types. You should have analyzed this data (which may mean you charted it, or perhaps you counted events in the data, or performed some other kind of defensible analysis) and then made changes to your robot's wall following algorithm based on your analysis of that data.

Your lab report would (ideally) include code for your initial solution, your data, your analysis, and your improved code based on your analysis. It might close with some reflection on the process, and potential improvements you could make to both the data collection/analysis process and/or the algorithm itself.

This shouldn't be too surprising, we hope, as it was discussed in the lab as well as in the lab handout.

Keywords: coursework , robodeb

Question 47 (2006):

Submission reference: IN1012

Why does typing this into the xterm not copy my file?

    scp test2.occ z:/

or this:

    scp z:/ test2.occ


    scp bodiam:test.occ ./test.occ


    scp bodiam:test.occ ./test.occ

or anything? Can you give me the exact code I have to type to use scp?

I downloaded subversion to windows and it's just a blank command prompt I can't make it copy anything!

Answer 47:

First, I'm afraid there's a small rant. Then, we'll give some answers ... bear with us!

It's hard to know exactly where to begin. You need to grab a friend, or do some Googling, or make an appointment for some help. You are confused about how scp works. To begin with, you could start by typing:

    man scp

on a UNIX command line, and carefully read that document. Take notes. Experiment. Use your notebook to record what you did, what worked, and what didn't. If you don't work methodically through problems like these, you'll never learn. And, in case you didn't know, you're going to be continuously learning new tools and technologies for your entire career in computing/informatics, so developing these strategies sooner rather than later is going to be good for you.

Regarding subversion, it's pre-installed both in your VMWare image and on raptor. So, all you have to do is learn to use it. Try typing "subversion tutorial" or "subversion book" into Google. There are loads of tutorials and a whole book! The basics are outlined pretty early, and there are only a few commands you really need:

    svn commit


    svn checkout

However, again, if you're going to learn about version control (another common tool in computing), you're going to have to do some reading. By "some reading", I mean it will probably take you an hour or two of careful reading and experimentation. You can make an office appointment to help get you started, but we can only *teach* you, not *learn* you. Learning is something you have to do yourself.

OK, rant over ... :)

To transfer your file test2.occ from your VMWare linux to raptor, first change directory to the one containing the file. Now, assuming your raptor login is xyz42:

    scp mycode.occ xyz42@raptor:mycode.occ

will copy the file to your home directory on raptor. You will be asked for your raptor login password.

To copy it directly to, say, a sub-directory co631/robodeb/ from your home directory, the command would be:

    scp mycode.occ xyz42@raptor:co631/robodeb/mycode.occ

To restore this file from raptor back to VMWare, operate still from VMWare:

    scp xyz42@raptor:co631/robodeb/mycode.occ mycode.occ

If you are doing this from a PC, not on the university network, but connected to the Internet:

    scp mycode.occ xyz42@raptor.kent.ac.uk:co631/robodeb/mycode.occ

Humm ... actually, our firewalls might stop you making that connection. Will check.

Keywords: robodeb

Question 42 (2006):

Submission reference: IN971

Hi, for the Robo assessment, do I need to use the player library?

Answer 42:

The "player library" is a set of processes and utilities developed by (postgrads) Christian, Matt, Jon, Carl, and others who have worked on the Pioneer. See:


Both of these documents detail all kinds of things you can use in your solutions. I don't think, to make a simple wall follower, you need any more than positive.slice, negative.slice, etc. – basically, the processes that you saw in your first experience with RoboDeb. The point of the robotics control portion of the assignment is not to challenge you to develop new, complex algorithms for robotics control.

That said, you may want to have a bit more control than that provided by the few processes we showed you. In which case, you are welcome to explore the above URLs and make use of them in your solutions. There is nothing in them that is "advanced", so we did not "hide" them from you for fear that they would be "too much". They are there for you to use if you want to.

Keywords: robodeb

Question 35 (2006):

Submission reference: IN997

I can't transfer text from the VMware to windows, even after reading the comments for the other question (Question 29 (2006))about this.

Where can I find "subversion"? I can't find it anywhere, and I searched all through my home directory on raptor, and there don't seem to be any folders holding any files that I save! It's driving me crazy!!!!

I just wanted to copy and paste some code to ask you a question, but even that's not working. My code (painstakingly copied by hand) is something like this:

    -- proc that takes 1 chan int and returns 2 chan ints

    PROC chanDouble(CHAN INT in1?, in2?, out!)
      INT x1, x2, x3:
      CHAN INT cx:
          in1 ? x1
          in2 ? x2
          x3 := x1 + x2
          cx ! x3
          out ! cx

It gives the error:

    I/O list item 1 does not match protocol

and the line of the error is the "out ! cx". It's such a simple piece of code. Why isnt it working? And how can i use or find "subversion"?

Answer 35:

Possibly the simplest way to move files between your VMWare linux environment and anywhere else is to use the scp command. A Google search ("SCP manual") just found the following pages that should help you do this:


Subversion, which gives you a source control system, can be downloaded from:


but I think I'd find scp quicker to understand and use.

The comment above your PROC is a little misleading. Your PROC takes three INT carrying channels and doesn't return anything – once invoked, it never returns ... because its WHILE TRUE loop never terminates! Nevertheless, it can do useful work by accepting stuff on its input channels and generating stuff on its output channel.

Your internal declaration of CHAN INT cx: looks very wrong. If we declare an internal channel, it's because the implementation is going to go PARallel, with one sub-process being given the writing (output) end of the internal channel and another getting the reading (input) end. That doesn't happen in your code: in its loop cycle, it inputs two numbers from its two input channels, adds them together and then tries to output them down the internal channel (cx ! x3). At that point, it would get stuck since there is no process running in parallel and inputting from that internal channel.

However, your code doesn't compile because the line, out ! cx, says: "output the channel cx down channel out". But we can only send integers down channel out – not channels! Hence, the compiler's complaint.

Maybe you meant to output the result of the addition down (the external) channel out? If so, all you need is:

          out ! x3

Keywords: robodeb

Question 29 (2006):

Submission reference: IN872

Sorry if theres a real obvious anwser to this question that I'm missing but is there a way for me to save(/load) the occ files a create in RoboDeb to my Windows drive? (for the sake of organisation and keeping backups)

If the directory structure for RoboDeb stored somewhere on my Windows install?

If this isn't possible I can always FTP or email my files so not too much of a problem but is it safe to assume that anything save when using the VMWare will be secure and wont dissappear for next time I use RoboDeb? Thanks.

Answer 29:

The VMWare VM is "safe" to store your files on in one sense, and "unsafe" in others.

The VM saves its data where you installed it to. For most of you (all of you?) this was in your Raptor filespace. So, there is a file that represents "your" part of the VM virtual disk. It contains your data. So, as long as you don't delete *that*, you can launch the VM and work with your files. If that file is on Raptor, at least it is backed up.

Now, you're right in thinking that this is not exactly the best place to put your work. There are a few ways you can get things on/off the VM; you'll have to decide what works best for you.

Hopefully, that answers the question. If you have more questions, you can either post them here, or you can join the tvm-discuss mailing list:


This is a good place to ask questions and get answers that pertain to the Transterpreter itself or the RoboDeb VM. The whole TVM team is on that list, and we're glad to help make the tools better in any way that we can.

Keywords: robodeb , transterpreter

Referrers: Question 35 (2006)

Question 28 (2006):

Submission reference: IN871

Is there any chance we can get our raptor quota increased? I couldnt get 128MB free on my raptor account for the VM we needed to run the robotics occam, the lowest I could get it down to without deleting files from other courses was 90MB and our limit is 200MB.

Answer 28:

Done! The raptor filespace limit for all students taking Co631 has been increased to 350MB.

Keywords: robodeb , transterpreter

Valid CSS!

Valid XHTML 1.0!

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Last modified Mon May 20 13:50:32 2013
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.