Rubikon

By taking inspiration from the original Rubik's Cube we propose a new way of interacting with a personal computer. Rubikon is an independent interactive device which can, not only be used as a controller, but also a personal device. Over the period of 8 weeks we created a prototype which can be used to control a number of applications on a user's personal computer, as shown in the video below:

For any new interactive device it's success depends on user feedback; Rubikon is no different. A group of fifteen individuals were asked to independently carry out various tasks, such as navigating through the file system, using the Rubikon and. They were then asked to rate their experience on a scale of 1 - 5 with 5 being very intuitive. The results of the experiments can be seen in the graph below:

The general consensus among the participants was that it was very straight forward for them to interact with the personal computer using their basic knowledge of physics and how various applications worked.

This work in progress device can be made standalone and platform-independent. This can be achieved by adding wireless connectivity, replacing the current Arduino board with a smaller integrated controller board, and adding a portable power source.
In conclusion, Rubikon is a highly configurable independent device enabling a diverse set of interactions. Despite having many degrees of freedom and a large number of possible rotations, use remains intuitive and easy to master.

Software

Having finished building the cube I decided to help out the software team. For the demo Vlad, Rupert and Max had implemented an OpenFrameworks application which took input from Arduino code. However under certain circumstances the input received by OpenFrameworks wasn't exactly what was sent by Arduino, so I suggested a way of getting around that.

Apart from that, me and Vlad spent a good few hours researching how we could run the OpenFrameworks application as a service in background so that when Windows is locked, the user can simply use Rubikon to log in. This however proved unsuccessful, but it is nonetheless still achievable when the entire application is written as a service.

Modifying the core - Part 2

Now that I was able to reassemble the Rubik's Void around the core and all the encoders were in place, the next step was to attach the custom-built mechanism to the cube so that when a side of the cube is rotated, it rotates the corresponding encoder as well.

Upon attaching the mechanism it turned out that it's bottom layer was thick and therefore prevented movement of parts of the cube (as discussed in Designing parts of the cube). This is caused by the shape of the core; since the core is spherical some part of it comes out of the centre of Rubik's Void (shown in image below).

At first I spent couple of hours grazing the bottom layers along the path where each side moves. This however proved to be unsuccessful. So I was faced with 2 choices, either design the bottom layer of the mechanism to be spherical in shape, so it could perfectly fit the shape of the sphere, or modify the core so that the area around the encoders is flat, to match the shape of the bottom layer of the mechanism. Images below.

I explained the problem to Vlad and he suggested modifying the core because we couldn't think of a way to make a spherical bottom layer. So after spending couple of hours making areas around the encoders flat, I was finally able to reassemble the cube and perfectly fit the mechanism around all the encoders. The mechanics of the cube worked as intended, i.e. when each side of the cube was moved it in turn moved the encoder it was attached to, and each encoder could also be used as a button. Below is the picture of the final Rubikon:

Modifying the core - Part 1

Having built the core for the cube and the mechanism which will rotate the encoders when sides of cubes are rotated it was time to build the Rubik's Void around the core and put the mechanism in place.

After me and Madalina built the cube around the core by de-assembling the Rubik's Void and then reassembling it around the core we came across a bit of a hurdle. When drilling holes in the core for the encoders we weren't very precise about their location. This, as I insisted during the process of drilling the holes, has caused the encoders to be misaligned with respect to the sides of the cube (image below).

At this point Madalina had to leave so I now had two options: I either buy a new sphere and rebuild the core from scratch, or just modify the existing core by turning the encoder holes into rectangles along which the encoders could slid. The latter option was more appealing as it required less time and since the encoders came with a bolt it was easy to tighten them in the place best suited with respect to the side of the cube.

After few hours of modification to the sphere I reassembled the Rubik's Void around the core and tightened the encoders in place when they were centered with respect to the side of the Rubik's Void (image below).

Designing parts for the cube

Having built the core and tested the functionality of the encoders inside it the next step was to build mechanisms which will rotate the encoder when the corresponding side of Rubik's void is rotated. Currently a side of the cube looks like this:

The mechanism will go where the arrow is pointing. Together me, Vlad and Madalina gathered ideas about how to build such a mechanism. Upon taking apart the Rubik's void, I noticed that each small cube on one side of Rubik's void slides along the square below. The arrows indicate the path in which the orange cube can move along.

So our mechanism would need to be attached to the inside of the square (in the ring). We could simply design a circle as shown in the image above however as we can see in figure 1, due to size constraints the encoder comes quite far out of the side. Therefore the circle will need to be really thick. This however creates further problem since the encoder varies in shape along it's height; therefore we needed to design different layers and put them together (image below).

The top-left design is for the top layer, bottom-left design is for the middle layer and the one of the left is for the bottom layer. The reason the top 2 layers are smaller in diameter is because when smaller cubes are moved they slide over a part of the circular hole. We decided to make the above layers using a laser cutter as it's accurate and fast giving us time to perform trial and error. Vlad designed the above layers using Adobe Illustrator and then we used the laser cutter in MVB HCI lab to build them. The material used was acrylic, however due to the shape of each encoder the height of layers was varied. The top and bottom layer was 3mm each where as the middle layer was 5mm.
Once we built the layers we realised that we needed the middle layer to be a bit thicker, but since we didn't have any thicker acrylic sheet we used an additional 3mm layer of the same design. Following is an image of all the layers super-glued together:

Building the core - Part 2

Next we needed to decide which ball to use as our core and make some holes in it. I proposed to go with the following ball as it was largest in size (allowing for more space for the encoders and the wires) and was also slightly deformable (with high resilience) which meant it would be easier to make modifications to it further down the line if need be.

First we dissected one side of the sphere to allow for wires to come out from. Then after quickly getting trained to use the drill machines in the workshop, me and Madalina made 5 more holes in the sphere. Since our calculations weren't precise the holes were misaligned and I was quite concerned about this. However, the sphere was made out of easily deformable material, therefore I decided to let go of it for now and make modifications to it later when building the cube on top of the core. That way I will know precisely where the holes need to be. Below is the image of our core after Madalina fitted all the encoders inside it:

The next task was to connect all the encoders to the Arduino. We had 40 (5 x 8 ) wires to connect, however the Arduino we had been provided with only had 13 ports. After Vlad borrowed a bigger Arduino, Madalina spent few hours connecting all the wires and writing a program to communicate with all 5 rotary encoders, their RGB LED's and their push buttons. Below is an image of the core fully connected to the Arduino:

Building the core - Part 1

The next step in the process was to decide how we were going to build a sphere with 6 holes (5 for encoders and 1 for wires). Since the video demonstrated fitting a golf ball inside the Rubik's void, I suggested we buy a golf ball and modify it to suit our needs. Madalina then went and bought a few golf balls, however upon partially dissecting one she realised that it'd quite difficult to make the ball completely hollow. So we decided to shop for a hollow ball of the size of a golf ball (or ever so slightly bigger).

Since it was quite late (past 5pm) Madalina proposed that we could try use the 3D printer instead; I was on board with the idea as it would allow us to be precise about the locations of the holes (very important further down the line) and also give us an opportunity to develop new skills.

Vlad, however, suggested that since building the sphere is going to be more of a trial and error process (as we weren't sure about the exact size) we shouldn't use the 3D printer as it could take many hours to build a model. He insisted on shopping for a hollow ball. So me and Vlad went to cabot circus and after sometime decided to purchase the following 3 balls as they were all able to fit inside the Rubik's void.