Week 6: Testing and Evaluating The Prototype

Given that the code prototype was finished last week and the hardware prototype was finished the week before that (until the rangefinder broke and got replaced) the last week was dedicated to testing and evaluating of the prototype and deciding what we would do differently if we were to do this project again.

First of all we did a scan of Fabio in the library. Apologies for the bad audio quality, the laptop we recorded this on was throwing a fit.

From this we were able to conclude a few things about the current prototype. It does not produce a high fidelity scan and is prone to artifacting depending on the properties of the surface being scanned. However the prototype did manage to produce a scan that showed a rough outline of what was scanned. This leads us to believe that with a sensor that has a greater range the project could actually be usable to produce accurate scans.

In order to validate our results we carried out multiple scans at varying distances from the target being scanned and got some interesting results. The scans taken from further away produced more accurate shape silhouettes with less distortion but far less depth resolution which also made them very vulnerable to any artifacting that occurred. This further validated our theory that a sensor with a greater range would produce better results as it would be able to maintain depth resolution while not being susceptible to fish-eye distortion.

We also tested scans very close up to the target object. This produced highly distorted scan images to the point where objects were unrecognisable due to how extreme the fisheye distortion effect was.

Week 5 - Making Prototype Code, Sharp Rangefinder Not So Sharp Any More

Sharp GP2Y0A21YK0F

Sharp GP2Y0A21YK0F installed into the case lid

During development of the prototype code we hit several roadblocks. The first of which being that the Sharp 2Y0A02 rangefinder module died during testing of one of the revisions of the software prototype. This was particularly difficult to diagnose because it did not go suddenly, but rather it gradually deteriorated over the course of a few hours to the point that the readings were no longer readable. Fortunately Fabio was able to source a new rangefinder from Amazon, the Sharp GP2Y0A21YK0F, and order it with expedited delivery so that it was delivered within the week. We had originally ordered a second Sharp 2Y0A02 rangefinder but the supplier informed us that they were out of stock and on short notice the Sharp GP2Y0A21YK0F was the only one we could get a hold of. The Sharp GP2Y0A21YK0F had a more limited range, making it less ideal for the project than the Sharp 2Y0A02, but still worked to give some reading at least and allowed Liam to continue developing the code. The new rangefinder also needed to be modified as the old one had been to mount more easily to the front of the case. Fabio performed the modification differently this time however as it was suspected that the modification may have been the cause of failure for the dead rangefinder. This time he simply swapped the cable plug from the front side of the sensor to the backside, rather than removing it altogether and replacing it with wires as had been done with the previous one, which had actually caused some of the PCB to peel from the strain.

The second roadblock we encountered was when the accelerometer and gyroscope module suddenly stopped working during development. After a couple of hours of debugging and testing however this issue was tracked down by Fabio to be caused by a poor solder join on the VCC pin. After Fabio re-soldered the join Liam was able to continue development.

Liam also encountered some code-related issues whilst developing the code. The accelerometer and gyro module would read as being rotated to a roughly 90 degree angle when the device was held as intended. This was due to the fact that the way the module was mounted inside of the case was not being compensated for. This was solved by using the first reading from the module as an offset for all subsequent readings.


By the end of the week the code prototype was finished:
https://drive.google.com/file/d/0B5ZXvoDnC39FR1VnenNDbF95b2s/view?usp=sharing

Week 4 - Sick 3D Printing or Sick, 3D Printing... Also soldering

This week Fabio got sick, so Liam had to finish the 3D model to get it printed on time. In the end it took around 6 hours to print, but the result was a durable, lightweight case that fit almost all dimensions of the components perfectly. However there was one error in that the hole for the USB port on the 3D model was positioned incorrectly due to an error made when reading measurements off a diagram of the Arduino Uno. This was corrected by cutting a chunk out of the case on one side of the hole and hot glueing it to the other to move the hole along.

Finished case 3D model

The 3D print in progress

While the case was printing Liam also soldered the cables for the rangefinder and laser modules, as well as the shield board and gyro and accelerometer module.



Afterwards the parts were assembled together to produce the complete prototype.

Shield board underside

Shield board topside

Soldered rangefinder and laser with cables

Case lid back

Rangefinder stoppers

Case lid front

Case body inside

Case body ports

Case lid finished front

Case lid finished back

Case complete finished inside

Week 3 - Breadboard Circuit Planning, The Gyro Lives! and Re-Scoping Because Arduino Can't Camera

Over the winter holidays and week 3 the new shield board has arrived. Liam soldered the pins to the board so that it can plug into the Arduino. He also attempted to get the camera module working but the libraries available for the OV7670 either did not compile, required a different version of the OV7670 with FIFO memory on-board, or required an expensive shield board with FIFO memory as a substitute for on-board FIFO memory and would use all pins on the Arduino. Writing our own code to interface with the camera module without the use of libraries was considered, but upon inspection of the documentation revealing that the camera has 8 data pins that would need to be read from simultaneously it was deemed that doing so would be far beyond not only the timescale limitations of the project but also the abilities of the group members. In the end we decided to re-scope the designs of the product and drop the camera module in favour of making the product into a phone accessory so that we can use the integrated camera on the phone instead.

Fabio was able to get the gyroscope and accelerometer module working with the I2C library's teapot demo over the winter break and has begun work on the 3D model to print for the case.

After Fabio got the accelerometer working Liam then used it to build a breadboard circuit to prototype the layout of the circuit for the solder board.

The next week will be spent soldering the components to the shield board and printing the case to hold the components.

After the prototyping of the circuit on breadboard was done a circuit diagram was drawn up in fritzing by Fabio to use as reference when soldering the components.

Week 2 - Testing Components and Attempting to Frankenstein a Shield Board

This week we set about testing the components and making some adjustments to the design based on the results of these tests. Unfortunately we still haven't figured out how to get the OV7670 camera module working, Liam will be attempting to get it working by the end of the winter break. If he is unsuccessful then we will look for alternatives and according adjustments to the design will be made.

I2C Accelerometer and Gyroscope Module (GY-521)

Fabio has tested the analogue accelerometer and he has found that it does not detect any rotation around the pole of gravity, meaning that in order rotation on a horizontal axis (which is required for the basic functionality of the device) we will require another sensor. After some research it was found that a gyroscope can fix this problem and as such an I2C accelerometer and gyroscope module was obtained from Damian Hon, a fellow student in the class that had ordered a large number of the modules and had spares. While the module will be less easy to work with than the analogue accelerometer module, it will be better suited to the purposes of this project.

Frankenstein'd solder board

Liam has tested both the rangefinder and laser modules has confirmed that they are fit for purpose. He has also been attempting to figure out how to extend the solder board further as it currently is not wide enough to reach the appropriate pins to serve as a shield given the fact that the new accelerometer and gyroscope module requires use of the SDA and SCL pins. An attempt was made to Frankenstein two of the existing solder boards together but it was pretty clear that this was inadequate and would not work correctly. The decision was made to instead order a solder board specifically designed for prototyping Arduino shields from Amazon. The new board should arrive next week.

Additionally two changes in the interaction design of the prototype have been made during a group meeting. The first change is that the device will no longer scan 3D points using a point and click system to scan each individual point in 3D space; it will instead use continuous sampling to generate a height-map which can then be used to construct a detailed mesh via tessellation and deformation of a flat plane. This was done to improve the ease of use for novice users and decrease the amount of time taken to perform a 3D scan in most cases, especially when high detail is required. The second change is to the design of the device housing as it has been changed from a laser-pointer style design to compact-camera style design. This was done to increase the ergonomic familiarity to the user.

During the winter holidays Liam will be attempting to get the camera module working. Fabio will be attempting to find a library for and test the I2C accelerometer and gyroscope module.

Week 1 - Looking for parts

Seeing as this is the first post on the development blog for the 3D Take-Away project, an introduction to the project is in order. 3D Take-Away is a project by Liam Robinson and Fabio Peres Filho that seeks to bring 3D scanning to a handheld form factor, so that 3D designers and artists can scan almost any object that inspires them to create a rough 3D reference image while on-the-go to use as a base for making a full detail model later.

To start the first week we decided to begin the project by looking for parts in order to begin building a breadboard prototype for testing the next week. We used numerous sources to acquire the parts, including ordering parts on amazon.co.uk and salvaging spare parts from old household electronics.

Figure 1 - Arduino Board

To control all of the inputs and outputs of the project we chose to use the Arduino Uno (Figure 1) given that both group members had one, so if one broke we would have a spare, and because we were familiar with the Arduino IDE already.

Figure 2 - Accelerometer Module

Figure 3 - Rangefinder Module

In order to generate 3D co-ordinates for the scanner we would need an accelerometer to read the orientation of the device (figure 2), in combination with a rangefinder to get the distance between the scanner and the object it is scanning (figure 3). For these purposes Fabio hunted down the GY-61 analogue accelerometer, which would be ideal for use due to the fact that the readings could be taken from it using the analogue input pins on the Arduino. This would be far easier than using, for example, an I2C accelerometer as we would only have to read from the pins and would not have to deal with reading data buffers. He also found the Sharp 2Y0A02 Long Distance Measuring Sensor which also gives an analogue output, making it easy to detect the range between objects and the sensor at distances as low as 20cm and up to 150cm. The rangefinder was modified by Liam to mount more ideally to the front of a case by removing the plug on the front of the module and replacing it with wires coming out the back of the module. During the modification some of the PCB was damaged, but through some more modifications the module was salvaged. Both the accelerometer and rangefinder were ordered from Amazon.

Figure 4 - Laser Module

In order to see exactly where the device was pointed we needed to obtain a laser module (figure 4). Rather than ordering one, Liam managed to salvage one from an old battery powered laser pointer. Getting it working without a connection to the battery and casing was a process of trial and error as Google searches for it's part number, assumed to be ZY65A as it was the only marking on the board, only returned results for sex toys and did not yield a datasheet.

Figure 5 - Camera Component

We also wanted to get a texture for the object being scanned, as such we would need a camera (figure 5). Liam managed to acquire the OV7670 camera module via Amazon for this purpose.

Figure 6 - Arduuino with a "shield" board

In order to tie all the components together we would also need some solder prototyping board (figure 6). Liam ordered some of this from Amazon as well as some header pins so that the combined components could act as a shield for the Arduino.

Next week we plan to be testing all the components and making any necessary adjustments to the design.