|
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 coursework
2009 |
Submission reference: IN1839
The coursework in Co538 is probably the most time consuming of all modules, I don't mind I think it's fun, however it seems very unfair that only 20% of the marks are coursework.
Why are there so many marks associated to a few hours long exam when our programming tasks will take us many more hours and probably show more our level of in depth understanding.
It would be nice to get an explanation of your thoughts on this matter. Thanks.
The aim of the coursework is to let you explore in depth the ideas being presented in the lectures. Without this, any learning you do will be fragile and untested. Doing the coursework lets you discover what you don't understand, since solutions cannot be found without real understanding. Without doing the coursework, you will not discover that you have not understood something and, therefore, will not be able to correct that misunderstanding.
Also, we hope that the coursework will be fun – and are glad that you and finding it so, :). Fun is essential for most things, so we try to make the coursework interesting and fun since we really want you to want to do this work ... because we really want you to understand!
Now, hours! Assuming a 40 hour working week (most of us work much longer!) and 4 modules to study during term, that's 10 hours per week per module. This module has 3 contact hours per week (2 lectures, 1 seminar), so that's 7 hours per week for your own study on this module. Some of that will be spent reading the slides, background papers and talking to / teaching / learning from colleagues. Much of the former will be driven by solving the challenges set out in the coursework. The last two coursework assignments span several weeks (at least three), so it should not be surprising that each may take between 10-15 hours – maybe less, maybe more.
Now, exams! For this module, this is 3 hours work during the exam ... but, of course, an awful lot more in preparation for it. In fact, all the work you spend on your coursework is preparation for your exam. You cannot succeed in your exams without understanding – in depth – the material and, as reasoned above, you cannot do that without the coursework.
Therefore, if the coursework were zero weighted, you would have just as much motivation for doing it. Note that in my definition of the aim of our coursework, the grading of students is not included. Grading is the purpose of the exams, which provides a level playing field for every student in conditions where there is a recorded audit trail of how the work is produced and how it is graded (that can be, if necessary, challenged).
The exam seeks to let the student demonstrate understanding of the concepts and mechanisms presented in the module. It does this by asking for simple explanations and by applying them to solve short problems (that are either hard or impossible to solve without that understanding). The exam does not expect or seek a rote reproduction of material from, say, the course slides. The exam will not penalise trivial mistakes in syntax, say, that would not be made if a compiler were to hand – or, indeed, any material available from the web (e.g. the course slides). It's the ability to explain and apply that is all important. And that is very difficult to achieve without doing the coursework.
Summary: the coursework is there to help you learn, the exam is there for you to show us that you have learnt. It's not just the 20% from your marked coursework that is the achievement of all that coursework. It's the 80% from your exam, which would be near impossible without it.
Keywords: coursework , exams
2006 |
Submission reference: IN1174
Did we get additional marks for using shared channels on the dining philosophers assessment?
[Ed: this question has been combined with the following for a single answer.]
There is not much feedback on my dining philosophers assessment, I did not even know what the mark was out of until my friend told me, I would like to know what I lost marks on... seen as my dining philosophers worked and had additional features within it. Who can I ask about this?
Using shared channels simplifies the solution, which may result in a higher mark. Extra marks were allowed for shared channels, protocol inheritance etc., but markers had freedom to award other marks for specially nice things. Quality (e.g. simplicity, no repetitive lengths of code differing only with magic numbers) and animations beyond the minimum requirement were the main sources of extra marks. Marks over the maximum were not allowed though! Extra marks usually compensated for minor ommisions/errors in otherwise good solutions – resulting in a maximum score.
I'm sorry if your returned script contained little feedback. Some contained a great deal! Below is the marking scheme and guidelines given to the markers, which should let you see how your marks were awarded. If you think your marks do not represent a fair assessment of your work, please contact me (phw@kent.ac.uk) directly. Thanks.
=====================================================
Dining Philosophers Animation - Marking Scheme (2007)
=====================================================
This year, they do not have to submit diagrams if their solution is the
standard one (i.e. 11 reports channels from the college to a multiplexing
display ... or 1 SHARED report channel from the college to a display).
If they have done something else, they were asked to provide a diagram
(e.g. a GIF, JPG etc. image in their submission directory or hard copy,
could be hand-drawn, handed in to CAS).
However, it would be harsh to penalise those who have something more ambitious
(e.g. with extra animation processes) but a poor diagram. So, treat those
diagrams as aids to understanding their system - but no penalty if no diagram.
Give additional marks for more ambitious animations. The basic animation
(run ./a7 on raptor at /proj/ofa/631/answers/) is all they need for full marks.
This year, I never got around to specifying any keyboard interaction - e.g.
for setting the random number seed to a known start value ... or for freezing
the display. Award extra marks if any do this.
Here is the breakdown:
4 : decent PROTOCOL declaration(s) - deduct 2 marks if no commented
explanation of any component fields of, for example, tagged variants.
CHAN INT report channels, reporting VAL INT *named* codes, are OK
but only get 3 marks.
7 : the philosopher PROC - roughly 3 marks for random timeouts when
thinking/eating (and for getting/setting the seed correctly and
uniquely) plus 4 marks for making sensible reports. Note: the
seed should be set *once* before starting the philosophers and
passed to each philosopher (who adds his-her id number). I gave
them a random number warm-up PROC in the anon Q-and-As (Q55) that
they should use - but no penalty if they don't.
3 : the fork PROC - for adding sensible reports.
3 : the security PROC - for adding sensible reports.
4 : the code for the networks - 2 for the modified secure.college (with
all the report channels) and 2 for the top-level network code.
9 : the display PROC - 2 marks for some sensible initialisation;
6 marks for everything else. This year, we also never got around
to making them work out fair alting, :(. Extra marks if they did,
though this is only relevant for a report array. Award extra marks
if they used a SHARED channel, and more if they used PROTOCOL
inheritance (so that the phils, forks and security had their own
protocol and the report channel itself combined all three).
----
30
----
Keywords: q7 , coursework
Referrers: Question 30 (2008)
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: IN1106
How far apart are sonars 7 and 8? Thanks
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
Submission reference: IN1107
How do I get square root in occam?
Something like this:
REAL64 x:
SEQ
x := DSQRT (64.0)
...
out.real64 (x, 0, 0, scr!)
or, if you're using 32-bit floats:
REAL32 x:
SEQ
x := SQRT (64.0)
...
out.real32 (x, 0, 0, scr!)
The two integers (0 and 0 here) specify the number of integer places and number of decimal places — 0 means "as many as required".
Keywords: coursework , libraries
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:
http://www.transterpreter.org/wiki/Pioneer_Sensor_Library
Is there some easy way to say get the two right sonars, and the numbers that they generate? Thanks.
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:
SEQ
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:
SEQ
in.sonar ? stuff
sonar.left := stuff[0]
sonar.right := stuff[7]
... etc.
Keywords: robodeb , coursework
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?
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
Submission reference: IN1092
I asked Question 71 (2006) a few minutes ago, it was very helpful. I've altered my program and now I have an output, I'm using one shared channel. So far the security guard and the phils are sending information down it. Phils 0 and 1 seem to be getting all the attention of the security guard now though.
I can't see how my display proc would cause this discrimination but thats the only proc I've added, and I haven't even altered anything else that much yet!
Sorry to include so much code, but I can't see how else to show you what's going on ...
... PROTOCOL status
... PROC display (CHAN status in?, CHAN BYTE out!)
... PROC q7 (CHAN BYTE keyboard?, screen!, error!)
where q7 runs the college in parallel with a display process connected by a single channel carrying the status protocol, shared by all the college processes at the writing end.
Sorry, I've edited out most of your code in your question. Your system now has a good structure. I don't know why you aren't seeing phils 2 through 4 getting past security – you didn't submit all their codes. But we couldn't answer it even if you had. I'm afriad this is not a debugging line ...
Keywords: q7 , coursework
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?
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:
http://robots.mobilerobots.com/
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:
So I hope that helps; it certainly isn't a question we anticipated.
Keywords: robodeb , coursework
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?
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
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?
You may use them. They are documented more fully at:
http://www.transterpreter.org/wiki/RoboDeb
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
Submission reference: IN1086
I'm having some difficulty outputting what's going on, I've tried using the below code to output what the philosopher is doing and what philosopher is doing it. However, currently nothing is coming out.
I have three constant which are thinking, eating and waiting of int values 1, 2 and 3, these ints are set in the philosopher PROC then output to print.stream along with which philosopher it is (i). Can u give me any help with this please?? :(
PROC secure.college ()
[5]CHAN BOOL left, right, up, down:
[5]CHAN INT status:
[5]CHAN BYTE screen:
PAR
security (down?, up?)
PAR i = 0 FOR 5
PAR
philosopher (left[i]!, right[i]!, down[i]!, up[i]!, status[i]!)
fork (left[i]?, right[(i+1)\5]?)
print.stream (10000, status[i]?, screen[i]!, i)
:
Stop, stop, stop, stop using print.stream ... that prints a single stream of integers to a single screen channel ... it was only ever of use in questions 1 and 2 ... it has absolutely no use for this assignment!
Your secure.college process above has no (channel) parameters – so there is no way it can get any results out anywhere, let alone to the screen.
You have attached status channels carrying integer codes: one from each philosopher – that's reasonable (though a variant protocol would be better). But each of these status channels is then connected to its own print.stream process which outputs to its own screen[i]! channel. That tries to send ASCII text down that channel – but none of those channels are connected to anything! Thus, each print.stream blocks which means that each philosopher blocks ... which means the whole system deadlocks (the forks and security are waiting to hear from philosophers).
As shown in slide 60 from applying.ppt and discussed in the lecture and in seminar groups, those status channels should be external output channels (i.e. parameters) from your college and there should be a display process, running in parallel with the college, that multiplexes in all the status channels and generates (animation) text to the screen. You also need 5 more status channels from the forks in the college, plus one more from the security guard.
Keywords: q7 , coursework
Referrers: Question 75 (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 ... ?
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!):
http://www.transterpreter.org/wiki/Pioneer_Sensor_Library
http://www.transterpreter.org/wiki/Teaching
(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:
http://www.transterpreter.org/wiki/Teaching
(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
Submission reference: IN1040
Where do we submit the dining philosophers and robots?
For the dining philosophers, submit your solution by placing it on raptor in the directory: /usr/local/proj/co631/dining/login/, where login is your login. If you have a network diagram, etc. submit these on paper via CAS.
For the robots assessment, you should submit your report on paper to CAS. Submission directories for your code will appear presently.
Keywords: coursework
Submission reference: IN1060
I'm just trying to work out the shared channel business and I have come up with a shared channel array of 26 'CHAN INT's. 15 for the philosophers: 1 for thinking, 1 for sitting and 1 for eating therefore 3 states * 5 philosophers = 15. 10 for the forks as two states (left, right) * 5 philospohers = 10. Finally 1 for the security to report on. Which ever channel I get an input on I then know what has happened and who by, is this a good way of doing it?
It works, but I wouldn't say it's a good way. There are two pieces of information you're trying to communicate here: who is doing it, and what it is they're doing. Probably best to keep these separate. Having a single channel for each of the philosopher, fork and security processes (11 in total) makes sense — that tells you who is doing it. As for what they're doing, using a tagged-protocol would make sense — this makes that information explicit, and definitely makes it easier to modify — without having to rewire other bits of the network.
By the way, the forks have 3 states (on-the-table, picked-up-by-left-hand, picked-up-by-right-hand) – not 2.
Keywords: q7 , coursework
Submission reference: IN1059
Does the display process only need to take one array of channels from all of the the process that are reporting to it? If so then I assume this channel will be shared among the philosopher, fork and security procs?
Yep, that's pretty much correct. But your second sentence is inconsistent with your first. Your "this channel" suggests splitting a single channel up amongst the various processes; whereas you talk about an array of channels in the previous sentence.
What you should do is give each of the philosopher, fork and security processes a single channel
from within an array of channels –
see slide 60 from applying.ppt.
As described in the lectures, you can do it with a single channel
– and it's much easier (especially for the display process, which
then only has one channel to deal with).
But that means using a SHARED channel and CLAIM blocks,
as presented in slides 3-26 of shared-etc.ppt.
Note: there is some stuff relating to shared-channels in previous anon Q+A, but these use the old-style which involves SEMAPHOREs and explicit claim and releases (not particularly nice, but these were before the days of mainstream occam-pi).
Keywords: coursework , q7 , shared-channel
Referrers: Question 68 (2006)
Submission reference: IN1054
Hi, I'm working on the dining philosophers assessment but I'm not doing too well. I have attended the classes, seminars and most of the lectures but am still struggling. I understand what we are supposed to do and have a rough idea of how to do it, but i just don't know where to start. Can you give a rough outline of how to go about it, so i know what to do and in what order?
Also can you explain the following PROC? I understand the others given in the q7 starter file, but this one confuses me:
PROC secure.college ()
[5]CHAN BOOL left, right, up, down:
PAR
security (down?, up?)
PAR i = 0 FOR 5
PAR
philosopher (left[i]!, right[i]!, down[i]!, up[i]!)
fork (left[i]?, right[(i+1)\5]?)
:
Starting with your second question, the secure.college process sets up a network
of parallel sub-processes. If you look at the relevant lecture slides (available from the
module directory on raptor, slides 36-39 of applying.ppt/pdf), you'll see a picture of the process network which this creates.
It creates a PAR network containing one security and five each of
philosopher and fork. Each philosopher has two channels connecting it to
the security process, and two channels connecting to the forks on either side. The modulo operator
(\) is used to wrap-around the channel connections -- e.g. the last fork (where i+1
is five), needs to connect to the first philosopher (the modulo 5 sets it to zero, which is the same
index as the 0th philosopher's 'right[i]' channel (because i is zero).
With regards to starting the assessment, I'd begin by creating an outline for a display process which will take input from the various philosophers, forks and security (via an array of channels), and generating output to the screen. I would suggest having the display process outside of secure.college — and running in parallel with it, so there will be some channels connecting secure.college to display.
The next step would involve allowing the various philosopher, fork and security processes to output to the display. If you have modified secure.college to have a channel-array parameter, this means distributing those channels to the various processes — i.e. adding single-channel parameters to the processes which will generate output to display. From there, get those processes to generate outputs, which the display process receives. It might be sensible to start with simple INTs being reported to display, but to do any serious level of reporting you'll proably want to use a tagged-protocol.
Before coding, it's wise to start with a process-network diagram of what you're trying to code — design first, then implement! The wealth of q7 related questions from previous years will also be helpful.
Note: you say you have attended seminars and lectures. All the above has been presented – in detail – in the seminars and lectures.
Keywords: q7 , coursework
Submission reference: IN1051
Dear Sir, I've been trying to introduce a pause into my program but I'm getting an incorrect indentation error. I know I must have made simple mistake somewhere, but i can't understand why and where this error is. I'm just wondering if you could give a hand in getting rid of this error.
PROC philosopher (CHAN BOOL left!, right!, down!, up!)
... local variable declarations
SEQ
... local variable initialisation
WHILE TRUE
--{{{ think
SEQ
... random delay code
--}}}
--{{{ get permission to sit down
down ! TRUE
--}}}
--{{{ pick up the forks
PAR <----------- Error-occ21-q7Edited.occ(53)- incorrect indentation
left ! TRUE
right ! TRUE
--}}}
... more stuff
:
Somehow you've managed to damage the existing contents of the WHILE loop. Removing the opened fold comments from your loop body leaves:
WHILE TRUE
SEQ
... random delay code
down ! TRUE
PAR
left ! TRUE
right ! TRUE
... more stuff
The error on the PAR is because you don't say whether this should run in parallel or in sequence with the SEQ above it. The problem is broken re-indenting of code, e.g. that PAR should be part of (indented inside) the SEQ, not alongside it.
Look again at the starter file code for philosopher (with all the folds open) and compare it with your code – there's no reason for code inside a fold to start at an indentation level different from the fold markers (which is what's happened in your code).
Keywords: q7 , coursework
Submission reference: IN1037
Hi, I've just got started on the assessment but I've come to a problem. Some of my code in my display process is:
[11] CHAN INT x:
WHILE TRUE
ALT i = 0 FOR 11
in[i] ? x[i]
print.stream(0, x[i]?, scr!)
As you can probably tell, I'm just trying to get the outputs working first before I make the animation. So, I'm printing using print.stream for now to debug.
However, the fourth line above is causing this error:
Error-occ21-q7.occ(145)- I/O list item 1 does not match protocol
I can't work it out!
The array 'in' is presumably a channel array from the display process header.
You should input INTs from CHAN INTs — your code is currently attempting
to input into another channel (x[i]), which doesn't make sense;
hence the error regarding protocol mismatch.
You probably meant for x to be an array of INTs
– not CHAN INTs!
However, your use of print.stream is very wrong.
That process runs forever, consuming numbers and printing them.
So, after receiving its first input from channel in[i],
it runs print.stream forever taking numbers from that same
channel – assuming you plugged in that channel and not x[i],
which is either a channel (as in your code, but which is wrong as there
is no process outputting to it!) or an integer (which it should
be, but is illegal here!).
No data from any other channel would ever be taken.
I've no idea what numbers are arriving on your in[i] channels
... but if you just want to print them, just print them:
ALT i = 0 FOR 11
INT value:
in[i] ? value
SEQ
out.int (value, 0, scr!) -- print the number
out.string ("*c*n", 0, scr!) -- carriage-return and line-feed
Note that the above sequence prints one number (see out.int). Using print.stream would lock this process in to the channel and print the whole infinite series of integers that arrive.
Note further that it only makes sense to use an array of values (e.g. [11]INT x:) if you have some need to keep the last reported state from each channel. If you intend to handle them on an individual basis, just use a single locally declared variable (like value in my snippet).
I also question the use of the magic number 11 all over the place — name this as a VAL INT constant at the top-level somewhere.
Keywords: coursework , q7 , out.int
Submission reference: IN1058
Would I be right in saying that the only way to identify which philosopher is doing what is to do the reporting after this line:
philosopher (left[i]!, right[i]!, down[i]!, up[i]!)
in secure.college? My rationale being that this is the only way to identify each channel as we have access to the 'i' variable.
No. It doesn't make much sense to try and do reporting in SEQ with the philosopher instance (which is part of a network of parallel processes). The philosopher process has a WHILE TRUE loop, so it won't terminate – nothing following in SEQ after it will ever run. Changing that loop into one that terminates means placing another loop around the philosopher invocation and your reporting process. Your philosopher then comes into existence and terminates repeatedly. This is not a nice way – it makes the code hard to understand (and is the sort of thing you normally end up programming C/C++/Java/etc.).
The only process which knows what a philosopher is doing currently is the philosopher process. Keep the philospher reports there. If you want each philosopher to be able to identify themselves, simply pass its index, i, as a VAL INT parameter to the philosopher procedure. You'll probably need to add some other things too – like a report channel! There is no way for the philosopher to report its actions at present (and deducing it from interactions with security and the forks alone would be complex – and probably wrong).
Keywords: coursework , q7
Referrers: Question 55 (2007)
Submission reference: IN1036
I was wondering how you would do a double variant protocol. I want to have a variant to express the types (philosopher, fork, security) as well as having a separate one to indicate the actions. Currently I have:
PROTOCOL FORKSTATUS
CASE
on.table
left.pickup
right.pickup
:
PROTOCOL MIXEDSTATUS
CASE
philosopher; INT; BYTE
fork; INT; FORKSTATUS
security; INT
:
But when I say:
report ! fork; id; left.pickup
it complains about left.pickup not being defined. Also to how would I make this readable in the CASE statements, because I would somehow need to say something like:
report ? CASE
INT id:
BYTE status:
philosopher; id; CASE
You can't do this, as you say, handling the input sensibly is hard. The normal approach would be to define some constants and use these. What we really want is an enumerated type, but until then, something like:
-- fork status values
VAL INT ON.TABLE IS 0:
VAL INT LEFT.PICKUP IS 1:
VAL INT RIGHT.PICKUP IS 2:
PROTOCOL STATUS
CASE
fork; INT; INT
...
:
...
Keywords: coursework , protocol
Submission reference: IN945
This is probably an issue with my icky code but it is worth checking. KRoC produces:
Fatal-occ21-q7.occ(162)- internal inconsistency found in routine "chan_direction_of -- not channel"
*********************************************************************
* The compiler has detected an internal inconsistency. *
* Please email kroc-bugs@ukc.ac.uk with a copy of the code which *
* broke the compiler, as this is probably a compiler bug. *
* Please include the KRoC version and any other relevant details. *
*********************************************************************
The offending code fragment is:
INITIAL MOBILE []CHAN BOOL down IS MOBILE [num.phils]CHAN BOOL:
So, what's wrong? Am I doing something silly or did I find a bug in KRoC? (I highly suspect the former rather than the latter!). I've not yet tried in the Transterpreter, I guess this would be a good plan...
I'd expect the Transterpreter to fail in the same way &mdash it uses the same compiler. The problem is a compiler bug, of sorts. Dynamic mobile arrays of channels are not entirely well supported, as you've discovered. The issue is that the compiler isn't allowing you to refer to the whole array 'down' (when you attempt to pass it as a parameter to another procedure).
Unfortunately I'm way too busy at the moment to fix compiler bugs (until June/July at least), so you'll have to find another way to code what you want.. Sorry :-(. But logically, what you're trying to do is sane.
PHW writes: all you're trying to do (I think?) is declare an array of channels with 'num.phils' elements. In the above, you've adapted a line from 'print.streams' that declares an array whose size is computed at run-time (from the size of the channel array argument it was passed). Your adaptation is logical but, as Fred says, the compiler does not yet support all aspects of dynamic array allocation – such as for channels.
However, if 'num.phils' is a compiler-known value (not a variable set at run-time) – e.g. it is declared somewhere towards the top of your file by:
VAL INT n.phils IS 5:
then you can use it to declare a fixed-size array of anything, including channels, trivially – for example:
[num.phils]CHAN BOOL down:
That should be all you need? :)
Keywords: coursework , q7
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
