|
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: IN1682
Hi im trying to use the log CHAN for debugging the life on mars thing but nothing's happening. E.g.
out.string ("x", 0, log!)
Am I doing anything wrong? I tried sending a FLUSH afterwards as well, but so far nothing is happening...???
We've tested the log channel, and it appears to work in all the cases we tested. The problem may lie in other parts of your code, as what you have done and explained in your question should work (the flush is important, as you note, when using the TVM).
If you need further assistance, you should contact your seminar leader with the actual code in question.
Keywords: mars
Submission reference: IN1695
In lifeonmars task 2, what integer hazard.detected amount is considered "too close" ?
You can experiment with the simulation, driving the robot through the wall (assuming it isn't doing hazard detection already) to see the hazard values as it approaches and hits the surface, and choose a value that you feel is appropriate. You could use a hazard value of 9 as a boundary between 'acceptable' and 'too close'.
Keywords: mars
Submission reference: IN1691
I always have strict on, however unlike all the other assignments, with the 'life on mars' assignment, are you aware that a load of error messages spew out of the compiler when strict is on?
Since we intended for you to be using the Transterpreter, and do not tend to use the --strict flag to kroc ourselves, we didn't notice these messages. They do not affect the functioning of the simulation.
Keywords: mars
Submission reference: IN1693
For Life On Mars, when implementing turn, it states we should expect to actually turn a few degrees difference to the amount specified. In order to do this there obviously needs to be a check of degrees actually turned against degrees requested. Am i right in assuming we should keep going til equal or more than request, and that we should not stop short when we are a few degrees less than the request?
If you are integrating the ticks that come back from the motors you will most likely have a value which stores the amount that has been turned in total. It doesn't make sense to stop the turn early, because you may be able to turn exactly to the required heading, but you may find you are over because the ticks add up to more than the amount required. Stopping short is not really a natural property of the system, and is not something we would expect. The expectation would be +1 on most values, but I have posted below about the acceptable tolerances.
Keywords: mars
Submission reference: IN1692
Hi, In lifeonmars, so far I have implemented turn and move as their own PROCs. However, there are two problems I have encountered, both stemming from this: I'm not sure how to communicate back to the robot.control process from these new PROCs. Firstly, in find.blob I can't call turn as I'd like to because it's turn that's outputting turn.complete signals (and so when I call it from find.blob, a signal is received that isn't expecting and things break). Secondly, I need move to communicate the current status of the hazard detectors to some variable somewhere, so we don't move forward until the hazard status changes everytime (e.g. we might be at 9, move forward, hit 10, and then we've crashed). The first problem I could (untidily) solve with a boolean parameter saying whether to signal or not. Or I could research into MOBILE stuff, but that seems overly complicated. It seems like there must be an easier way that solves this problem and the second one too. I can't add parameters to the robot.control process beacuse it's called externally with the set parameters. So adding communication channels to the other processes is out. So I'm a bit stuck! Any hints?
You can use processes and channels inside the robot.control process, with their own protocols. You probably don't want to let the turn & move processes reply to the messages, because this will impede their re-use later on (as you have found). You could use a client/server protocol internally between your main loop and these other processes, asking them for the action and returning the relevant results to your control process - which can return the appropriate variables. You shouldn't need to modify the top level of the robot.control process if you are adding processes inside of it, since the channels and processes are declared internally.
Keywords: mars
Submission reference: IN1702
I noticed that a new hazard value is sent every 10 mm you get closer to a hazard. So when you move forward until at a level of 9, moving forward again will go forward 10 and then detect a 10 (Hit). Because of the way hazard values are sent, this can't be avoided. Moving forward again will keep moving you forward 10 and detecting the hazard until you have past through hazard. Is this functionality ok? Or should we do something like move backward 10 before we move forward ... so we never hit anything?
You should remember the last set of hazard values you received, as you only receive values when the hazard level changes. If you've moved away from the object, then you will receive values which will be lower, thereby making your stored values amenable to movement. You should check these stored values before moving at all, to prevent the problem you mention in your question.
Keywords: mars
Submission reference: IN1708
Hello, lifeonmars problem again! I am having the following curious issue. The results are surprising when I give this set of instructions: 1) Find blue 2) Move backwards such that the blue blob is out of camera range 3) Find blue Surprisingly it then - without turning but after a 2 second scan - returns that it has found the blue blob at the same bearing and size as before. This also occurs when you, for example, rotate a random amount instead of moving; or indeed when you do any combination of move/turning that gets you out of the range of the blue. Staying in range of the blue but manipulating the angle/distance seems to work fine, though. What's going on?!
The object camera takes a certain amount of time to stabilize its data (camera scan time) after you have moved, you should be careful that when you start looking for objects, you have emptied any stale data that is coming from the camera (it will take at least 2 seconds to receive more good data, due to the scan time). If you don't empty this data you are liable to get stale results which don't reflect the state of the environment (which is what it sounds like in your question).
Keywords: mars
Submission reference: IN1712
In task 4 of Life on Mars: to get full marks, how much accuracy is required for dropping the sensor probe between two blobs? Does it have to be dead at the centre??
The sensor probe doesn't have to be placed exactly at the centre, you won't lose marks as long as the sensor is dropped in the area between the two coloured blobs, however it would be nice if you tuned your solution to put it as close to the center as possible. (Such that if we sent your robot to deploy the sensor from many different positions, it would probably end up putting it in roughly the same position each time).
Keywords: mars
Submission reference: IN1705
How can we implement a structured priority alternation of processes? For example, I have 3 processes A, B and C. I want A to have the first priority, then B and finally C. Can we nest the PRI ALT constructs to achieve this, as follows:
PRI ALT
PRI ALT
x ? any
A()
y ? any
B()
z ? any
C()
?
Priorities given by a PRI ALT relate to the guards rather than the processes they are defending. So, it does not make sense to say you "want A to have the first priority". It would make sense to say you "want channel x to have the first priority", etc.
The code fragment you give does give priority first to channel x, then to channel y and, then, to z. But there is no need to nest the PRI ALTs! A single PRI ALT can have any number of guarded processes. So:
PRI ALT
x ? any
A()
y ? any
B()
z ? any
C()
does the same job. See slides 124 to the end of the choice slides for the rules about nesting ALTs.
Keywords: priority
Submission reference: IN1713
For the 4th task, the "Mission to Mars" document states: To get full marks you will need to appropriately modify the response protocol such that it returns the new relative position of the robot and allows the reporting of any other error conditions encountered. Could you expand on this a bit please? What is meant be relative position? Should we just return the distance travelled, or is more information required? Also what is meant by reporting errors? What type of errors? Many thanks.
Your assumption that relative position is the distance travelled is correct. There are times when writing software where you must make the choices about operational behaviour. We have purposefully left the list of error conditions you need to add unspecified — you should apply knowledge you have gained from your course and the specific behaviour of your solution to craft a suitable answer.
Keywords: mars
Submission reference: IN1709
Ive finally got to task 4 and am having a difficult time working out the relationship between bearing and size. I get that you use the two blobs bearings to turn to a particular angle (in order to face middle of the blobs), but i cant figure out how to judge the distance to move. i imagine it would be to do with size, but this changes depending on the bearing, as well as the robots distance from the blobs. any chance you could give us a little more info on bearing and size's correlation with each other so we can use them to work out the distance?
An approach to figuring this out would be to go forward toward the blobs, in the right direction, and print out the size values for the blobs (making sure you're throwing away the stale camera data for the 2 second stabilization period while doing this). It would be non-trivial to try and work out a distance to the object based on the size and the bearing. The size value is the percentage cover of the vision arc that the blob has. A hint would be that if you've gone right between the two points, it may well be that you've lost sight of the two objects from your frontal vision (because they are to your sides). The blob size will get larger as you progress toward the blobs.
Keywords: mars
Submission reference: IN1720
I'm getting a really strange error. STOP ERROR line 1015 mars-sim It happens when I search for a blob. If the robot doesn't find the blob it starts turning, then after around 80degrees of rotation this error occurs, it seems to be the CASE section of mars-sim where it handles the protocol referring to the BLOB. I can't figure it out because it happens mid-way through a turn, the robot isn't doing anything but turning at this point.
Line 1015 of mars-sim.occ contains the CASE statement which reads protocol responses for the find.blob command. The STOP error implies that you are returning a response which is not covered within the CASE statement (i.e. not one of blob.found or blob.not.found.)
Keywords: mars
Submission reference: IN1719
On Task 3 for Life On Mars, I am trying to take a Real32 from the BLOB bearing field and add it to an INT.
This is to get its location from my starting point. However, I am unable to add it to an INT; and I am unable to cast it to an INT. I'm really stuck on this.
Casting from REAL32 to INT requires you to specify what you want to do about the loss of precision in fractional numbers. See the last part of Question 111 (2003) for an explanation.
Other anonymous questions from the past dealing with casting are under the keyword cast if you need further help.
Referrers: Question 54 (2010)
Submission reference: IN1716
When moving, I have the problem that once a hazard has been detected, I can't move away from it. From what I understand about how the hazard detectors work, I should only be receiving values when the hazard level changes. Therefore, If I detected a level 9 hazard which has caused my robot to stop, upon moving away from the hazard the next value I receive should be a level 8. However, I suspect that I'm infact I'm receiving a level 9 which is causing the problem. Could you confirm this? Thanks.
There is a buffer between the hazard detectors and your control process which filters changes and outputs the latest value. In the event that your program cannot keep up with hazard data events, a duplicate value may be output from this buffer in the hazard detection.
If you need consistently unique values, then you will need to implement a filter process within your control program.
Keywords: mars
Submission reference: IN1718
For the second, "move", command of lifeonmars , do we report the distance moved or the relative position? My understanding is: if we move 100mm back then the distance we moved would be 100mm, but the relative position would be -100. Thanks.
The PDF and protocol definition both ask for the distance moved (i.e. 100mm in your example), but either is acceptable.
Keywords: mars
Submission reference: IN1721
Hi there, with the move command for the current assessment I seem to only be receiving feedback in blocks on 10mm. Therefore, if I execute a move command for example for 14mm, the robot potentially moves either 10mm or 20mm (depending on hazards). Is this acceptable, or am I doing something wrong ?
Apologies! The answer below is no longer correct. Please see Question 52 (2009) for the currently operational answer.
[It sounds like something is wrong with your code, ticks would be expected to increment in single units. Note that if you don't read the motor feedback channels, the ticks will be summed (so if you're not reading it frequently enough, you might find that the increments you receive are quite large). You've discovered the problem with allowing these ticks to be summed, in that it makes moving a precise amount (or within set tolerances) difficult.]
Keywords: mars
Referrers: Question 58 (2009) , Question 58 (2009)
Submission reference: IN1722
I'm really struggling with task 2. Can you give any more tips as to how we are supposed to implement this? Thanks.
It may be easier to deal with solving the problem in two steps.
First, make your robot move forward on command, which requires a similar approach to turning: starting the motors with an a command and then reading the ticks until the condition is satisfied; then returning the correct protocol variant to signal a completed move.
Now add the second behaviour: hazard detection. Once you're in motion, you need to check that you have not exceeded a hazard threshold using the information given to you by the hazard sensors. If you have encountered a hazard, you need to stop moving and return the appropriate protocol variant to indicate a detected hazard.
Keywords: mars
Submission reference: IN1725
I've finally got my robot to rotate x degrees, but then the transterpreter sits there going "Response: ..." How can I fix this?
The simulator expects you to return an appropriate protocol variant from the protocol P.OPERATOR.RESPONSE once you have completed the turn, along with the amount turned before it will continue. Your simulator is waiting for this response, hence the message.
Keywords: mars
Submission reference: IN1726
For task 3, I have the following;
camera ? blob
SEQ
clr := blob[colour]
IF
clr = colour.in
where colour.in is passed as a parameter. Why do I get a runtime error when this bit of code is run? It always fails on the IF statement. All I want to do is to compare the blob colour value found by the camera with that given, if it is the same then stop and report back to operator.
Assuming that colour.in is declared elsewhere, have you checked that your IF statement has a TRUE condition – IF statements without the TRUE condition will work as long as one of their conditions is passed, but if you get into a state where none of its conditions hold, a runtime error is thrown.
For further information, see the questions under the if keyword, specifically Question 2 (2006).
Keywords: mars
Submission reference: IN1727
With the third year project deadline last Thursday and lots of other commitments all coming to a climax this week it's been a real struggle to finish the Life on Mars assessment in order to get Task 4 working correctly. I've asked a number of colleagues on the course if they have manage to complete it fully but it appears that very few have. As this is the first time the assessment has been run, and the hence the best timing of the assessment hasn't perhaps yet been fully determined, is there any chance you could consider extending the deadline for everyone, perhaps to Thursday midnight?
OK. You'll have to mail me (p.h.welch@kent.ac.uk) your solution. Imrpoved re-submissions may also be mailed to me. No penalty if received by end of Thursday, 9th. April.
Keywords: mars
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
