Note: Actual code is in black; Commentary is in White.

This is the original code used in the Sword in the Stone Project:

menu 1 [sword]
menu 2 [release]
menu 3 [close]

 

to grip
output switch7
end

 

to sword
a, onfor 10 thatway
when [(grip)] [release]
when [not (grip)] [close]
end

to release
launch [a, on thisway waituntil [(sensor1) < 100] a, off]
forever [if (not (grip)) [stoprules] print [congratulations] [music happy]]
end

to close
a, on thatway
waituntil [(sensor1) < 220]
a, off
print [sorry]
end

to music-happy
loop [note...
end

There were three basic menu options: a sword procedure (the one that would make the stone open or close whenever the conditions for doing so were met) and separate close and release procedures to test whether the mechanism worked.

In this program, opening and closing was triggered by a switch wheras in the final version it was controlled by two flex sensors and a light sensor. This was so the functions of the device could be tested while its control was simplified.

The first version of the sword procedure sought to use concurrency to have the handyboard continually check whether the conditions for releasing or closing were met at the same time.

 

Both the release and close procedures first entailed timed motorized movements. These used motor a to move the tracks back and forth using a gear system. Unfortunately, these movements were not over uniform distances each time. Reflective sensors were added in subsequent iterations to control the limits of the tracks' movements in order to have more consistency.

 

 

In this version, only a song would celebrate the release of the sword from the stone.

This is the original song written for the release of the sword:

to music-happy
loop [note 40 10
note 43 10
note 48 10
note 55 10
note 70 15
note 75 10
note 79 5
note 90 10
note 120 5
note 115 10
note 93 5
note 60 10
note 65 5
note 70 6
note 75 2
note 90 10]
end
Some of this composition is the same as later rendition; however, the higher notes were lowered for the comfort of the listeners and the sanity of the composer. It would be continually changed and added to as well.

Final Song:

to music-happy
say [music1]
setmusicon (1)
note 40 10
note 43 10
note 48 10
note 55 10
note 53 15
note 50 10
note 65 5
note 63 10
note 64 5
note 65 10
note 63 5
note 68 10
note 75 5
note 67 6
note 56 2
note 58 10
note 60 5
note 61 5
note 59 5
note 70 1
note 71 2
note 72 3
note 71 4
note 56 2
note 58 10
note 60 5
note 61 5
note 59 5
note 72 1
note 73 2
note 74 3
note 72 4
note 60 10
note 62 5
note 63 5
note 59 5
note 74 1
note 76 2
note 76 3
note 70 4
note 62 5
note 62 5
note 62 5
note 62 5
note 63 5
note 62 5
note 60 4
note 59 3
note 57 3
note 55 2
note 52 2
note 50 1
note 50 1
setmusicon (0)
say [music2]
end
This is the final version of our celebration song.


This is the second main interation of our code:

menu 1 [sword]
menu 2 [release]
menu 3 [close]

to release
launch [a, on thisway
waituntil [(sensor 1) > 100]
a, off]
forever [if
(not (grip)) [stoprules]
print [congratulations]
music-happy ]
end

to grip
output switch 7
end

to close
a, on thatway
waituntil [(sensor 0) < 220]
a, off
print [sorry]
end

to sword
a, onfor 10 thatway
when [(grip)] [release]
when [not (grip)] [close]
end

to music-happy
loop [note 40 10
note 43 10
note 48 10
note 55 10
note 70 15
note 75 10
note 79 5
note 90 10
note 120 5
note 115 10
note 93 5
note 60 10
note 65 5
note 70 6
note 75 2
note 90 10]
end

 

 

Here, you can see that the release procedure has been changed to pay attention to reflective sensor outputs. As the device releases, one track no longer covers sensor 1, a sensor near the motor. When this happens, the motor stops, and friction stops the tracks. This produces more reliable movements. Afterwards, music should play unless the lock closes (stoprules for this procedure). However, in this current iteration, the music did not stop; a global variable, saying whether the music was one was suggested by Professor Turbak as a means to rework the music procedure and later implemented.

 

Close has likewise been changed to rely upon a reflective sensor's outputs to stop its movements. Once that sensor is recovered by a track, it outputs a value which tells the motor to stop.

 

Sword here still relies on concurrency...unfortunately, this was halting the program due to, as Professir Turbak discovered, a race condition between the two "when" procedures for use of motor a. Professor Berg later suggested that using "if" and "waiuntil" statements would work better.

Final Code:

menu 1 [sword]
menu 2 [release]
menu 3 [close]
menu 4 [celebrate]
menu 5 [music-happy]
menu 6 [candy]

global [musicon celebrating]

to grip1
output (sensor 5)
end

to grip2
output (sensor 6)
end

to brace
output (sensor 2)
end

to release
print [release1]
say [release1]
a, thisway
a, on
waituntil [(sensor 1) > 100]
a, off
print[release2]
say [release2]
end

to close
print [close1]
say [close1]
a, thatway
a, on
waituntil [(sensor 0) < 220]
a, off
print[close2]
say [close2]
end

to candy
c, setpower 8 thatway
c, onfor 2
c, rd
c, onfor 3
b, setpower 1 thisway
b, onfor 3
end

to music-happy
say [music1]
setmusicon (1)
note 40 10
note 43 10
note 48 10
note 55 10
note 53 15
note 50 10
note 65 5
note 63 10
note 64 5
note 65 10
note 63 5
note 68 10
note 75 5
note 67 6
note 56 2
note 58 10
note 60 5
note 61 5
note 59 5
note 70 1
note 71 2
note 72 3
note 71 4
note 56 2
note 58 10
note 60 5
note 61 5
note 59 5
note 72 1
note 73 2
note 74 3
note 72 4
note 60 10
note 62 5
note 63 5
note 59 5
note 74 1
note 76 2
note 76 3
note 70 4
note 62 5
note 62 5
note 62 5
note 62 5
note 63 5
note 62 5
note 60 4
note 59 3
note 57 3
note 55 2
note 52 2
note 50 1
note 50 1
setmusicon (0)
say [music2]
end

to celebrate
setcelebrating (1)
setmusicon (0)
when [grip1 < 130] [say [celebrate 6] setcelebrating (0) stoprules]
candy
loop [if (not (musicon)) [say [celebrate 5] music-happy]]
end


to sword
setmusicon (0)
setcelebrating (0)
close
loop [if (and (grip1 > 170 ) (and (grip2 > 110) (brace > 110))) [release if (not (celebrating)) [launch [celebrate]] waituntil [grip1 < 130]]
if (grip1 < 130) [close waituntil [and (grip1 > 170 ) (grip2 < 110)]]]
end

More menu options are included so more procedures can be tested.

 

 

Two global variable are used to keep track of whether the handyboard is celebrating a release or playing music.

The switch was replaced by two flex sensors and a light sensor to measure whether conditions were met for the sword to be released. These are here named grip1, grip2, and brace (since the light sensor would be covered by one's hand if one were "bracing" oneself against the stone at a specific point.)

 

 

 

 

 

 

Release and close remained controlled by the reflective sensors.

 

 

 

 

 

 

Candy was created to control a candy dispenser added to the machine to celebrate the release of the sword. Motor c powers a trapdoor which releases candy onto a conveyor belt then turned by motor b.

 

 

When the music is started, the global variable "musicon" is set to be true. When it is finished, it is set to false.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This procedure controls the celebration of the sword's release. It sets the celebrating global variable to true, and them makes sure musicon is false. Then, until the flex sensors are relaxed (stoprules) it will release candy, and play music whenever it is not currently playing.

 

 

The sword procedure first sets the two global variable to false and makes sure the locking device is closed. Then it continually tests for one of two conditions using if statements: If the two flex sensors are positions a certain way and the light sensor is covered, it will release the sword and initiate celebrate mode if it is currently not celebrating. If one flex sensor is relaxed the device will close.