|
CO538 Anonymous Questions and Answers |
This page lists the various questions and answers. 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.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
When asking questions, please do not simply paste in your code and ask what is wrong with it, as these types of question are hard to answer in a public forum (resulting in either no answer, or an answer which will only be of use to the person asking the question). In many cases, a question about code can be formulated in general terms. For example, if you have an `IF' block that results in an `incorrect indentation' error, you might ask, ``what is the correct syntax for an occam `if' statement ?''. Questions of this form are easier to answer, and are meaningful to all.
Questions that are not suitable for these public pages (i.e. those that contain assignment-specific code), should be mailed to your seminar-leader.
Submission reference: IN1109
In response to question 79, how do I read these files?
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
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?
Looks good to me ...
Keywords: robodeb , coursework
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 :(
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
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.
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
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?
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
trunk/applications/player/player2.0
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.
http://www.transterpreter.org/wiki/SVN_Download
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.
http://www.transterpreter.org/wiki/Mailing_Lists
Keywords: robodeb , coursework
Submission reference: IN1094
In the class you wrote down an ALT used for timing yet still taking in
data, but I didn't get the final version written down.
You made some adjustment that meant the timing period was only calculated once I think.
Could you give me the code again?
Thanks.
Hi – you need to be a bit quicker taking notes ... we did spend almost an hour on this!
All we were doing was waiting for either a channel input or
a timeout.
occam-pi has a particularly simple, efficient and elegant mechanism for
such things – the ALT.
Here is the process we developed.
It's a clock process that ticks with a regular, but resettable,
period.
It doesn't do anything until a period is supplied (down its reset channel):
PROC clock (CHAN INT reset?, CHAN BOOL tick!)
TIMER tim:
INT timeout, period:
SEQ
reset ? period
tim ? timeout
timeout := timeout PLUS period
WHILE TRUE
PRI ALT
reset ? period
SKIP
tim ? AFTER timeout
SEQ
tick ! TRUE
timeout := timeout PLUS period
:
Note the standard idiom when setting up a sequence of regular timeslices: check the actual time just the once ... then calculate the first time-out time before going into the loop. Inside the loop and when a timeslice ends, calculate the next timeout value from the last one – i.e. don't check the actual time again and calculate from that:
tim ? AFTER timeout SEQ tick ! TRUE tim ? timeout -- this is a mistake timeout := timeout PLUS period
because that means the timeslices will not have regualar periods. If the above were coded, the time betweem timeouts is period plus however long you have to wait for the tick to be taken plus however long it takes to check the time and calculate the next timeout.
With the original code above, the time betweem timeouts is period ... at least, the run-time system will do its best to make it so. If sometimes it takes more than period microseconds before the tick is taken, the next timeout will follow immediately. So long as that doesn't keep happening, the system will get back on schedule – the code is real-time stable.
There is an argument for checking the actual time again on receipt of a reset period. Suppose the current period were 10 seconds and we were 2 seconds into this when a reset arrives telling us to start ticking every second. The code given above would wait until the end of the currently defined period – i.e. another 8 seconds – before the next timeout occurs and, then, it starts ticking every second. [My windscreen wipers work like this when on intermittent sweeps: when I switch them to speed up, they wait until the end of (long) period before changing speed.]
Depending on the application, that may not be acceptable. If not, there is an easy solution:
PROC clock (CHAN INT reset?, CHAN BOOL tick!)
TIMER tim:
INT timeout, period:
SEQ
reset ? period
tim ? timeout
timeout := timeout PLUS period
WHILE TRUE
PRI ALT
reset ? period
SEQ
tick ! TRUE -- immediately start a new sequence of ticks
tim ? timeout
timeout := timeout PLUS period
tim ? AFTER timeout
SEQ
tick ! TRUE
timeout := timeout PLUS period
:
Now, if a reset to 1 second arrives 2 seconds into a 10 second period, it immediately starts ticking with the lower period (= faster rate). Whether that immediate tick in response to the reset should be done should be discussed with the engineer who is going to use this device. It's easily removed!
Keywords: timers
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.
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:
http://www.transterpreter.org/documentation/occam-pioneer-robotics-library.pdf
They are documented further – with diagrams – at:
http://www.transterpreter.org/wiki/Pioneer_Sensor_Library
Keywords: robodeb , coursework
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.
The exercise is defined by:
http://www.transterpreter.org/documentation/teaching/20070222-experimental-wall-following.pdf
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)
Submission reference: IN1123
Exactly what do we have to submit for the robodeb assessment?
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:
\proj\co631\wall\<login-name>\
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)
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 ...
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
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.
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)
Submission reference: IN1137
Hi, for Question 91 (2006), how can I make the robot turning away from objects? Thanks.
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
Submission reference: IN1149
Hi, what should happen if out robot is placed facing the wall? Should it reverse or stop? Can it reverse?
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
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:
WHILE TRUE
SEQ
x := 100
output ! x
:
-- Caution
PROC follow (CHAN MOTORS moto!, CHAN LASER sick?)
CHAN INT motor.right:
CHAN INT motor.left:
WHILE TRUE
PAR
number(motor.left!)
number(motor.right!)
two.motors(motor.left?, motor.right?, moto!)
:
-- Main
PROC main (CHAN BYTE kyb, scr, err)
CHAN MOTORS moto:
CHAN LASER sick:
PAR
brain.stem.ML (moto?, sick!)
follow (moto!, sick?)
:
Kind Regards.
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:
http://www.transterpreter.org/documentation/occam-pioneer-robotics-library.pdf
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:
PAR
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:
PAR
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:
PAR
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:
WHILE TRUE
PAR
number(motor.left!)
number(motor.right!)
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:
WHILE TRUE
SEQ
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
Submission reference: IN1142
What size are the grid squares on the worlds?
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:
window
(
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
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 :(
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
Submission reference: IN1154
Hi, at the moment I only have these two processes in my robot:
... code deleted
Does it look reasonable to you? Is there any improvement I can make?
Sorry – we can't answer questions like this here. This forum is for specific questions about the course material. Please see paragraph 3 at the top of these pages.
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?
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
Submission reference: IN1153
Do we need to put the data and/or log books in the raptor directory?
Yes please. Any format we can read is OK ... plain text or PDF or Word DOC is good.
You could also hand in a real (hard copy, pasted bits of code, hand scribbled) logbook if you prefer. But that needs to be at CAS before they close tomorrow. If there are no cover sheets in the Co631 pigeon hole, just ask for one. Tell them it's for Co631 Assessment "A6 - Robotics Exercises".
Referrers: Question 100 (2006)
Submission reference: IN1157
Are we going to submit our reports online?
Yes please. See Question 99 (2006). Just copy them to your submission directory on raptor (Question 89 (2006)), along with your source code file(s).
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
