Jeremy’s Status Update for 2/15/2020

This week I did research comparing different 3d reconstruction options as well as a bit of research on texturing 3d scans. There are several possible scanning options, some of which were suggested by Professor Tamal. These include RGB-D camera (gives depth information on each pixel using coded light), time-of-flight single point (one laser point with depth using time-of-flight), time-of-flight vertical line (like a barcode), and time-of-flight laser 2D depth map. 

The time-of-flight single point laser scanner was the lowest priced option, but it was difficult finding many papers that used this method due to being very prone to mechanical errors, as well as being rather time-costly and complex mechanically. There were a few possible ways of executing this method which included the spiral method, where the laser point would slowly move down vertically while the object rotated. Depending on the controlling mechanism, this method would be prone to missing a lot of points scanned, especially if the laser shudders or other mechanical errors. A way to make this more efficient would simply be to use several different laser points since each was not very costly; however, the same issues would still arise. 

The RGB-D camera using coded light was one idea we were very interested in, especially given that the camera would already help us do some of the processing to get the depth data. This would also allow for texture mapping, something that would be missing from the time-of-flight sensors (unless we combine those with camera data). This method would be less prone to error depending on our depth camera, and among the few options we looked at, we would most likely use one that can give within 1mm accuracy for depth data. This method would also allow for correction for bias using color data potentially. The price is also not too expensive (less than $100 for the coded light depth camera), which fits our requirements. However, we may need to do some work in figuring out confidence intervals for the accuracy ranges and determining if this reconstruction method would be able to figure out the depth accurate enough to fit our requirements for accuracy. 

The laser-based approaches are still intriguing since time-of-flight lasers can usually give micrometer accuracy since we determine the exact distance using wavelength and time-of-flight data. This led to an idea from Professor Tamal to use LIDAR (1D/2D) for the scanning. The 1D LIDAR would behave like a barcode scanner with a vertical line to scan and the object rotating, but there may be certain complexities to explore with this method, and there have not been a lot of previous work using this method. The 2D LIDAR would be even more accurate and gives an accurate depth map, but it would cost quite a bit more. This method is certainly very promising and deserves extensive research to compare with the RGB-D camera method. 

All of these methods would potentially require some filtering or smoothing techniques to remove the noise from the data, but the RGB-D camera and the 2D LIDAR would probably give us the easiest time in managing and converting the data into a 3D point cloud. Since the data is 2D, however, we would need to cross reference points and map several scans from different angles back into the same object, which would be one of the main algorithmic complexities of our project. We would also be able to leverage the rotational position of the platform to help us determine which pixel maps to which exact 3D point in space. 

Thus, in the coming week, I will have to dive deep into researching the RGB-D and 2D LIDAR methods and doing more extensive comparisons between the two, and referencing their qualities back to our requirements. So far, a lot of our research has been very breadth based, since we were considering a large variety of options, such as previously considering using two cameras and computer vision to do the scanning. However, my research goal this week is to narrow down on the specific idea we use and justify it with qualities we look for based on our requirements. I will also be doing more research on piecing together scans from different angles, as well as working out math to figure out a 3D point given a pixel, depth, and camera position, as this will be necessary information for our algorithm later on regardless which scanning mechanism we choose (both will output depth data).

Table for Comparing Possible Sensors

Sensor Cost Mechanical Complexity Pre-Filtering Complexity (estimated) Potential Sources of Error Texture Mapping Algorithmic Implications
RGB-D Camera (structured/coded light) ~$70 Low High Less accurate than laser time-of-flight approaches, noise Possible Color may allow better matching with ICP
Time-of-Flight single point ~$10 per sensor High Medium High risk of mechanical errors No Direct computation of point cloud, no ICP
Time-of-Flight vertical line ~$130? Medium Low Noise (but less error than 2D?) No Direct computation of point cloud, no ICP
Time-of-Flight 2D depth map ~$200? Low Medium Noise No Direct ICP available

Team Status Update for 2/15/2020

For this week, we did a majority of the work as a team. After getting feedback from the Proposal Presentation, we realized that our user-story was too vague and that some of our requirements were not as clear and quantifiable as they could be. As a team, after doing more research, we narrowed down the scope of our use-case to just archaeological documentation and refine our requirements to fit our use-case more. For example, we made the error rate for accuracy depends on the object size dynamically instead of just static measurements. We redefined our usability requirement to include the input object size and weight limit and redefined our time requirement to be one minute. We also refined some other requirements. As a team, we also discussed different sensors we researched on to use for the project. 

Currently, the most significant risk we have right now is that we have not finalized the type of sensor to use yet, so we might be a little behind the schedule in terms of ordering parts. We are managing this risk by starting other tasks that could be done in parallel such as researching more on the common pipeline generally utilized in 3D Mesh reconstruction from raw depth data. We also assigned everyone on the team to do more research on different sensors available. We first agreed on using Intel real-sense depth camera (RGB-D camera using coded light), but was suggested by Professor Mukherjee to look into 1D/2D laser array/LIDAR sensor which could be more accurate and time-efficient. All of our team members are working on this to be able to finalize the sensor by this upcoming week and get back on schedule. Another risk factor we have is our lack of expertise in mechanical engineering and robotics. The rotational mechanism and platform design seem to be more complex than what we initially thought. The rotational mechanism is a crucial part of our system no matter which type of sensor we use. This risk is being managed by letting Chakara take care of the part and he only has to worry about this part for the upcoming week. We also started seeking advice from someone with more expertise in the area. 

As mentioned earlier, there were some changes made to the requirements and use-case. The changes were necessary for us to be able to narrow down the project scope to be able to finish it in the given period of time. They were also necessary since we need requirements that are more clear and quantifiable to use them as metrics. These changes cost us time from last week but made our project goals and scope clearer which will benefit us in the future. 

Below is the link to our updated schedule. Or you could also refer to our “Project Schedule” section.

https://docs.google.com/spreadsheets/d/1GGzn30sgRvBdlpad1TIZRK-Fq__RTBgIKN7kDVB3IlI/edit?usp=sharing