|
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: IN2094
Task 3 of the mars assessment.
If the robot turns a full rotation (360 degrees), and hasn't found anything so therefore stops find.blob execution, should it return a value of 0 for new heading or is 360 acceptable?
The instructions for Task 3 say: "return the new heading of the robot relative to the heading you started at". A heading of 360 degrees relative to the initial heading is the same as 0 degrees – so either figure is acceptable.
Keywords: mars
Submission reference: IN2095
For the Mars assessment, Do we just submit mars-main.occ?
Thank you for this question. Perhaps we did not make it crystal clear! The fourth bullet of the Getting Started section of the Starting out on Mars web page says: "mars-main.occ. This is the file you'll spend your time editing, and eventually submit, as detailed in the submission guidelines." I've updated those guidelines in the Assessment 5 box on the Moodle page and repeat them here for convenience:
Please only submit your edited mars-main.occ file, together with process network diagram(s) if you have used concurrency in your implementation of the robot.control process. Network diagrams can be in the formats approved for earlier assessments (or could be handed in to the CAS office on paper with signed cover sheet). If you have changed any of the other files in this assessment's set of files, you must also submit those – together with a README file explaining the changes you have made. [Note: we do not expect you to have changed any files (other than mars-main.occ, of course)].
Keywords: mars
Submission reference: IN2096
Super Simple Question:
Will our marks be affected by the efficiency of Task 4?
My demo answer takes a pretty long time for the rover to find its way to very roughly the midpoint between the two blobs. Sometimes it fails completely (e.g. when too many obstacles are in the way it wants to move).
Following a strategy that takes a long time to find a place, very roughly, where the sensor is to be deployed will definitely not be penalised!
Of course, unnecessary inefficiencies in lower-level logic will continue to be penalised.
As always, your code must be elegant and clean – well-chosen PROCs that abstract coherent pieces of logic, no repeated sections of code with only trivial differences (e.g. magic constants), sensible comments explaining aspects of your code that are not obvious (e.g. the high-level search strategy you have devised), etc.
Keywords: mars
Referrers: Question 69 (2011)
Submission reference: IN2097
Regarding Mars:
I'm having some trouble getting the hazard detection to work as I would like. I can receive the values and act upon them easily enough when moving – the problem is checking them prior to moving. I would like to check them before the robot moves; for example in the case were the robot has stopped for a hazard and then told to move again towards that hazard. I want the values I had previously so that I can prevent the robot from ever moving, until it’s facing/moving away from the hazards.
The problem is that the values aren’t persistent since the move proc ends so I have to request new values. However, the hazard monitor doesn’t have new values since they only update when the values change (i.e. whilst moving).
I can see how I would do this with a request system: have my monitor run continuously, and ask for the hazard values whenever I need them, and then just keep asking every set amount of time whilst moving. However, this sounds like a bad solution. I would rather keep a system similar to my current one, in which I ALT on the hazard channel and respond based on the values. However I can't get it to work as a check before movement and at the same time work whilst moving.
Any tips or advice would be appreciated. :)
As you say in your last but one paragraph, a request solution (see the answer to Question 59 (2011)) works but is awkward and inelegant – as it depends on choosing a suitable polling interval between requests (see the Postscript in the answer to Question 59 (2011)). The rest of that Postscript describes an elegant modification to this, but leaves you with a challenge to implement it in a way that avoids any possibility of deadlock.
The solution to that challenge is an example of a general, and very useful, concurrency pattern: the cancellable service. This is an extension to the pure client-server pattern (see Overview slides 39-43). In a cancellable service, a client can interact with a server in the normal way (send a request message, wait for reply). However, the client can also send a cancel message, following its request, if it has a reason that it no longer needs that service. The server must be able to receive and deal with such a cancel, even though it may be about to send a reply to the client – without causing deadlock. Dealing with a cancel would mean undoing any state change made in the server as it processed the now-cancelled request. Something to think about ... ;).
There's a sequential way to solve this problem (i.e. without installing a concurrent hazard monitor that provides a cancellable service) that may be easier.
You said: "the hazard monitor doesn’t have new values since they only update when the values change (i.e. whilst moving)". That's true, but hazard values also change when the rover is turning. They could also change if other moving obstacles (e.g. other rovers) are on the scene – although that doesn't happen in the simulation environment you have been given. To cope with this, all hazard channels must be observed at all times and the most recent warning levels kept up to date. Of course, this is what a a concurrent hazard monitor does.
But this can be done sequentially. The robot.control process has various states that it goes through is various sequences: wait for an operator command, do a turn, do a drive, do a find and do a deploy. So, listen to the hazard channels when doing all these things, keeping the latest warning levels in an array that is passed to all implementing PROCs (as a reference parameter, of course). Then, when asked to do a drive, you have the current hazard levels in that array – so you can check before moving. The important thing is to monitor the hazard channels when turning, even though that information is not relevant for the turn itself. Although not necessary for the environment we have given you, monitoring the hazard channels when waiting for mission control commands is trivial to add (and useful, in case of aliens or other robots).
Everything said in the last two paragraphs applies also to monitoring the camera channel – just save the latest BLOB. Then, when told to find one and the rover is stationary, you may already have it!
Keywords: mars
Referrers: Question 68 (2011)
Submission reference: IN2098
Hi, I've been working on the move and turn parts of the mars assessment. I seem to have implemented the sensor section correctly, as my robot stops for obstacles, but refuses to stop other than this. Currently, I have a while loop that only runs while the total amount moved/turned is less than the amount given by the operator. This is worked out by adding each value being received on the feedback channel to the total distance travel. I can't seem to figure out why its not stopping.
This sounds similar to the problem reported in Question 55 (2011). Check out its answer – especially the paragraphs following the one starting: "There are other problems though ...". Also, check out Question 58 (2011) and its answer – this question reports the same problem, but the mistake was for a different reason.
If these don't help, you have to post more information on your code. I'll edit out too much information before replying.
Keywords: mars
Referrers: Question 67 (2011)
Submission reference: IN2099
Can we leave the debug dumps (log!) in our code (I use it to display all the calculations and steps)?
If I leave it there, it messes up the operator response part of the output.
If you have masses of log reports and the screen output is too messy, please comment them out ... but read on ...
A better way (than commenting) to switch on and off debugging reports is to declare somewhere close to the top of your program:
VAL BOOL debugging IS TRUE: -- for no debug reports, change to FALSE
and then to wrap all debugging reports with:
IF
debugging
... sequence of "log !" reports
TRUE
SKIP
Then, you can easily switch off debugging with a single-line change of the declared VALue of debugging to FALSE.
Set this FALSE for your submission. If your program does not work for some tasks, include a README.txt file in your submission that says what does not work and mention the debugging reports in your code and how to switch them on. Making it easier for your markers is always a good idea!
Submission reference: IN2100
In response to my earlier Question 65 (2011) about the never ending while loops, here's my code for the turn process. I've had a look at both the previous questions and they still don't solve my problem. Here is my turn process:
PROC turn (VAL INT distance, CHAN INT output!, CHAN INTERNREP feedback?,
CHAN P.MOTOR.CMD sigsender!, CHAN P.MOTOR.FEEDBACK info?)
... code omitted
:
The feedback channel in here is to gather info from the sensors. It delivers two items: a BOOL that indicates if the sensor is from the front or the back, and then the threat level.
Also, is it possible to use the AND operator to determine whether two expressions are both true? I've switched from using nested IFs to this method while debugging my code, but the computer is coming up with an error.
[Note: although this answer is about code that is not shown, it should be worth reading by those other than the questioner since it describes misunderstandings about the problem and errors in approach that may be of help generally.]
You use the IABS function correctly on the info channel tick counts to accumulate always a positive total amount of turn. But you should also use IABS on distance (the commanded amount of turn) when checking to see if that total exceeds the commanded amount. Otherwise, if the turn were anti-clockwise (i.e. distance were negative), your loop would never end.
You also wait (inside the loop body) for sensor information (warning you about hazards) from your feedback channel. If none arrives, your code blocks at that point until some comes. Meanwhile, the rover keeps on turning and you keep missing ticks from the motor feedback info channel. It's not that the loop keeps looping ... it just gets stuck! This is almost exactly the same mistake as pointed out in Question 55 (2011) (the paragraphs following: "There are other problems though ...").
Also, if and when you do get sensor information from your feedback channel, the code you sent does nothing with it ... possibly because of the question you raise in your last paragraph?
In that last paragraph of your question: when you say "the computer", I assume you mean "the compiler"? If so, you must be having trouble with the syntax of boolean expressions containing boolean operators (AND, OR, etc.). Remember that occam-pi has no binding precedence for any of its operators – for the good reason that it's hard to remember them! So, when writing expressions with more than one operator, we must bracket them to group them in whatever way we want (what-you-see-is-what-you-get). For example:
IF
(x > y) OR (x > Z)
... do something
TRUE
... do something else
or:
WHILE (distance.turned < absolute.distance) AND (danger < theshold)
... do something
Hope that helps ...
Keywords: mars
Referrers: Question 71 (2011)
Submission reference: IN2101
This is in response to my earlier Question 59 (2011). I have included some code that probably requires omission.
So far I have implemented it where hazard.monitor works in a client-server fashion, and move continuously checks the values until it reaches the destination. However I think I am polling? There doesn't seem to be an obvious solution to implement it in a non-polling fashion.
PROC move (VAL INT move.mm, BOOL success, INT driven.mm,
CHAN P.MOTOR.CMD motor.cmd!,
CHAN P.MOTOR.FEEDBACK motor.feedback?,
CHAN BYTE log!,
CHAN BOOL hazard.enquire!,
CHAN [HAZARD.SECTIONS]INT reply?)
INITIAL BOOL forward, continue, hazard.detected IS FALSE, TRUE, FALSE:
[HAZARD.SECTIONS]INT hazard.value:
SEQ
success := FALSE
... get latest hazard values (from hazard.monitor process)
... if no hazards in movement direction, issue drive command to motors
IF
continue -- i.e. drive command was sent
CHAN BOOL stop.motor.monitor, stop.check.hazard:
PAR
SEQ
... loop that listens on 'stop.motor.monitor?' and 'motor.feedback?'
channels. If anything on 'stop.motor.monitor?', exit loop.
If anything on 'motor.feedback?', accumulate tick counts in
'driven.mm' and exit loop if 'move.mm' is exceeded.
stop.check.hazard ! FALSE
... loop that polls 'stop.check.hazard?' (from above process) and
exits loop if anything is received. In the loop, if poll fails,
get latest hazard values (from hazard.monitor process) and,
if hazard found in direction of travel, send 'stop.motor.monitor!'
message (to break the loop in the above process), wait for
'stop.check.hazard?' message, set 'hazard.detected' and exit loop.
TRUE
SKIP
motor.cmd ! stop
success := NOT hazard.detected
:
I'm unsure if there is chance of deadlock here? I haven't experienced any and it appears to work fine.
I have also managed to implement this move process in a sequential fashion where hazard levels are checked, then motor feedback and it loops back round. I believe this isn't too great though, as it reports it has moved 10mm closer to the hazard than when it detected it.
Not bad, :), ... but there is the chance of deadlock (see below) and unnecessary inefficiency (busy polling). You also have a trivial typo error in your code for detecting hazards in the direction of travel of the rover (use of the 'BACK.RIGHT' index twice, instead of 'BACK.RIGHT' and 'BACK.LEFT').
Polling cannot be avoided with this design, since you have to send a specific request to the 'hazard.monitor' process (the second of your PAR components) at the same time as watching 'motor.feedback?' (the first of your PAR components) to see if the target distance has been reached ... and occam-pi does not support ALTing between a send and a receive.
However, your polling is needlessly busy! Your second PAR component gets new hazard levels each time the poll on 'stop.check.hazard?' fails (which takes around two or three nano-seconds and will almost always be the case). This is far too often and will keep a processor core at 100% and very hot! Rather than PRI ALT against a SKIP guard, PRI ALT against a timeout (set for, say, every tenth of a second ... which should be often enough, given the slow speed of the rover). The rover movement should be the same, but the processor loading should now be minimal (along with demands on its battery ... which is a key consideration for any embedded application).
Deadlock can happen with your design as follows. The loop in the first of your PAR components exits because the requested distance, 'move.mm' has been exceeded. At roughly the same time, the loop in your second PAR component detects a hazard and sends a 'stop.motor.monitor!' to the first component. That first component is no longer listening, because it's exited its loop and is trying to send a 'stop.check.hazard!' to the second component. Deadlock!
This deadlock is unlikely to show up ... but that's not acceptable! One day it will happen. The rover is on Mars and may be tricky to reboot, :(. There is a (fairly simple once you know it) way to avoid such deadlocks – and it's the same solution as is needed for implementing the cancellable service pattern (described in the answer to Question 64 (2011)).
However, it may be simpler to follow the suggestion in the last sentence of the Postscript of the answer to Question 59 (2011). For your code, combine the two PAR components into a single loop that ALTs between 'motor.feedback?' and a timeout (every tenth of a second). Respond to a 'motor.feedback?' in the usual way (exiting the loop if the target distance is achieved). Respond to a timeout by getting the hazard levels (exiting the loop if a hazard is detected). Simples, :).
The above may be close to the "sequential fashion" you mention ... but please use timeouts (not busy polling)! From your description, it sounds like you only check the hazard levels after every 'motor.feedback?' ... which is wrong (and would account for the 10mm overrun you report). You need to ALT ... as described in the preceding paragraph.
Hope this helps.
Keywords: mars
Referrers: Question 69 (2011)
Submission reference: IN2102
Hello, With regards to Question 63 (2011), what kind of inefficiency will be penalised?
Is it code-wise or in solving the task? I make a ridiculous number of sweeps over the same territory. My robot has amnesia.
Code-wise. We will penalise programming inefficiencies that are needless ... like busy-polling (see the answer to Question 68 (2011)), recalculating the same thing more than once, testing variable values that don't need testing, searching more of an array than needs to be searched, etc.
Strategic inefficiencies in the plan for solving Task 4 will not be penalised ... so long as they are not too gross and easily avoided. A strategy that is infinitely inefficient (i.e. has no chance of success) will, of course, be penalised. A strategy that takes a long time, but gets the rover roughly to the required deployment point, is fine!
Keywords: mars
Submission reference: IN2103
all the tasks have been complteded, thing is, i never get a message back on the terminal. the robot moves/turns etc sucessfully, but then does nothing. im sednign the correct value on the operator respone channel, and the right hting happens on the screen. but just no messages on the termianl. any suggestions on how to fix this?
If you send a correct message on the opr.resp! channel, it will be relayed to your screen. For example, just try sending:
opr.resp ! turn.complete; 42
as an immediate response to any turn request (i.e. without actually doing anything!) to see the response relayed to your screen.
If your program turns the robot successfully (as seen in the animation window) but your screen shows nothing, it's because your code has not reached the line in your code where you send your response to opr.resp!. Try adding log! messages – e.g.
out.string ("===> turn complete, about to send response ...*c*n", 0, log!)
just before your opr.resp! message. Do you see that log! message? If not, put in more log! messages further back in your code (e.g. into the loop in your turn logic ... does that loop ever exit?).
Time is short, but hope this helps!
Keywords: mars
Submission reference: IN2104
my hazards dont seem to be working. currently, i have a process that takes an array of hazard channels, and stores the values that come in on each of them using a replicated alt. it then sends that value out, zlong witha boolean variable to detrmine whither it is the front or the back set of sensros to any prcess that is connected to it, such as my move rpocess. the move prcess cheks the boolean to see if the sensor data is related tot he direction it is traveling in, if it is, then it should stop the rover. but it doesdtn seem to be. what would be the best thing to do to solve this?
How often does your move process listen on the channel from the process you describe that forwards specific hazard warnings? Does it listen inside a loop in sequence, or in parallel, with listening to the motor feedback channel? If so, that is the same mistake as reported in Question 67 (2011) (para starting: "You also wait ...") and Question 55 (2011) (para starting: "There are other problems though ..."). Your problem is also similar to Question 58 (2011).
Please read carefully through those Q&As.
Keywords: mars
Submission reference: IN2143
hi, with regards to the exam, what would happen if we were to answer all the questions in part B, instead of only answering two?
Part B has three questions and the rubric says to answer exactly two of them. If you answer three, I don't know the official answer. However, what has (I think) usually happened in the past is that all three answers will be marked and the two with the highest marks will be accepted as your formal answers (i.e. the answer with the lowest mark will be discarded).
Please note that this is not an official answer. For an official answer to the procedures for managing exam rubric errors by candidates, you must ask the University Exams Office.
Keywords: exams
Submission reference: IN2142
Supposing you have a process "plex" that ALT's over two incoming INT channels:
PROC plex (CHAN INT in.0?, in.1?)
WHILE TRUE
SEQ
INT x, y:
ALT
in.0 ? x
SKIP
in.1 ? y
SKIP
:
... with "plex" called using two "numbers" processes:
PROC main (CHAN BYTE in?, out!, err!)
CHAN INT a, b:
PAR
numbers (a!)
numbers (b!)
plex (a?, b?)
:
Since only one guard is executed, why does the program not block? Will both x and y be set (and only a single body executed)? Could I write the following?
INT x, y:
ALT
in.0 ? x
SEQ
out.int (x, 0, out!)
out.int (y, 0, out!)
in.1 ? y
SKIP
In every loop of your plex process, only one ALT guard is executed – i.e. a communication from either one of its input channels is taken. Your main process does not deadlock since its two numbers processes will always offer to send messages and plex will always take a message from one of them. Were you forgetting about the WHILE-loop in your plex?
The last fragment of code in your question is wrong because the y variable in the second call to out.int is undefined. This fragment executes as follows: it waits for a message on either of its input channels; if it takes a message from in.1, it does nothing else; if it takes a message from in.0, it catches it in variable x and outputs ASCII bytes for its decimal representation down the out channel (which must carry BYTEs, otherwise the fragment of code would not compile) and then tries to do the same for the integer value in variable y ... but that value has not been set anywhere ... which makes no sense and is not allowed.
Keywords: alt
Submission reference: IN2144
Consider the following top level processes:
PROC main.1 (CHAN BYTE out!)
out.int (1, 0, out!)
:
PROC main.2 (SHARED CHAN BYTE out!)
CLAIM out!
out.int (1, 0, out!)
:
The first prints "1", whereas the second prints nothing. Adding a FLUSH (or newline) "fixes" it.
Why does a SHARED channel introduce this behaviour?
First, I confirm getting the same behaviour that you report (using KRoC under Ubuntu, version 11.04, Linux).
The need to flush characters sent to the screen channel depends on the operating system (if there is one) in which the occam-pi program is running. Both in the KRoC support for occam-pi (compiled code plus multicore scheduler) and in the Transterpreter (interpreter), we have tried to provide the behaviour that is normal for Unix standard output (which is that characters are buffered until either the buffer is full or a special flush character is received).
What happens to characters still in the Unix standard output buffer when a program ends is a grey area. It would be OK simply to discard them, as happens with your main.2 program. It would be OK to flush them out, as happens with your main.1 program. However, we ought to be consistent about this and we will see if we can do that!
Thank you for your question. It is really about the interaction between the occam-pi system and its host operating system. Please be assured that such matters are not part of the syllabus for this module and no questions requiring such knowledge would be asked in the exam on this module.
Keywords: flush , shared-channel
Submission reference: IN2145
In the exam are we expected to implement fair alting if the question doesn't explicitly ask it?
Nope — if fair-alting is required, it would be asked for (indirectly though perhaps).
Keywords: fair-alt
Submission reference: IN2151
I am trying to run the Transterpreter, yet I get the error message "CreateProcess returned false" and thus cannot run the transterpreter.
This sounds like a problem actually launching the Transterpreter. Check that the paths specified in the JEdit plugin (assuming you are using that!) are actually accessible from where you're trying to run things. If the compiling part works fine, then running things should too. Failing that, can you provide any more details? (or ask your class supervisor during one of the terminal sessions; it may be easier to diagnose the problem when it's in front of us).
Keywords: transterpreter
Submission reference: IN2150
Hi, I was curious as to what options were being offered after I returned from my year in industry, so had a look at the modules currently being offered. I remember someone saying that there was an advanced concurrency module and was curious as to why it's no longer running, given that the vast majority of pcs in use these days are multi core systems?
Very many apologies to whoever asked this question so long ago (2 Aug 2012). We didn't know how to answer this properly. Belatedly, I (Peter) will have a go.
We've had the advanced concurrency module (Co632) prepared for several years, first presenting it in the academic year 2006-2007. Sadly, that was the only year we were allowed to offer it. The withdrawal of the Co632 option was a decision taken the the Board of Studies (now the Learning and Teaching Committee) for the School of Computing. The reason was the need to reduce the number of options offered, prompted partly by course restructuring (with more compulsory modules) and partly by falling staff numbers (voluntary redundancies). Each year, we have tried to reinstate it – without success. If anyone would like to get the Co632 materials, please contact me or Fred Barnes.
For information, next year (2012-2013) is the last year this module (Co538) will be offered. Further restructuring of the degree means that Concurrency will become part of the core (compulsory) modules, but probably spread over Stages 2 and 3. Final arrangements (timing, contents) have still to be settled. It will likely be very different from Co538.
My personal belief is that concurrency is fundamental to Computer Science and should be introduced at the same time as sequence is introduced in programming. So long as a sane concurrency model is taught, going parallel is no harder than looping and communicating between processes is no harder than assignment between variables. Start early and it will be easy.
Keywords: advanced , teaching , future
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
