Week 13 - Reflections

Through out this course we've learnt several different design concepts.

I personally have been reflecting upon these questions during the design development process and through this precess, new side and phases of design have been discovered.
Well, I haven't had must time to blog my reflection due to the "great" assignment influx from various courses I've been taking (mostly from studio 3 and studio 5).

How do you describe yourself and your interest?
Me? A highly volatile person, someone who enjoys the attention of leadership and the thick of getting in the midst of action.
My current interests have changed highly through this semester of work, most properly due to the thing related to the work I’m doing. I usually hate code even though I’m rather decent at it. However my interest have in fact tilted towards physical computing (which made me realized the importance of coding) and research. Somehow or rather there has always been this hidden interest for academia in me.

What designers/design works do you like?
Firstly I must say, the country I come from (Singapore) there is almost nobody and no courses teaching the things we do now, so it’s seriously hard to find a design which I really like. If there was someone who has impressed me with design within these few years it would be Ben Burtt the sound designer for Star Wars, I’ve always been a sound freak and I enjoy listening to sounds, creating sound and mixing them. The things that Ben Burtt does with sound can really be amazing and the process that he goes trough.
There are design locally in UQ that have also inspired me, the 2 of which are namely “Talk2Me” by Ann Morrison and the current “Interactive Night Club” done by 3 year studio 5 students. At this point of time now I must say that these 2 designs will really affect what I do in Studios 4 and 6 next semester, simply because now I know what is possible. That is physical computing. Moving away from just the screen, something that get people fully involved, not just by looking at a screen, but actually moving around or talking to it.

What is good design?
A good design, sadly now a day the word design has been reduced to making things look good. However this is not the case, design is art, and art must not only look good but also have “interaction”. As the saying goes “every picture tells a story” what’s the point of just making something look good, when people just walk by and not get anything out of it. Good design is not just art, but art that “talks” to people. Art that can tell people something, art that makes it possible for people to relate to it.
It is “Interactive Art”.

In what way does your own work reflect what you consider to be good design?
Since mid-way through this semester, most of my design ethics have changed. From the posters to the latest assignment of the “cambot”, the original idea of the “cambot” was to have a robot that was able to follow you around the house and allow you to chat with someone via a webcam.
However when I tried to create it with my project group, my focus wasn’t just to have a robot that follows, but my focus was a technological piece of art work. Instead of viewing it as a robot, I went about the problem viewing it as a person virtually transported to you. In this case further functions were added to the robot, to make it move off and make some noise when it knocks into objects just like what normal humans do when we know into things.

How can you push your work into that direction?
I think from now on, most of my work will be headed towards physical computing, in a sense combining technology with art. To not just concentrate on the outcome, but to consider other factors, to research on topics related to those factors and finally to come up with the most effective way around a problem. A problem is no longer a problem, it is a new opportunity to excel.

What are your main priorities? What are your main interest right now?
God? Well, yah but in a design context, I guess now I’ll have to look at new and different ways and technologies that are currently available and also research. As these will help me to be able to achieve the direction I’m heading to.

What do you hope to achieve through this degree?
Get a job… (hahaha) Its hard to say, I learn new thing every year I’m in this program, from the power of simplicity to the essentials of interactivity. Of course it would be a better understanding to the field and yes as much new technology as possible.

Where do you hope to be at the end of this degree?
I hope to achieve or emulate one of the 2 projects mentioned in the above answers “Talk2Me” and the “Interactive Night Club”. Of course I do have something in my mind right now mostly something inspired by the movies “Minority Report” and “iRobot”. As you can see the technology based in these movies are mostly physical computing. Apart from that as much as it freaks me out, I also hope to be an academia the technology gained will go to waste if it is not passed on especially to those countries who have yet to go into it.

What projects are you interested in pursuing further?
Like I said I already have something in mind. Now imagine, what if you’re not just talking to a microphone, what if you’re can interact with more than a screen, what if the whole building/room is interactive? A whole new space that allows you to be immersed in, a world within this world. This would be one of the projects which I’ll be attempting in the near future.

Week 12 - Final Presentation

Poster Containing justification of results, research and timeline of development.


Poster with sketches of prototype during development phase and changes we made during trial and error.


Poster with final sketches of prototype and photos of testing phase.


Rough view on decision of prototype to be bade during development phrase.


Top view of tracks and base unit.
Cambot version 1.9


Initial Sketch of firstt prototype.
Cambot Version 1.0


Angel View working prototype.


Top view of working prototype.


Side view sketch of working prototype.


Future model of robot with base unit and computer on top for the webcam module.


Research justification on types of wheels to use.


Final Picture of poster done.

Great work team...

Thanks Megan and John

Week 11 - Final Coding

So far we've managed to get the robot to follow a path, and avoid objects when knocked into. However, we didn't managed to get it to do both together, until now.

This is the logic in which RCX code works by, it has up to 3 input sensors, which it can "listen" to all the time. However these sensors do not have prioty over each other, which means if it detects an object with its left bumper, and while manuvering around, it detects a new path, or in this case the same path, as the first command when it bumps into objects would be to reverse, the code that makes it follow the path, would just overright the manuvering code, and the robot will just move forward and knock into the same object again.

This seems rather silly and its an endless loop we tried to find different ways to set prioity to different codes, but on the other hand if the manuvring code is over the follow path code, than it would have to bump into something first before it can follow the path, but we do not want that we want the robot to follow the path first.
So it seem like an endless problem.

So what do we know now:
1. The input sensors will all detect for input at the same time
2. We cannot set prioity to any of the codes
3. All 3 sensors have to be on as there is no function to turn them off or on
4. RCX code runs commands in a top/down procedure

What are the ways around this:
1. Input snesors will still have to detect all at the same time, as it might bump into more objects while manuvering
2. We cannot set prioity to the sensor codes, however there is a "command stack" in RCX code which take prioity over sensor code
3. We cannot run on/off sensors, but we can have sensors to do nothing upon certain conditions *this would be the discovery that helps us solve this problem.
4. Having code run in a top/down procedure would actually be to our advantage, as it would be easy to debug

So with what we've got after long hours of fight with our minds, brainstorming and wrestling with the RCX we came up with the follow concept that fianlly worked.

*Remember in this case all 3 program stacks are running together
on start program
set counter to "0";
if counter == "0" then
follow path;
alternate bewteen motor A(left) and motor C(right) to turn;
else
on both motor A and C;
move straight and prepare for manuvering;
end if
end

//Detects something hitting the left bumper
on left bumper == ture
counter++;
avoid object on left;
counter = 0;
end

//Detects somthing hitting the right bumper
on right bumper == true
counter++;
avoid object on right;
counter = 0;
end

The logic of the above code is rather simple, running the main program stack and set the counter to "0" . This will trigger the robot to follow a standard path, with the other 2 sensor inputs still on, if it bumps into any objects, it will set the counter to "1", which will effectivly stop it from floow the path, as the condistion statment is there. Now with the counter at 1 both motors are on and the manuvering code is free to perform itself, once the manuvering code is done, it sets the counter back to "0", which in turn activates the light sensor again and makes it continue to follow the path.
It feels great to have finally solved a problem, but come to think of it, it took us a rather long time to debug this issue.

Week 10 - Further Implementation/construction

The base of the robot has been settled, however our goal was to create a Robot that would not only follow a standard path, BUT also to aviod objects when it bumps into them.

Last week we created the base and the wheel/track sets for the robot, this week we played around and created the bumpers and light sensors. It was a challange as, we had to bring the bumpers up higher in order to accomodate space for the light sensor at the bottom.

After some time of "playing" around we've came up with a design, where the wheels and tracks are inter-changable, which means, if it is in door the user can leave it as small wheels and move as per normal, if the user wishes to take the cambot out side into the garden, the wheels can be removed and the tracks can be fixed onto it.

We've decided to scrap the old version 3 which we came up with last week, as the wheels are simply moving too fast.

And so enters version 4 with inter-changable wheels and bumpers with light sensor.

Week 9 - Prototyping and software testing

Prototype version 1, used for testing and trying out software


Gears and part used for creating and moving robot tracks and wheels


Prototype version 2, robot with changeable base (wheels or tracks)


Prototype Version 2.1, Robot with tracks as base


Prototype Version 3, Robot with fixed base and big wheels

Week 8

Testing of the RCX code.

Now that the full set of lego mindstorm(so gonna get one for myself on christmas) is finally in place, and we have every component in it.
We can get down to work, since I"m not very good at designing and drafting out ideas, I decided to concentrate on the coding need for the cambot to run.

Now we've zero it down to a few things in which the cambot has to be able to do while moving around.
1. Follow a standard path
2. Not go too close to the person
3. Be able to either aviod/move around objects which it bumps into

Instead of going straight into the RCX coding or VB coding, I've decided to document my "code to be" as a flow chart, which can be submitted in a documentation later on in the development process.
Since the RCX code can support up to 9 sensor watch stacks at a time and listen to 9 different inputs, this makes my job a little easier.
Stack 1 on start program, on output A nd C(which sets the wheels to run)

Stack 2:(this stack contorls the cambot to follow the path or in this case a light source)
if light is on then
on output A and C
else if light is off
off output A and C

Stack 3 and 4:(these will be the touch sensors which cause the cambot to move around objects 3 is the right sensor and 4 is the left)
if sensor is true then
off output A and C
on reverse A and C
off output A(by only having one wheel move, will cause the cambot to turn)
move A at normal speed
move C at high speed (causing cambot to turn back to its original direction)
wait for 1 second (waiting here causes the code to wait, but the cambot will carry on moving)
(the 1 second wait here is for the cambot to fully turn before continuing on its path)
set speed of C to normal speed (this will cause the cambot to move straight again)

The code has yet to be tested, as this is only the planning stage, certain features must still be added, and considerations like what if it bangs into a wall, there will be no point in move it then, can it be turned off...etc
What happens if there is more than 1 cambot moving around?

so there is still quite a lot of thing to build on from here.

Mid Sem Break a.k.a MMDS project week

We finally managed to get our hands on a lego mindsotrm set, only thing is that its not a complete set, as it has cables, axles and certain key pieces missing and it didn't come with the software, however it was enough for us to get some work done at least.

We tried playing with the lego block and looking at the building diagrams which come with the mindstorm as well, we tried building a few ideas, looking around testing it out to see if it works well on different flooring.
Small thick wheels works well on most flooring, but don't have much grip.
Bigger wheels work better than small wheels, but will have difficulty when moving on carpet flooring(as most homes and the crit has carpet flooring).
Caterpiller tracks is slightly slow, however these tracks works best and can even climb up from normal floor onto a floor mat or carpet.
We've not test the caterpiller track fully yet, however just like tank tracks, it might be able to roll over small objects as well.
Moving slower will just mean we have to increase the delay times of "move" commands in the programs allowing it to have more time to manuver around.

With the lmitation of touch sensors (should have 2, we only had 1) we could only try out the single bumper system.
From what we have discovered, the sensors are not as sensitive as we thought, which means the single bumper system might not be good after all, as it will be using only 1 sensor for both left and right. However if we had 2 sensors we could have something like bumpers for even the sides of the cambot. So we'll have to have more building with that.

Thankfully the light sensor was in the set and working, we tested it out and yes just the same its not very sensitive, thus we would need to have a real test in the crit space in order to know how to accurately set the sensitivity of the light senor via the software.

And just in time to save us, Magen managed to get her brother's mindstorm set, which is the full set, minus the software....so right now we have 3 RCX modules for the mindstorm, one complete set, one not so complete set and yes, zero copy of the software.