|
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: IN1936
Hi, Having a small issue with the life on Mars assignment.
I know all the protocols are in the file mars-robot.inc, and I have stored it in the same folder as my mars-main.occ file (and indeed all the other files to do with the assignment), but my program can't find any of the protocols defined in it. The compiler keeps coming up with statements like "P.MOTOR.FEEDBACK. is not declared".
I was wondering if I needed to write an #INCLUDE statement for it, but I'm not sure. Any help would be greatly appreciated!
Make sure the file you are compiling is mars.occ, which has just 7 lines (3 comments, one blank, 3 includes). Do not try to compile the mars-main.occ file on which you are working!
If this is not your problem, contact your seminar leader or me (p.h.welch@kent.ac.uk).
Keywords: mars
Submission reference: IN1937
On the moodle page, it links to an example implementation for assessment 5 but "its solution for Task 2 is not entirely correct". I assume this means that you can spam move commands to the robot to make it slowly edge towards a hazard and eventually make it go through the hazard? At the moment, my robot will stop when it detects a hazard and moves back even if I've moved it very close to the hazard. I'm having difficulty thinking of a way to determine if a move command will increase the sensor value without actually moving it though. Any tips? :) I've come up with a few ideas but they will fail if say I move forward, get within hazard range, turn 180 and then move backwards.
Yes – the demo implementation is incorrect since it allows move commands to be sent that bludgeon the robot through obstacles.
The robot should move as commanded, unless a hazard level in the direction of movement is too high (and you have to decide what is "too high") – in which case, it should stop. (It doesn't need to back off, although that may be a nice touch and won't be marked down!) If a robot that stopped short is told to continue moving towards the hazard, it should not move! If a robot was moving forward and stopped (because a hazard was detected) and is then turned 180 and told to move backwards, that is still towards the hazard and it should not move.
The robot has two forward hazard detectors (front-left and front-right) and two backward detectors (back-left and back-right). These detector channels should always be monitored – the robot should always know the latest hazard level from all four detectors. See Question 40 (2010) and Question 32 (2010) (second paragraph in each answer).
Before and when moving forwards, the robot should check its forward hazard levels. Before and when moving backwards, the robot should check its backward hazard levels. To determine "if a move command will increase the sensor value without actually moving it", just check the relevant hazard levels.
Now, with the robot always monitoring all detectors (even when turning), its hazard levels will always have the most up-to-date values available. If the robot moves forward too close to a hazard and stops, one of its forward hazard levels was too high. If it then turns 180 degrees, its forward hazard levels will be OK and one of its backward levels will now be too high – if then asked to move backwards, it won't! :)
Keywords: mars
Submission reference: IN1943
A question for q7. For the first 10 or so seconds the philosophers sometimes eat even though the fork next to them is being used by a different philosopher.... after that they behave fine (I think!). I don't understand why this is happening because it was working fine a couple of days ago, :S
My secure.college process looks exactly the same as the one given in the assignment, with no changes made to it (except for the things the assignment wanted me to add) – the same goes for philosopher, fork and security ...
Maybe I'm missing something ... but are there any other places which affect when the philosophers eat?
Sorry – there's not enough here to diagnose your problem(s). If it worked before, then your current version must be different. When the philosophers eat is determined by when they get hungry and when security lets them in – there is nothing beyond those rules specified in the slides (3-14 and 32 of "applying") and implemented in your starter code (exercises\q7.occ).
Your code is faulty and you have to fix it. Check paragraph 4 of the answer to Question 37 (2010). If your system always goes wrong at the start, check that you always initialise variables (such as coordinates) before using their values. Try changing the eating time from the short random one (required for a good solution) to a long one (e.g. 30 seconds) so that you have more time to look at the screen and work out what's wrong.
Keywords: q7
Submission reference: IN1938
What is a "spurious move.complete" and why does my robot tell me that every time it finds a hazard?
I am reporting hazard.detected when one is found, but only move.complete when the move is completed (obviously), which it isn't if a hazard is found because I am telling the robot to stop.
The "spurious" messages are displayed if the mission.control process (back on Earth) receives an unexpected message from the robot.
If the robot is commanded to move and completes the move to the distance asked, it should report back move.complete. If the robot is commanded to move and does not complete the move (because it detects a hazard), it should report back hazard.detected only – it should not precede that hazard report with a move.complete! This is as specified in the life_on_mars PDF (section headed "Task 2"). If the robot replies with both messages, the first is taken as the full answer and the second as spurious.
Keywords: mars
Referrers: Question 57 (2011) , Question 57 (2011)
Submission reference: IN1939
My robot has trouble identifying the purple blob :( It can find all the others fine, but regardless of how close it is the the purple one, it just doesn't seem to detect it. Would the smaller size of the purple blob affect the robot's ability to see it?
The small blob in the environment given is violet, not purple. Apologies – I agree that's not terribly obvious!
Keywords: mars
Referrers: Question 48 (2010)
Submission reference: IN1941
For task 3 in Life on Mars, the task description says: "At the end of the search you should return the new heading of the robot relative to the heading you started at".
Will we lose marks if we return a relative heading of 120 degrees if the blob was located at a heading of 100 degrees? As the camera reports every 2 seconds, the blob may not be reported as soon as it comes into view, giving us an incorrect heading of the blob by the time it actually comes through.
Also: "If multiple matches are found, you may return any of them". Don't we specify a colour to look for, of which there will only be one? Or does this mean it should support returning any blob if there happened to be multiple similarly coloured blobs?
Yes, you will lose marks for this. You must return the heading of the blob from wherever the robot is pointing at the time of making its report. If the robot spots a target blob when turning, it should stop turning and wait for the next report(s) from the camera. If the robot hasn't turned too much since the target was spotted, the target will still be in the scan. If not, it'll have to turn back – it knows the target is there!
The environment given has only one blob of each colour. Other environments may have many blobs with the same colour. Your robot must be able to cope with this. Returning the first one found (if any) is a simple and valid policy.
Keywords: mars
Submission reference: IN1944
Hi, I've pretty much finished the animation for q7 but my problem is that one of my philosophers is missing, and s/he's not off the bottom of the screen. I've been to the homework club for 2nd years and they couldn't see any issues with my code. Turns out s/he isn't reporting but code seems to be correct. Any ideas as to why s/he isn't reporting like the others?
The screen coordinates are [1..80, 1..80], with [1, 1] being the top-left corner. Are you sure your missing philosopher isn't to the left, right or above the screen? Before you did the animation, did you have a display process that just output single lines reporting the messages received and, if so, were all your philosophers showing up then? If not, change your display to do this and make sure all philosophers are reporting. Check (look at your code) that each philosopher (and fork) gets the correct identity number. Check (look at your code) that all variables are initialised before their values are used. Look very carefully at the screen coordinates your philosopher animations are using. Find a way for the dislpay process to print them out, especially from the philosopher that's disappeared.
Hope this helps!
Keywords: q7
Submission reference: IN1942
In the Life on Mars assessment, I'm having problems comparing the colours of blobs seen by the camera with the colour input by the user.
During execution of the find.blob task, I'm printing the 'colour' INT passed in the find.blob; INT protocol, along with the blob[colour] from blob records that the camera sends.
The problem is that these never seem to be the same. Even after noting down the INT values for each colour the user can specify, I cannot see these reflected in the blob[colour] values. Worse yet, I can't match any reported blob[colour] values to any of the four known INT values of red/green/blue/purple ...
I assume that there must be some problem with receiving blobs from the camera, although I cannot understand what it is given that reported blob colours can't be matched with colours input.
You are looking at the right things: the INT colour requested for the target blob, the blob[colour] values received from the camera. When the camera has blobs within range, it sends blob data with colour fields set to the colours of the seen blob. For the environment you are given, these will be red, green, blue or violet (not purple – see Question 45 (2010)). When the camera has "rocks" (represented by parts of the Mandelbrot image shown) within range, it reports blob data with colour fields set to those of the seen rocks (which are not colours from the set of possible blob colours).
Sorry – can't help much here! If still stuck, mail your seminar leader or me (p.h.welch@kent.ac.uk). If there's an obvious mistake, we may point you at it ...
Keywords: mars
Referrers: Question 65 (2010)
Submission reference: IN1945
I appreciate that having separate PROCs for move/turn etc. is useful and allows for a 'cleaner' design; but would we necessarily have marks deducted for having the move/turn logic contained within the main robot.control process rather than in separate PROCs?
Clean engineering will always gain more marks than less clean engineering.
Having said that, if all you do is Task 1 (turn), you may get away with in-line coding within robot.control. But it shows a lack of forethought and ambition: the turn operation is needed for Tasks 3 and 4 – as is the move operation of Task 2. So, abstracting them into individual PROCs makes sense. If you do that, you may as well use them in Tasks 1 and 2 ... which may as well be the place to develop and test them.
Keywords: mars
Submission reference: IN1946
In Task 2 of the mars assessment, are we likely to lose a lot of marks if it goes through objects when multiple moves are called (similar to the demo application we are given)?
I'm also currently on task 3. After telling it to turn, my program just seems to freeze after turning 90 degrees and stays there on waiting on response. Does the output from the opr.resp channel (that turn sends data to) have to be stored somewhere ... rather than just sent down a channel that is only connected at one end?
Here is my current code which might demonstrate the above question a bit further:
... code deleted
Also the part of the assessment sheet (Task 3 still) that says: At the end of the search you should return the new heading of the robot relative to the heading you started at (as you will have rotated).
So does that mean if I turn 180 degrees, I should return 180 degrees as the new heading?
Yes – we've said that the demo implementation is deficient. You will lose marks if your robot can get moved through obstacles.
Blobs will only be reported to the robot if they are in its field of view, which is indicated by the longer red rays beamed from the robot. Your code starts its loop with a committed read (i.e. with no ALTernative) from the camera channel. So, if there are no blobs that the camera can see, nothing will be sent and your find blob process will wait forever. In the run you describe, it sees a blob (but not one with the target colour), turns 90 degrees, doesn't see a blob and gets stuck. Your loop should not start each cycle with a committed read from the camera channel!
I don't understand the last sentence of your second paragraph ... it doesn't parse well. Sending data down a channel copies the data – i.e. it's still stored in the variables used in the send command. It's only with mobile data (discussed in the last lecture) that the sender loses what it sends – that's not the case with your code. Why do you think the opr.resp channel is only connected at one end?
Yes, if you turn 180 degrees and find the target blob, you send back 180 (and the blob data, of course). Note that you may turn by any amount – not just by 90 degrees each time.
Keywords: mars
Referrers: Question 57 (2010)
Submission reference: IN1947
Are we allowed to use the Camera to move forward/backward? Indeed, Camera reports rock that may help to come closer.
Sorry, I don't understand your question.
You have to use the wheel motors (by sending commands to the motor.cmd channel) to move the robot!
Yes, the camera reports blobs when rocks come into its field of view ... just as it reports blobs when it sees artificial ones (that are the real targets).
Keywords: mars
Referrers: Question 53 (2010)
Submission reference: IN1948
Is it possible to loop over some code for a specified duration? Something like:
SEQ
tim ? t
PRI ALT
NOT (tim ? AFTER t PLUS 2000000)
... still waiting, do stuff
SKIP
SKIP
I've had a look over lecture slides and cannot find anything. I want to be certain I am receiving all the blobs from the camera before I start searching them for the correct colour.
Yes, but this is typically simpler than the code you have above. The "AFTER" operator can be used to test whether one time is after another, so can be used in conditionals. For example:
TIMER tim:
INT start, stop:
SEQ
tim ? start
stop := start PLUS 2000000
INITIAL BOOL waiting IS TRUE:
WHILE waiting
INT now:
SEQ
tim ? now
IF
stop AFTER now
... still waiting, do stuff
TRUE
waiting := FALSE
There are probably better (more elegant) ways to code this, but that should do what you want. If you really wanted to use an ALT with a timeout it could be coded something like:
TIMER tim:
INT t:
SEQ
tim ? t
INITIAL BOOL waiting IS TRUE:
WHILE waiting
PRI ALT
tim ? AFTER (t PLUS 2000000)
-- timeout reached
waiting := FALSE
SKIP
... still waiting, do stuff
However, this is polling a timer ...so probably isn't the best way to go about it. How about:
TIMER tim:
INT t:
SEQ
tim ? t
INITIAL BOOL waiting IS TRUE:
WHILE waiting
PRI ALT
tim ? AFTER (t PLUS 2000000)
-- timeout reached
waiting := FALSE
BLOB blob:
camera ? blob
... check out this blob (if target, set waiting FALSE)
? That's much better, :). Now, it only does stuff if the camera sends a blob or the timeout happens – and this is the basic pattern for setting timeouts on waiting for things to happen!
You may need some more stuff in the above ... so that you can tell whether you exit the loop because you found the blob or timed out.
Keywords: timers , mars , polling
Referrers: Question 61 (2010)
Submission reference: IN1949
I am sorry if you did not understand my previous Question 51 (2010). I asked if we are allowed to use the Camera to write the move process. I have seen that the Camera reports Rocks from the hazard, so it can help to come closer. Am I right?
Ah, I think I understand now – I think you mean: are we allowed to use information received from the Camera in the implementation of the move process?
Yes. But there is no need to do this ... when moving, the robot needs to avoid hazards ... so monitor the hazard channels!
I guess you're thinking of checking out the size field of the BLOB data returned by the camera? But the camera gives no distance information ... so a large blob could just be a very large blob a long way away ... i.e. not a hazard!
Keywords: mars
Submission reference: IN1950
I am searching a way to cast a REAL32 into an INT. On the Occamdoc, I find a way to convert a REAL32 into a string and then a string into an INT. Is there a way to do it more directly?
Yes! You can directly cast a REAL32 to an INT – see Question 53 (2008) (which asks exactly the same question as you) and check under the keyword-index cast for other questions on casting. See also slide 30 of "basics" and the example program: examples\casting.occ.
Keywords: cast
Submission reference: IN1951
I am using kroc on Mac and I have a problem that I do not understand. I have a code that does not work if I use the Transterpreter but works if I use the command line to compile and launch the executable. For example:
PROC my.proc(..., BLOB blob)
...
WHILE loop
ALT
BLOB b:
camera ? blob
...
:
I am using the BLOB I get in my PROC parameter. If I do not have the "BLOB b:" before the line "camera ? blob", the code does not work. Is this a bug?
Your code fragment has illegal indentation and a missing response process to the camera input guard of the ALT. Correcting this (and filling in gaps to get something compilable) gets:
PROC my.proc (CHAN CAMERA camera?, BLOB blob)
INITIAL BOOL loop IS TRUE:
SEQ
WHILE loop
ALT
BLOB b: -- spurious declaration (the questioned line)
camera ? blob
loop := NOT loop -- silly code
camera ? blob -- more silly code
:
Using kroc on my Mac, the above compiles whether the spurious declaration is present or not. Same with the Transterpreter on the Mac. I've not tried with the Transterpreter on Windows – it should also be the same though. All systems use the same compiler. Send me (p.h.welch@kent.ac.uk) your code if it still won't compile!
Keywords: alt
Submission reference: IN1953
Is there any chance of a FORWARDing keyword to be made e.g.
out ? FORWARD in
which, if in and out were channels carrying INTs, would be the same as:
INT i:
SEQ
in ? i
out ! i
This would be very useful in the case of variant protocols e.g.
out.variant ! FORWARD in.variant
This would replace:
INT i, j, k:
in.variant ? CASE
x.case; i
out.variant ! x.case; i
y.case; i, j
out.variant ! y.case; i; j
z.case; j, k
out.variant ! z.case; j; k
which would be much smpler to write. I think this would be useful if you were writing an id process for variant protocols, or in channel bundles wanting to send a request and then forwarding on the response (e.g. having a main control process in mars robots and then forwarding the response from a process (turn etc) to the operator response channel).
Either that or being able to store a variant protocol as a variable e.g.
VARIANT OPERATOR.RESPONSE variant.variable:
-- where OPERATOR.RESPONSE is a protocol that the VARIANT is a type of
INT result:
in ? CASE
turn
variant.variable := turn.complete
... do turn
move
variant.variable := move.complete
... do turn
... later
out ! variant.variable; result
This would reduce the amount of coding where the output on a variant protocol is dependent on the input on a variant protocol. A permutation of that would be to save the whole output in the protocol e.g.
variant.variable := turn.complete, result
Or something like that.
You are right that routine forwarding/buffering of messages carried by variant protocol channels is tedious (though trivial) and that something should be done about it.
One proposal is for union types, which give you something like the variant.variable in your question. This, together with an idea for automatic dynamic memory allocation (which saves memory bloat), look promising for the future.
The current list of enhancement proposals for occam-pi can be browsed here.
Keywords: mars , protocol , union
Referrers: Question 30 (2011)
Submission reference: IN1952
Hey, this is in follow up response to my earlier Question 50 (2010): "Does the output from the opr.resp channel (that turn sends data to) have to be stored somewhere ... rather than just sent down a channel that is only connected at one end?"
You reply: "I don't understand the last sentence of your second paragraph ... it doesn't parse well. Sending data down a channel copies the data – i.e. it's still stored in the variables used in the send command. It's only with mobile data (discussed in the last lecture) that the sender loses what it sends – that's not the case with your code. Why do you think the opr.resp channel is only connected at one end?"
My question is this. Inside my PROC find.blob, I use my PROC turn and this sends data down a channel that is declared in find.blob (this channel is only connected to PROC turn and nothing else). This causes PROC find.blob to stop/freeze up and left waiting on response. But when I connect the turn response to the actual CHAN P.OPERATOR.RESPONSE that is used to send feedback about whether it has found a block, it works up until it the move command gets a response (I'm guessing it's because it was expecting a find.blob appropriate message rather than a turn message). So how are we supposed to deal with the messages that are generated by PROCs that we don't need?
Sorry for the mass of text above but it was the best way I could come up with to demonstrate my question.
OK – you have the turn (and move?) logic abstracted into a PROC. This logic looks like it includes sending the response from the turn (or move) back to the operator. This is too big an abstraction – it's doing more than one thing: making the turn (or move) and reporting back to the operator. Better is to have an abstraction that only makes the move (or turn), letting its invoker know through result reference parameters (how much it turned/moved, whether a hazard was encountered). Now, the invoker can report back to the operator (which you need for tasks 1 and 2) or not (which you need for tasks 3 and 4).
But your turn tries to report back. Within find.blob, connecting its report channel to one that doesn't go anywhere (as you first describe) just means deadlock – a process has to receive the report and there is none. Connecting it to the actual CHAN P.OPERATOR.RESPONSE causes a run-time error for the reasons you guess. I suppose you could connect the report channel from your turn to a black hole process (which you would have to write and run in parallel with your code inside robot.control) – but you would still be left not knowing the result of the turn (or move).
So, the answer to your question is: don't generate those un-needed messages! Reduce your turn (and move) abstractions as described in the first paragraph of this answer and all is simple, :).
Keywords: mars
Referrers: Question 56 (2011) , Question 56 (2011) , Question 58 (2010) , Question 58 (2010)
Submission reference: IN1954
Sorry but I have another question regarding my Question 57 (2010). I have looked through the lecture slides but can't see any reference to "result reference parameters". What exactly do you mean by this?
Result parameters are those which are only used to return results from a procedure call. They can be thought of as the opposite of VAL parameters (which only pass data into procedure calls), though that's a bit vague. As a simple example:
PROC add (VAL INT a, b, RESULT INT v)
v := a + b
:
...
INT x:
SEQ
-- 'x' not defined here
add (42, 15, x)
-- 'x' is now defined and is 57
Added by PHW: I didn't present formal RESULT parameters in the lectures and they are not examinable. In my answer to Question 57 (2010), I didn't mean anything formal by the word result – my emphasis was on reference parameters. Fred's add process works the same without the RESULT keyword in the parameter declaration of v. The only difference is in the semantic checks made by the compiler. With the RESULT keyword, the compiler checks that it is not used in the body before it is assigned and that it is assigned (either by an assignment or an input). Without the RESULT keyword, the compiler assumes that it has some value when passed which may be used in the body before being changed – we assume it will be changed since, otherwise, it should have been passed as a VAL parameter.
So, when a parameter is being used only to return a result (as in add above), declaring it as a RESULT parameter increases security – as the compiler checks it is used in that way. When a parameter is used to deliver a value to a PROC and to return a result, it should be a reference parameter – i.e. no keyword. When a parameter is used only to deliver a value to the process, it should be declared as a VAL parameter.
Keywords: result
Referrers: Question 49 (2012) , Question 56 (2011) , Question 60 (2010)
Submission reference: IN1955
Hi, Could you explain what motor.feedback returns during movement in the Mars animation? It returns degrees when turning, as stated in the help pages but I've not been able to fathom its output during straight movement. Thanks!
On the Life on Mars web page, it says:
You can't tell the robot to go forward 60, but you can tell it to go forward, add up all the values for the amounts it moves and stop when that value is 60.
So, you may assume the values from the motor.feedback channel when moving are in the same units (probably millimetres) as the distance the robot has been commanded to move.
Keywords: mars
Submission reference: IN1956
I'm experiencing an embarrassingly stupid problem with reading a value on a channel into a variable.
PROC a (CHAN INT a?)
CHAN INT b:
INT output:
SEQ
some.proc (a?, b!)
b ? output
... do stuff with output
:
"some.proc" hangs when it outputs on b because I guess nothing picks up the value. Can you please suggest what I need to do to get this to work? The compiler warns about sequential input/output on b but I can't think how else to express that I just want the value on that channel assigned to a variable.
The code you have above tries, in SEQuence, to output then input on the same channel (b). Because channel communication is synchronous, the output (inside "some.proc") will just block, because there is no parallel process to communicate with. That process ("b ? output") cannot run until the call to "some.proc" completes, because of the SEQ, thus deadlock. The answer is to add some parallelism, e.g.:
PROC a (CHAN INT a?)
INT output:
SEQ
CHAN INT b: -- only needed for the PAR (declare stuff only where needed)
PAR
some.proc (a?, b!)
b ? output
... do stuff with output
:
This assumes that "some.proc" only outputs once on "b" and then terminates, else the "... do stuff with output" won't be able to run. If "some.proc" outputs repeatedly on "b" (and maybe never terminates), you would need something like:
PROC a (CHAN INT a?)
CHAN INT b:
PAR
some.proc (a?, b!)
INT output:
SEQ
b ? output
... do stuff with output
:
On the other hand, if your "some.proc" does only output one value down the "b" channel, it's much simpler to return that value through a reference parameter – i.e. not to use a channel and the first PAR code above. Question 58 (2010) introduces the (non-examinable) concept of RESULT reference parameters, which would be ideal for this – for example:
PROC some.proc (CHAN INT in?, RESULT INT answer)
... puts some value into 'answer'
:
PROC a (CHAN INT a?)
INT output:
SEQ
some.proc (a?, output)
... do stuff with output
:
The above code will work the same without the RESULT keyword qualifying the "INT answer" reference parameter. Having the keyword improves safety, since the compiler checks that "answer" is not used before it is given a value and that it is given a value (at least once) before "some.proc" terminates.
Keywords: channels , seq , par , result
Referrers: Question 56 (2011)
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
