Wednesday, May 30, 2012

Networks: Contextualise

Had a talk with James and Andy about our exhibition and project in general to make sure that we're okay.

We showed them the working engine, we also took videos of the engine working in case it stops working. I don't think they were very impressed to be honest, it felt like they thought it was too simplistic and straightforward.

Other than that, there were some really good points that we haven't thought about. They pointed out that our methodology in doing our project is heavily reliant on technology. This contradicts with the point that our project is to show how heavily we rely on the power grid and technology to do our daily activities. There's a contradiction because we've used the internet extensively to learn how to make those engines and do our research. We've also used laser cutting to cut our engine parts, which is another piece of technology.

Also, we've focused so much on how to get the parts working that we've forgotten the meaning behind our project and therefore lost our compass in taking our project to the next level. Having that conceptual underpinning to give a background and greater context to our work would be best for us, so afterwards the group had a talk about what we want to say with our work.

We're still trying to show how heavily we rely on technology, and how we use technology to preserve our comfort in modern living. People want to do things the easy way because easy is comfortable. This is why people tend to rely on technology; because it's easier.

As for the style, we've decided that it's going to be like being in the workspace of a tinkerer or person who makes things. Basically, our character is going to be a person in the future where technology requiring electricity can't be accessed and he/she is trying to take back the comfort that they had before in life but without relying on electricity so much. Looking for an alternate source of power first by trying to make communications easier.

Tuesday, May 29, 2012

Networks: Switches refined

Tim and Ben got more switches made with some improvements to the design and we tested them out. The switches still look rather crude, but the point is that it works. We found that we needed to make adjustments to the counterweights when we tested them though. The counterweights were too heavy for the ping pong balls.

Also, to make the CD flywheels look a little nicer I peeled off the silvery bits so they're now see-through. It looks much cleaner this way.

Friday, May 25, 2012

Networks: Working

The engines are finally running. It was really surprising because none of us were expecting one to work. We got one working, but the second needs more adjustments.

While Ben tinkered with the engine he gave it some spins of frustration, after it failing to work after a myriad of tries and adjustments. After much profanity, the engine budged and finally got running.

It was a great day.



As a result motivation and morale has risen. I think this would give us more energy in getting through with out project.

Thursday, May 24, 2012

Networks: Everything's Wrong

We've nearly got our stirling engines working, but they're not quite there yet. Ben and Edrian made more adjustments in how the parts are aligned. It's getting better, with the heat the displacer feels like it wants to do something when you wind it because it feels lighter than it should. However, it's still not going yet.


As for the rails, they're going terribly. Tim and I tried bending them into the right shape but the wire proved difficult to work with. Also, when we tested it out I realised that the design didn't exactly make sense. We're going to have to make changes to the design. I don't think they'd be big changes, but I do think there must be a better way to work with this wire.

Feeling pretty demotivated and mildly confused as to what to do as well. Need more sleep.

Wednesday, May 23, 2012

Networks: Simplification

Made all wall of nails and decided to simplify the tracks. We've decided not to add in zig-zags because they're not absolutely necessary. One reason is because we can control the incoming flow of ping pong balls with the frequency at which a ball is brought up to the track at the engines. The second is that time is running out and the making of zig-zags would be more time-consuming.

I haven't blogged about our critique marks yet. Today I'll take this opportunity, since not a lot happened.

We got a not-so-good mark and only now I realise our flaw.

With our presentation, the structure wasn't good enough in coherently communicating the meaning and ideas behind our project. Also, some of use, namely me, didn't talk much. This needs to change. We all need to be more engaging and discard our shyness. Outside of our presentation, I think my group isn't interacting with other people's ideas enough. We should really take in what other groups are trying to communicate so that we can give good critiques, which would be beneficial to both my group and the group in question. I think it would help my group and I to view our project more objectively to effectively solve our problems. These are the things we need to improve on.

There's one group that I've been watching closely. I watch them because I envy them in how well they work together and I view them as the model group. I'm not saying that every group should be just like them, I'm saying that the way they work and fit together is something that other groups can learn from by example. I've talked to one of them and he says that three of them make one programmer while the other two group members take care of the visuals and musical side of their project. I think the reason why they work well together is not only because they click and "speak the same language", but also because their skills compliment each other for the project type they've chosen. They have a nice flow that keeps them going.

In comparison, my group does work quite nicely together. I'm not sure how our current project will turn out, but I can tell you for sure that when I look at our various skill sets we're made for films. We have director material, a fine photographer who knows how to work the camera, an editor and another amazing with effects. Maybe in the future we could work projects to our advantage by leaning more towards film-related options?

Also, by talking to other people and listening to their opinions, I find that my thinking is simplistic and naive in comparison. I'll admit that my mind isn't very rich with life experience because I haven't lived very long in addition to being rather sheltered. I think I need to think and consider more in a wider range of perspectives.

Tuesday, May 22, 2012

Networks: Wall of nails and wire


Today, we made one wall of nails first to test out its effectiveness. We don't want to make all of them only to find out that they don't work, so better safe than sorry.

The test came out quite well. The nails slow down the ping pong balls quite a bit so we can make more of these.

In addition to the wall I also made some spacers for the rails. These are to keep the width of the rails the same distance the whole way through. This way we won't need to worry about keeping the fiddly bits in position with the help of the spacers.

Meanwhile, we still haven't got the engines working. It's looking pretty bleak. What I find with most of our projects is that we really rely on some piece of technology to work in order to complete a project. We focus so much on how to get things working that it feels like the meaning behind the work is lost to desperation in trying to get it to work.

Monday, May 21, 2012

Networks: Measurements+Templates

Today we're fully on track and on task again so I'm really glad. Got measurements down for making the ball tracks and the bits for slowing down the ball and a rough template of how things are gonna fit together.

I showed Tim videos of the wall of nails, spiral of nails and zig-zags that we could be building to see what he thinks. We decided not to do the arc that slows down the balls because it would be too big and chunky. It would be more of an obstruction. The zig-zags however, would be the best option as well as the wall of nails. We gotta keep the sizes in mind so that we don't make them too big, or else we would have a hard time twisting the rails this way and that. We want to keep the rails as straight as possible so that it could travel a little quicker between points. Curves would give a longer path.


Marked out with circles where we would need to slow down the ping pong balls. The places where we need to slow them down are all before the ball meets the switches.

I sketched out the options we have for slowing down the balls and made modifications to suit out needs.

Above we've got wall of nails (the rectangle and trapezoid with diamond arrangement of dots). I'm thinking is we made it into a trapezoid shape we could limit the flow coming off the wall of nails, therefore slowing it down further.

Spiral of nails - To make it slower the pole would be bigger. Bigger pole -> longer path -> slower ball.


For zig-zags, in the previous page I've got triangles making a simple zig-zag. To make more interruptions of momentum it would be better to add thin strips of wood at a very slight angle instead. This also lengthens the path the ping pong balls have to travel through.

Above is also a rough sketch how how the switches would be integrated into the path. There's also a side view with switches dropping down the balls on to wall of nails (trapezoid) and wall of nails (the two straight lines). The second side view drawing is a path interrupted by spiral of nails that joins up to the rest of the path. These are options, but I think we could come up with something better than that.

Zig-zags are a definite thing, so tomorrow Tim and I will be going up to the 3D labs to get working on those and maybe on the wall of nails too since it would be easy to do that.


Here I've drawn the size for the wood on our zig-zags and the spacing between nails. So we could lay this over the wood and cut/nail.

Ben and Edrian are doing really well on their progress on the engines.


They drilled some holes today on the sweet tins and assembled the top part of the engine as well.


This bit is the top part.


This is the diaphragm of the stirling engine. So this is the bit where the air pressure moves it up and down. This is where the cranks is connected to.


We talked about how thinking back on it we should have begun with this engine in the first place, since this one has the highest chance of success. We only canned this one in the first place because the materials weren't as common as the previous designs. However, we agreed that if we did do this first we would never have thought to laser cut the parts and would've spend many frustrating sessions trying to get the precision right up in the 3D labs. So it's kind of a good thing that we failed several times before moving on to this design.

Friday, May 18, 2012

Networks: Thinking

Thought more about the track. A way to stop tracks from smashing into each other would be to add curved tracks. Keep the main tracks, the ones that have the most switches, straight and have the rest curve around these ones.

Another problem is that if a ball is going down one track to be redirected to another at an engine, it can only redirect correctly if its weight is heavier than the weight designated to the engine it's approaching. A way to get around this would be to put more switches at the end of that track to differentiate between balls arriving at their final destination and balls moving to a new track.

I also found some more ways to slow down the flow of ping pong balls going to the switches. The previous ones considered were the dish and the zig-zags I mentioned. The dish won't work because it would have to be huge to make a ping pong ball go around and around. But the zig-zags will and will most likely be included.

There are three more different methods that I think we could do.

Two I found in this YouTube video (Denha, 2011):



In this video I'm interested in the spiral of nails and the wall of nails on the left. They both seem to slow down the balls quite well, possibly because spacing of the nails interrupt the momentum of movement. The spiral of nails also makes the path going down longer since it's coiled up.

Figure 1: An alternative track that slows down marbles (Source: Wandel, 2011)

The third is an alternative to the dish. It's basically a path that's curved into a c-shaped tube with a hole in the middle. So when the balls go in and zip left and right across the path, it eventually loses momentum to fall at the bottom and leave via the hole.

Last night I prepared some files in Illustrator so that we could use the laser cutter to cut our parts from wood. Decided to use laser cutter because that would give us the precision that we need and it's very fast as well.






___________________________________________________________________
Reference List:

Denha. (2011, September 28). Mangle marble machine [Video file]. Retrieved May 18, 2012, from http://www.youtube.com/watch?v=qHAum0izptU&list=UUQLeSzI5oBVHxPFz-PFQxMw&index=9&feature=plcp

Wandel, M. (2011). Marble run building blocks. Retrieved May 18, 2012, from http://woodgears.ca/marbles/run.html

Thursday, May 17, 2012

Networks: A little less confused

Brought in some polystyrene and coloured string today to map our where the rails would go.




Now that I can see what's happening it's actually not as complicated as I originally thought. The hard bit would be how to get the switches to redirect paths automatically if one line is taken out and how to use another sort of switch the differentiate between balls arriving at their final destination and those that are just moving to a new rail at a particular engine.

I don't have that automatic bit figured out yet but for switching to a new rail a way to do it would be to have a flip flop switch on the original rail near the destination. If the weight doesn't match the weight for the station the ball would be redirected to a different pool where the turning engine will scoop it up and drop it on a new rail. If it matches it goes to a regular pool that doesn't go anywhere.

Before actually making it I want to get a basic design down so that we know what we're doing when we go to the 3D labs. I don't want to waste any materials and especially not time.

Wednesday, May 16, 2012

Networks: Calculations and Confusion

To be completely honest I feel rather slow and lethargic at the moment, but we did get some work done for the switches.

The switches and rails were more complicated than we originally thought, especially because it's hard to see what's happening on paper.

However, we decided that short switches weren't going to work because it wouldn't have enough time to flip over when the weight of the ping pong balls arrive. So Tim went up to the 3D labs to cut and drill some switches at a decent length.

I began to calculate roughly how long the rails would need to be if they were straight. I drew up a diagram first so that I could see where the rails needed to go.





A is the lightest weight and D is the heaviest weight. The numbers represent which weights would trigger their switch first. So 1 would leave for their destination first, 2 would leave second and 3 would stay on the original rail to its destination.

As seen in the diagram there are various points where the rails would most likely intersect, especially in the middle. We can't have any of the rails touching or else the ping pong balls would get trapped. Gotta think of a way to get around it, but it's really confusing at the moment because even drawn on paper I can't really see what's happening clearly.

The engines on the other hand are seeing some development. We found that the displacer and cranks cause too much friction against the can. This stops it from running. So at the moment we're looking for alternatives, preferably not something as flimsy those coke cans. We found that they would keep cracking and so we couldn't get the engines to be air-tight enough. The displacer was also too heavy to move on its own.

The pace of our work, I feel, is slow because for some reason we're really not motivated and I think that is the main problem at the moment. I think if we keep on trying, maybe eventually we'll get more hopeful that things will go better and we can build up our energy from there.

Tuesday, May 15, 2012

Networks: Priority on switches

We did a few more tests this morning after some adjustments and I saw that Ben has most of his parts assembled for his engine. However, the testing also failed. It was a bit better than previous tests though. It feels like the displacer wants to move, but it doesn't really make it.

My group filled me in on the advice and suggestions our tutors gave us. Julian told us to place priority on the switching and the rails. Not only because we'd have a working system even if the engines fail, but also because the switches is where things will get interesting.

Daniel gave a pretty cool suggestion where the messages are represented by 8-bit info and it is fed into an Arduino, which is then read by a computer. However, we can't do that even though that does sound interesting because the setting of our project is in a world where we can't access any form of electricity. Therefore, we can't do that.

Monday, May 14, 2012

Networks: Demotivated

We tried again at troubleshooting today with the failed engine and Ben plans on making an alternate design.

Overall, we're feeling demotivated at the moment because we spent so long and so much effort in building the first one.

I had to leave early today due to an appointment, but as I was leaving Julian came over to have a chat to the group. Hopefully we have some hints and tips on what our problem might be.

Friday, May 11, 2012

Networks: First Test



Late today we finally got an engine built we prepared more parts for other engines.

Edrian made the cranks since he has a knack for making them and we went up to the 3D labs to drill holes in the bolts.


So once we got the parts sorted we decided to test the first finished one out to see if it would work.

It didn't. D:


I think it might be the displacer, which is made of steel wool. I think we might have made it too small for the can and therefore we don't have that heated air contained enough to move the displacer. So the heated air moves around the displacer instead. Other factors that may be a cause of failure could be that the engine is either not air tight enough or the diaphragm is too tight.

Also, the silicone seal on the cooling jacket has gaps in it so it leaks. However, this shouldn't stop it from working, so I don't think that is where the problem is.

Thursday, May 10, 2012

Networks: Weights and flip flops





Got working on flip flop switches today and stripped the casing off more chocolate blocks for Edrian today. Now that we have ping pong balls of differing weights we made a really simple prototype of our flip flop switches. We sorted out the counterweights as well.

1 doesn't need any counterweights because it's the completely empty ping pong ball and needs to stay on the original track.

2. 5g counterweights
3. 15g counterweights
4. 25g counterweights

Will need to see if these are enough because they're only a 5g difference from the weights of their respective ping pong balls.

The switches must be sensitive though, which is the main obstacle we'll hit for the switches.




Another thing is how the rails will shape around the switches. Since it's a rail, there needs to be a dip somewhere to let the ping pong balls fall when they need to. Thus, an option would be to have a dip in the rails with some additional side rails spreading out to allow for the fall while keeping the balls that don't need to fall yet on the path. The rails dipping down are also necessary to hold the switches in place.

So far, things are falling into place and happening as planned according to schedule. I'm still waiting for everything to go horribly wrong though so that we can all be prepared when it happens. I know it sounds pessimistic and maybe a little bit irrational given that there is no evidence at present of things going wrong, but I don't want to celebrate until we've given our absolute best shot at this right till hand in.

Wednesday, May 9, 2012

Networks: More building

Continued with building today. Now both engines are being built, but I see more progress happening with Edrian's simple engine though. He's been super productive and really on to what he's doing.

He found a tutorial so he knows what he's doing. I think that's the difference between today and yesterday. Yesterday, things didn't go so well because there was some confusion on how to build the more difficult engine. However, today now that we're clear productivity has also increased.

Tim and I helped out by preparing chocolate blocks for him today since we didn't have much to do yet.

I feel like I should be doing more, but today there really wasn't much to do.

Tuesday, May 8, 2012

Networks: Begin building

We got all the materials and began fully building today. We decided to put making the engines a priority today because Tim and I can't finalise the rails unless we know what the stirling engine design is, to make the connections work properly from engine to rail.

We managed to source our final materials as well. As mentioned in my previous post we found a design that we could make more easily, however, Ben still wanted to make the one we originally planned on making. So Edrian will take care of making the simpler one tonight while we start on the original one today.


We read through the instructions many times to make sure that we understood what we were supposed to do.


Once the cans were cut I filed down the sharp edges so that it won't be so easy to cut yourself on them.


Here Ben's seeing if the template we corrected is right for the can.


Edrian and Tim helped to saw some chocolate blocks in half.

Personally, I think it would be more efficient to go straight into building the simpler one because it would save a lot of time and would have less trouble. But when you're in a group you need to know when to object and when to let people go ahead and do their own thing.

The instructions for the original were confusing, but I heard from Ben and Edrian that in the end they broke the firebox they were making by accident. So they'll try again tomorrow to get things right.

When Tim and I left we started getting the ping pong balls ready by putting small holes in them so that we could fill them with water to control the weights. Also got a syringe from Daiso across the road to fill them. So I did that, and filled them with different amounts of water.




1. Completely empty
2. 10mL
3. 20mL
4. Full up 30mL

Next step for Tim and I would be to see if these weights would be fine and to see how much the counterweights need to be in order for the flip flop switches we're making to be effective.

We've decided that we can't use the dish vortex to slow down the flow of ping pong balls going to the switches. This is because the hole would need to be big for a ping pong ball to go through and therefore the dish would be proportionately huge. Thus, we can't use it because it would be way too big. An alternative we could try out would be the zig-zags I posted about earlier.

Monday, May 7, 2012

Networks: Change of plans

Yet again, the day was rather uneventful, so there's not much to write about. We did, however, change the kind of stirling engine we're building though.

I got most of the materials we needed to build a stirling engine over the weekend. When we went through instructions though, we realised it would be more difficult and unnecessarily annoying than we thought. So we found a better, simpler design that we could use instead by the same person.

I still think we're going to run into various problems though, but as long as we keep the pace up I think we can do this in time at an acceptable standard if not better. I feel a little bit unmotivated, but I think that would be because it feels like we're not doing anything and we don't have a solid object yet. I have a feeling it would be much like the movie we did last term; none of us would feel productive until we have something done that's solid.

We've got nearly all our materials, we can source them all by tonight and have them ready. Tomorrow, I think it would be beneficial to read through the instructions to have a very clear idea of exactly what we're doing and how to do it. Highlighting would be good. We need to name all our restrictions so that we have them in our mind to adjust the designs if needed. Then one Wednesday we can get straight into making things. We'll also prepare our materials for assembly tomorrow as well.

Wednesday, May 2, 2012

Networks: Mini-presentations

Today we had our mini-presentations and critiques on what exactly we're doing for this term. Our tutors today were James and Clinton.

First, we showed our film that we did for last term to put this term into context. The setting of the project is the solar flare and we talked about the basics of how we're going to go about building the system.

We got some pretty good feedback, which I'm pleased about. I was especially pleased about the feedback on how my group has clearly defined roles for each member and how this is a signature of how we work as a group.

The main advice we were given was to be careful about how our work translates across to the audience. This would be affected by our choice of materials and the design of our system.


Overall, the feedback was good, just need to think about what our system might mean to other people.

So tomorrow, it would full on designing. I want the basic designs down tomorrow so that we can get to experimenting as soon as possible, preferably begin experimenting on Friday.

For tonight, we'll go our separate ways, and think up ways to make a rotating wheel that can pick up the spherical packages and put it on the track. Also, what to use for the spherical packages.

Tuesday, May 1, 2012

Networks: Splitting of the Group

Talk about splitting the group in half. One for steam and another for rails. Explain why we're split this way and put in scans of your drawings.

We talked to Andy today about our project and where we're up to. It went pretty well I think. One thing I'm glad he brought our attention to is how complex our switching for the branching paths can be and how we need to differentiate between which packages go to which point so that we can still automate the routes even if one particular line is taken down. This is what a lot of the problem-solving will be about I think. Many calculations and adjustments.

We also decided that we should narrow down our network to serve a particular purpose. The setting of this project is post-solar flare, as mentioned before. So the primary purpose of this mailing system to send messages and maintain communication between areas. Therefore it's restricted to sending written messages only as opposed to objects and supplies, which I assume is best done in person so that you know what happens to it and where it goes.

This way we can also restrict our capsules to be a uniform shape. In this case, the best shape would be a sphere. It can move easily along tracks, which will be like pinball tracks, and it's the easiest shape to work with.

Our best bet is to trigger our flip flop mechanisms with specific weights. So we've got same shapes, but different weights to trigger out branching of tracks. This can be done by the flip flops I talked about before in my previous posts. For slowing down the flow of packages, we could use some sort of bowl with one hole at the base and zig-zags.



The bowl has curvature, so when a spherical package is shot near the rim it goes around and around the bowl. This slows down the package and only lets a certain number of packages go down at a time (Wandel, 2007). The best for us would be one at a time, so that there's enough time for the switches to reset properly.


(Matthiaswandel, 2007)


The zig-zags I'm talking about can be seen in this video, it's the structure with slopes and obviously look like a zig-zag:


(Matthiaswandel, 2010)

The zig-zags can also slow down the marbles. As the marbles fall through each hole, their momentum in going down the slope is interrupted. Therefore slowing it down a little bit, but down a slope it gains momentum again (Wandel, 2010). Thus, I can control the speed at which the packages roll down a zig-zag by using a slope at a low angle, and controlling at what height the package drops on to the slope. The drop is important, because it gives a brief interruption to the momentum, but also because if the height is too high, the package might roll off and bounce off the track.


Also, we've split the group in half for maximum efficiency and according to our strengths. We have the half that builds our stirling engines, and the other half that makes the switches and tracks. Ben and Edrian are better at making things, so they're grouped to make the stirling engines. I'm better at doing calculations and Tim has a good understanding of physics, so we're in charge of making the tracks and switches. To make sure that each half knows what the other half is doing and whether anything one half does affects the other, I'll be checking on both groups to make sure both sides are up to date on what the other half is doing. This also makes communication easier, and more control over how the group works as a whole. For example, if Ben and Edrian change an aspect of the stirling engine design that the tracks group doesn't know about, they might need to end up redoing all the tracks and calculations to make up for the change. This is why communications between two halves and having a person to oversee what both groups are doing is important. It's so that there's less of a chance of messing up because of insufficient knowledge about what the other half is doing.



____________________________________________________________________

Reference List


Matthiaswandel. (2007, April 25). Marble machine 2 [Video file]. Retrieved May 1, 2012, from http://www.youtube.com/watch?v=9Z2A6qJyURY&feature=player_embedded

Matthiaswandel. (2010, October 10). Marble machine 1 (more detial) [Video file]. Retrieved May 1, 2012, from http://www.youtube.com/watch?v=SHPC7GVg1Zk&feature=player_embedded

Wandel, M. (2007). Building Marble Machine 2. Retrieved May 1, 2012, from http://www.sentex.net/~mwandel/marbles/machine2.html

Wandel, M. (2010). Marble Machine One. Retrieved May 1, 2012, from http://www.sentex.net/~mwandel/marbles/machine1.html