Conclusion

So Did It Work?

Our algorithms (in our simulation) were effective at autonomous frontier exploration for mapping using only stereo cameras for our sensors. Our controller successfully allowed Tesroo to navigate to the desired location. In terms of sensing, planning and controls, we were ultimately able to meet our design criteria! You can view our demos under Results + Demo.

We recognize the ambitiousness of our project from the get-go and as a result we faced many challenges along the way to end up at our final design. We've highlighted a few of our challenges below!

Challenges: Wire Sensing

Based on our market research, user testimonials, and our own experiences, we wanted to explore one of the largest pain points of current vacuum models: wires.

Currently, wires remain one of the largest complaints of most vacuum robot owners. Like the image on the left, vacuum robots tend to destroy many cables on sight due to the robot's inability to detect wires.

As a result, we explored ways to model wires in our simulation and in our proof-of-concept. However, this proved to be extremely difficult. Currently, Gazebo has the option of adding several different components to custom worlds such as tables, chairs, etc. However, these components are often stationary and do not include the dynamics of smaller objects. For example, if a vacuum robot were to run into a ball, the ball would likely move. Similarly, if a vacuum robot were to run into wires, the wires would get stuck in the brush or move. This functionality isn't readily available in Gazebo and as a result, a large part of our design sprint was dedicated to trying to combat this issue.

After much trial and error, we found a research paper from Ecole Centrale de Nantes, a French engineering university. This final masters thesis was dedicated to model the cables under tension in Gazebo. Although this was not directly related to our team's issue, we reached out to the authors of the paper to discuss their paper and potential ways to approach our problem. They were able to hop on a Zoom call with us and discuss ways to approach our problem. Although we didn't come to a decent conclusion, it was interesting to talk to real world roboticists!

There was also a lot of difficulty sensing the wires since they're quite difficult to model and observe in the environment, which is what led us to neural nets. However, training requires data. As that wasn't readily available for our situation, we had to create the dataset ourselves. This limited us to image detection for the time being, since standard segmentation algorithms aren't very good at picking up wires (meaning we couldn't create training and testing masks for image segmentation unless we did them by hand).

Implementation Improvements

  1. Efficiency

Instead of using an interpreted language like Python, we can write our algorithms in a compiled language like C++ for 200x-300x speed boosts. Also, instead of using the original frontier detection algorithm, we can use more efficient algorithms such as the Wavefront Detection algorithm

  1. Dynamic environments

TesRoo's first environment will be homes. To account for moving objects such as pets or humans, we can use algorithms such as Simultaneous Localization, Mapping and Moving Object Tracking.


  1. Relax assumption of robot being a point

In our current implementation, we treat TesRoo as a point within the occupancy grid and thus don't account for TesRoo's radius and height. This assumption may cause TesRoo to occassionally bump into objects. To fix this assumption, we can take into account TesRoo's radius relative to the physical size of an occupancy grid during planning.

  1. General scene segmentation

Currently, the only object we account for in our scenes are wires. We'd like to be able to segment other objects (and liquids) too. To this end we can use various scene segmentation techniques described here.

Other Improvements

Some other improvements that we discussed were that we'd like to

  • Build a mobile application for users to track the map built, select which areas to avoid. We have the ability currently to be able to connect an application due to the way we structured our code, but we didn't have enough time to physically build a mobile application for users to be able to use. An example of what that mobile app may look like is on the right.

  • Manufacture a base and order parts to build a physical TesRoo instead of just a proof of concept. Because of our budget and time limitations, we were not able to 3D print components to be able to build a physical TesRoo. In the future we'd like to physically build TesRoo to be able to create an MVP!

  • Disrupt the vacuum robot industry ...just kidding...