COMP1120 Assignment 3

Yup Pete i got the same as you,

T 180 0.5 0.5

C 200 0.5

Mine seems to be working perfectly, happy to help u out, what exactly are you stuck on?

(BTW everyone else, may have been unclear, you gotta restart test_drive before doing the second test to output the same results as Peter and I.)

Random tests (move routine) (restarted prog b4 each test):

M 270 300 0.7

M 500 75 0.4

M 400 100 1

Remeber fellas, there is no competition in UNI, unlike college, so our best bet is to work together if ppl are having trouble :-D.

(BTW Peter, why not use the COMP1120 board??......Oh stupid me, this is your site eh :-p)

Mic

Shit didn't think of the greater than symbols being detected as HTML tags, sorry.

Test outputs below:

T 180 0.5 0.5
125 (1002,1191) (2;180) no_contact

C 200 0.5
206 (800,1191) (2;180) no_contact

M 270 300 0.7
98 (1180,739) (3;300) no_contact

M 500 75 0.4
287 (1177,1519) (2;75) no_contact

M 400 100 1
103 (979,1455) (5;100) no_contact

Sorry.

Dude u should allow users to edit their posts; made another mistake, whoops.

C 200 0.5
206 (800,1191) (2;180) no_contact

Should be:

C 200 0.5
85 (1200,1000) (2;0) no_contact

there is not quite good postcondition in 'move' routine in the boat_drive.e file
"(boat.b_vel.theta - direction).abs

for some weird reason my message didn't appear in one piece
well.. nevermind, just try this test:
T 180 1.0 1.0
C 30 1.0
T 90 1.0 1.0
C 400 1.0
T 230 1.0 1.0
C 190 1.0
M 70 0 1.0

C 180 1.0
T 270 1.0 1.0
C 200 1.0
M 70 0 1.0
M 200 90 1.0
q

Seems those HTML tags are stuffing Greg up also.

Pete, how do you put a greater than sign or a less than sign in your forum without it thinking it's a tag?

I agree chaos, that "(boat.b_vel.theta - direction).abs" is a shocking postcondition for the 'move' routine. The 'turn' routine uses 'diff_angle' to check the results, which works. I cannot see why Peter didn't use the same in 'move', maybe it is because there was no rudder parameter in the 'move' routine.

(ON THAT NOTE: In 'diff_angle' wtf does the paramter 'dir' do??)

I got an Ensure error when doing the test set chaos posted above. It happened after calling "M 70 0 1.0" the second time. It was because boat.b_vel.theta was 360 degrees instead of 0 degrees.

I'll email John and whinge and ask him if we can change the postcondition from "(boat.b_vel.theta - direction).abs" to "(boat.b_vel.normalize_degree(boat.b_vel.theta)-direction).abs" cause otherwise it not taking into account all the possibilities.

I CAN'T BELIEVE PETER DIDN'T LIMIT THETA TO 0

actually aboat.b_vel.theta in not 360, it's a bit less then 360 and in the sense of angles "boat.b_vel.theta - direction" is in fact less than accuracy, but in the sense of real numbers it's about 360.
i think we can change postcondition. i changed it to
"angle_diff( boat.b_vel.theta, direction, -1.0).abs LE Turn_accuracy or angle_diff( boat.b_vel.theta, direction, 1.0).abs LE Turn_accuracy"
LE - less or equal

just sent the following query to john:

"also, another question, we obviously dont have access to the information in the eboat class (so that we dont know how many charges the eboat has left etc). This however poses a problem as we have no way of knowing the blast radius of the charges that the eboat will be dropping - information we really
should have access to. The assignment statement says that any of the constants may be changed - so we can't assume that it will stay at 30. Is this access restriction an oversight, or is this how it is intended (i seriously doubt this is the case as it would make the simulation grossly unfair)?"

in the angle_diff function, dir clarifies in which rotational direction you measure the angle.

eg 2 directions, 15 degrees and 30 degrees

does angle diff return 15 degrees or 345 degrees?

if dir is +ve it will return 15 degrees (as +ve represents clockwise) and it dir is -ve, then it would return 345 degrees (as -ve represents anti-clockwise movement)

what actual value dir is doesnt matter at all - all that matters is its sign - imo a bit of a weird way to do it!!

hope that explains it

david ac

davidac:
>>hope that explains it

Yup thanks :).

chaos:
I don't think that that postcondition will work either, i somehow got diff_angle to return 360 degrees when two values of 0 degrees were passed in; weird :S.

Anyway, i just added an extra bit to the post-condition:

"last_ok implies (((boat.b_vel.theta - direction).abs

last_ok implies (((boat.b_vel.theta - direction).abs {= Turn_accuracy or (boat.b_vel.theta - (direction + 360)).abs {= Turn_accuracy) and boat.b_pos.add_v(-1.0, old boat.b_pos).r }= distance)

{ = less than
} = greater than

perfect tactics is
T 40 0.5 1.0
T 80 -0.5 1.0
T 80 0.5 1.0
T 80 -0.5 1.0
T 80 0.5 1.0
T 80 -0.5 1.0
T 80 0.5 1.0
T 80 -0.5 1.0
T 80 0.5 1.0
T 80 -0.5 1.0
T 80 0.5 1.0
T 80 -0.5 1.0
T 80 0.5 1.0
T 80 -0.5 1.0
T 80 0.5 1.0
T 80 -0.5 1.0
q

tag test >

perfect tactics suck.

nemesis:
it crashes because Peter's postcondition in 'move' routine
isn't right. See previous messages.

omega:
we are supposed to call 'set_alarm' routine to set which alarm we want to monitor. So if you want to exit, say, 'course' routine when boat is near the wall you should do:
"a.set_alarm(1)
drive.course( 100, 1.0,u, a)"

afaik, the boat_alarm is passed to each of the drive.turn, drive.course, and drive.move features. In my udriver class i use it similarly to this:

UDuck is
do
a.set_alarm (a.First_contact) -- make the alarm look for sonar contact
move (stuf, stuf, stuf, stuf, u, a) -- move to the end of the channel but stop if there is sonar contact
end -- UDuck

In my extended boat_alarm class (not real extended class, i mean i put stuff in) I include a constant First_contact. When alarm_type (or whatever it is) is set to First_contact, the alarm is raised if the eboat is in sonar contact. This causes the early exit condition from move to be sonar.in_contact. Obviously, the next alarm_types will be harder, but I believe that I need Eboat_chasing for when the Eboat has found the Uboat, so that I can switch into UEvade.

Is that any clearer or have I confused you? I don't know why Peter didn't make it a bit clearer in the spec.

Dunno if the boat_alarm is clear yet Pete.

Basically we can add as many alarms as we wish to the BOAT_ALARM class. To add an alarm the following is done:

----------
1. An alarm type integer constant is added at the top of the class.
eg:
No_alarm: INTEGER is 0
Near_walls: INTEGER is 1
Sonar_contact: INTEGER is 2
Explosion_detect: INTEGER is 3
...

----------
2. A routine/feature is added to the "feature {NONE}" section of BOAT_ALARM.
eg:

feature {NONE}
ocean: OCEAN -- used to access channel boundaries

near_walls(b: BOAT): BOOLEAN is
do
...
end

sonar_conact(b: BOAT): BOOLEAN is
do
...
end

explosion_detect(b: BOAT): BOOLEAN is
do
...
end

...

----------
3. The routine/feature added above is called in the 'is_raised' routine.
eg:

is_raised(b: BOAT): BOOLEAN is
do
inspect alarm_type
when Near_walls then
Result := near_walls(b)
when Sonar_contact then
Result := sonar_contact(b)
when Explosion_detect
Result := explosion_detect(b)
...
...
else
Result := False
end
if (b.destroyed) then
Result := True
end
end

----------
4. To detect an alarm, in the UDRIVER class you put:

a.set_alarm(a.Explosion_detect) --or a.set_alarm(3)
drive.move(distance, direction, throttle, u, a)

So each movement you can only have one alarm running, set by the call 'a.set_alarm()'.

Hope this clears things up a bit if they weren't already, dinner time for me :), then Maths study :(.

now this really sucks!!!

i downloaded the latest eiffel compiler for my computer - i try compiling the simulation, and the C code the eiffel compiler generates doesn't compile with gcc!!!!!!!

thats what i call a top quality compiler!!!!!

Hey guys, Lachlan here, how is everyone going? personally i'm thinking of killing myself. Lets hope carol comes through with that extension.

hi, just wanted to get an idea of where everyone's up to? i've done uduck and a very flimsy uavoid. and also, does anyone know what sort of success rate we should get against simulation 2?

guys,
how does 'detect_explosion' work?
does it detect released charge or
just it's explosion?

chaos:
guys,
how does 'detect_explosion' work?
does it detect released charge or
just it's explosion?

It only detects when a charge explodes, this is useful, because when the EBoat has released all of it's charges, the UBoat doesn't need to worry about being blown up anymore, so it can just drive straight to the finish line.

anon:
hi, just wanted to get an idea of where everyone's up to?

I've only finished boat_drive, just getting started on boat_alarm and udriver. Carol hasn't replied yet either, looks like we'll be having to plead with John this afternoon ;).

thursday, a great relief.

A little of topic.

Nice website you have there anon (www.owenthomas.com), although it reeks a little of google. Did you take any of it from their website?

lol, i only keep the domain for the e-mail address, so i redirected the domain to google.

I think I figured out why 'diff_angle' returns 360 when
we pass two equal angles and -1.0 as direction.

Result := (angle2 - angle1) * (dir/dir.abs)
here result is assigned not zero, but minus zero

if (Result

if (Result &lt 0.0) then
Result := Result + 360.0
end
of course -0.0 is less then 0.0, but -0.0 + 360.0 = 360.0,
so result if 360.0 and postcondition violated.

Do the boats have any angular velocity (that is, do they keep turning for a moment after doing a hard turn and then setting rudder to 0)??

Chaos, i don't know if that postcondition is actually violated:

If -0.0 is less than 0.0, then:

-0.0+360.0 has to be less that 0.0+360.0

...which is the postcondition.

Have you experienced this error?

i posted on your webct page this morning. I hope you guys have all finished your physics assignment 2, cos its gone from webct. 17hrs before due!!!