Mar 11, 2009
input |ˈinˌpoŏt| précis
Exercise 1 Chess Bot
Exercise 1 Chess Bot
_____________________
'explore creative potential of implementing protocol through programming and applying to robotic systems'
Acquiring a LEGO Mindstorm NXT (software development kit) the group must assess and construct a 'Chessbot', capable of simple actions of movement/direction. Accompanying software must be utilised to define and interface user protocol. The bot should start at foyer entrance and finish in studio.
throughput |ˈθroōˌpoŏt| passage
We unpack and distribute respective parts/pieces for the unit and collaborate to build the 'tribot' template in instruction manual. We identify that sensors are optional as add-ons but focus on basic unit. Completing the bot now capable of 'static' simple movements we plug in our module to test (motor) functions via USB interfacing with NXT platform.
These check out=working/moving/sending/receiving. Out of curiosity we add a sensor to produce 'ultrasonic' (object distance) sensitivity/reaction. It responds accordingly but we do not (until later) incorporate it as part of our protocol. Attempt at programming begins.
We identify between us how specific icons possess corresponding value criteria which are mappable onto a grid. It becomes clearer that these will eventually block together to produce a work flow for the Chessbot - transmittable to the module's CPU for 're-enactment'. This degree of action is variable (we note) and potentially unpredictable given the attachment of sensory detectors (and their programmable reaction). Doing our best to correlate all our 'ingredients' we discuss/plan our strategy for executing a RUN program for the bot that best reflects/performs our protocol moves.
output |ˈoutˌpoŏt| arriveé
Our NXT program became a sequence of 2-3 actionable commands, moving within limits of 2m sq. We physically mapped the route with the bot in tow using the defining movements to gauge and adjust the actual input values, but basic movements were [forwards 1 step=1.5m@2 sec/rotate R or L/stop;move forwards]. This often meant that the unit had to be reloaded with each correction of a step - to achieve accuracy. This proved very time consuming and exhausted the batteries, making it difficult to finalise our assessment. We decided to rendez-vous early am to tweak its performance for presentation.
reflections |riˈflek sh ənz| moi-même
'explore creative potential of implementing protocol through programming and applying to robotic systems'
Acquiring a LEGO Mindstorm NXT (software development kit) the group must assess and construct a 'Chessbot', capable of simple actions of movement/direction. Accompanying software must be utilised to define and interface user protocol. The bot should start at foyer entrance and finish in studio.
throughput |ˈθroōˌpoŏt| passage
We unpack and distribute respective parts/pieces for the unit and collaborate to build the 'tribot' template in instruction manual. We identify that sensors are optional as add-ons but focus on basic unit. Completing the bot now capable of 'static' simple movements we plug in our module to test (motor) functions via USB interfacing with NXT platform.
These check out=working/moving/sending/receiving. Out of curiosity we add a sensor to produce 'ultrasonic' (object distance) sensitivity/reaction. It responds accordingly but we do not (until later) incorporate it as part of our protocol. Attempt at programming begins.
We identify between us how specific icons possess corresponding value criteria which are mappable onto a grid. It becomes clearer that these will eventually block together to produce a work flow for the Chessbot - transmittable to the module's CPU for 're-enactment'. This degree of action is variable (we note) and potentially unpredictable given the attachment of sensory detectors (and their programmable reaction). Doing our best to correlate all our 'ingredients' we discuss/plan our strategy for executing a RUN program for the bot that best reflects/performs our protocol moves.
output |ˈoutˌpoŏt| arriveé
Our NXT program became a sequence of 2-3 actionable commands, moving within limits of 2m sq. We physically mapped the route with the bot in tow using the defining movements to gauge and adjust the actual input values, but basic movements were [forwards 1 step=1.5m@2 sec/rotate R or L/stop;move forwards]. This often meant that the unit had to be reloaded with each correction of a step - to achieve accuracy. This proved very time consuming and exhausted the batteries, making it difficult to finalise our assessment. We decided to rendez-vous early am to tweak its performance for presentation.
reflections |riˈflek sh ənz| moi-même
During presentation the Chessbot performed better (covering more distance) than I expected. It interested me, how much I had become 'attached' to the idea of achieving the 'success' of our result - by adhering to accuracy of protocol; as opposed to the event of unpredictability (or even failure). I was also intrigued how two bots, entirely independent of each other and with completely different protocols - converged at the same finishing distance (yet opposite one other)!
On a deeper level, observing the bot being drained of power conveyed a 'humanness' to me; in the sense that our 'power' to perform (with all the grace of our motor skills) changes dynamically (sometimes drastically) without energy: and moreover that total absence of 'electricity to the heart and brain' posits life/death motifs.
On a deeper level, observing the bot being drained of power conveyed a 'humanness' to me; in the sense that our 'power' to perform (with all the grace of our motor skills) changes dynamically (sometimes drastically) without energy: and moreover that total absence of 'electricity to the heart and brain' posits life/death motifs.
Mar 10, 2009
input |ˈinˌpoŏt| précis Project 1 Social Networking
________________________________________________________
'explore complexity of interaction within a small group;generate data visualisation of information'
Divide ourselves into (designated) groups. We would all be given post-it pads (of differing colour) as well as coloured balls of string. A series of questions would be asked and the relevant answers for each were to be recorded on a separate post-it sheet. These answers were to be presented using larger physical space in the first instance, as radiating connecting points
from our individual names (like a star) with uniform colour string.
Everyone (from our group) answered the following questions writing them down as specified (in no particular order and from memory)
1 What is your favourite/preferred social network/interface? J=(my answer) none2 What is your favourite coffee? J=latté
3 Which town do you currently reside? J=Mangere Bridge
4 What is your least favourite vegetable? J=brussel sprouts
5 What is your favourite cuisine? J=indian
6 What would be your favourite pet? J=cat
7 What is your favourite TV show? J=blackadder
8 What was your last job? J=caregiver
9 What's your favourite Blog? J=none
10 What city do you come from? J=Otahuhu
11 What was the last best-selling book you read? J=the whole woman
We chose one of the surrounding walls as our 'map' area and began to pin up our labels, using tables to stand on to cover a greater surface. Our group used yellow string to connect our answers to our names. We then received instruction to use a secondary colour, to show connecting values using 'similarities' (only) as the single common determinant. We then recorded our findings. Instruction followed to input this data into Pajek - a 'network analysis program'.
'Pajek' processed our data using an algorithm comprising Vertices/Nodes/Edges whereby;
Vertices = (total number=number of people+number of common nodes)
Nodes = 'similarites'
Edges denote relationship between people and nodes- where Edges would be the frequency of Nodes adjacent to an individuals identifying number/The common nodes for our group became 10 in total;
'facebook'
'latté'
'Auckland central'
'brussel sprouts'
'italian'
'japanese'
'dogs'
'none/social network'
'none/blog'
'none/job'
output |ˈoutˌpoŏt| arriveé
reflections |riˈflek sh ənz| moi-même
This project was an interesting exercise - in that physical interaction and exchange of information became a premise for connection, which was then subsequently mirrored in the diagram.______________________________________________________________________________________________
input |ˈinˌpoŏt| précis Project 2 Situational Shuffle
'explore system conventions (while following simple instruction) and observe how these interface with an environment'
Divide ourselves into groups of 4. Each group is given - set of (control)cards - chalk - map of downtown Auckland. We also required digital and non-digital materials/medium for documentation.
We are then each assigned a respective role determining our level of participation within the group. The collective objective remains unclear in relation to the actual content on the cards (as yet unseen). The roles comprise;
Actuator =subject=Josh
Controller =myself=directs the Actuator
Tracker =charts Actuator's progress=Tarei
Sensor =observes outside the group=Daniel
We are told to begin at Aotea Square (11am).
throughput |ˈθroōˌpoŏt| passage
As a group we follow the 'rules' of the roles which resemble a sequential block and flow of events.
1 Controller draws card>shows Actuator>gives to Tracker2 Actuator performs action>stops
3 Tracker transposes Actuator's movement onto map>draws present card icon on footpath with chalk (initial action reference)
4 Sensor documents whole group with (variety of) medium
5 Unactionable card goes straight to back>to be performed
We repeat this sequence as a loop until no cards are left unactioned. While assuming our roles, we find it necessary to re-iterate the Actuator's task - to avoid confusion and to facilitate movement to the next card. Josh performs a lot of rotations during the exercise. We came across only one card initially unactionable, placing it at the back. Our final card landed us on Queen Street. We return to the studio to collate/confirm data. Tarei and I make an itinerary, checking accuracy of the route to corresponding actions. We prepare for the morning presentation, identifying a strategy to do so. We all agree that a large map should reflect our route supported by text and raw material collected during the exercise. We must also prepare our own (150/200 word) reflective statement for inclusion during the presentation.
output |ˈoutˌpoŏt| arriveé
reflections |riˈflek sh ənz| moi-même
In particular, I'm intrigued by the effects of adopting individual roles within a collective/group(objective). What interests me are the social implications of levels of interaction as determined by the performance of a role. From the exercise - I identified that my desire to focus on the result of assuming the responsibility of my own role facilitated recording initial data accurately. Yet the 'effectiveness' of this role was strengthened however, inseparably and largely by the co-operation of the group.
This leads me to observing conventions further and how we may interface as a group - as an environment in itself -which I feel warrants discussion. Within systems governed by technology; if one's awareness of their own actions is predominant and maintained as the primary concern, and you translate that as say performance of data: does our level of interaction on a 'network/platform' really mean that we're communicating, or in fact connecting interdependently; simply because we have our own awareness of the information we provide? Or does it suggest, that in the act of 'participation' - we become insular and remain a cache/caste/category; the consumer and end user; visibly ONLINE: but not necessarily exerting 'controlled' influence?
______________________________________________________________________________________________
input |ˈinˌpoŏt| précis Project 3 Protocol Iteration
Group from previous project 2 assembles. We are required to create a new chess piece or character. The character's name should identify connection to the role while defining a simple protocol supporting (behavioural) movement defined as units. The protocol must contain; min 3/max 7 units (e.g. 1 unit in any direction/2 in reverse). A diagram should illustrate it.
throughput |ˈθroōˌpoŏt| passage
At first, we discuss elements that tend to centre around the 'rules' of chess and respective heirarchal pros/cons of movements leading to advantage. There is some confusion regarding priority, defining the piece's role; or identifying key movement for illustration. We are then requested to implement the protocol we are developing, applying it as physical movement.
= Assemble at Britomart/move our piece (as a group) to Aotea Square/without compromising our protocol rule/if so - we lose the 'game').Before our attempt, we identify a character - 'The Leap Frog' .... a (fairy tale) Prince through unfortunate events is turned into a frog by his King in order to contain/limit his movements as a singular leap. We translate this as 3 units in total; direction - backwards/forwards/left/right. We begin the exercise. Arriving at Britomart we first use a map to plot our course, then 'leap' from one city block over another,following the unit rule. (We eventually make it to Aotea Square!)
output |ˈoutˌpoŏt| arriveé
Taking our map data we extract our movements and represent them as blocks from the chessboard on the studio wall. We wished to convey the directional movement and capture the shape of our protocol; as a simple visual: separating the blocks from the constraints of a normal square board.
Setting aside the function of chess as well as its objective to be the winning opponent, I gravitated towards the necessity to develop our visual result. Graphically our illustration remains (while not overly dynamic) an arrival from the specific set of values in our protocol. I was however surprised to see how the governing values transformed to become iconic yet abstract, almost isolated. This suggests to me unpredictability (and even randomness) of representation, from a predominantly mathematical protocol.
Subscribe to: Posts (Atom)
No comments:
Post a Comment