From Wikipedia: “Sensor fusion is the combining of sensory data or data derived from sensory data from disparate sources such that the resulting information is in some sense better than would be possible when these sources were used individually.” Simply put, when you have several sensors that spit data at you, sensor fusion links the data in a meaningful way to produce information valuable to the task at hand. This year, like none before, SubjuGator will utilize the idea of sensor fusion.
Last year, SubjuGator operated around (and it really kills me to mention this to anyone) just one loop with just one thread. Multi-threading, in my opinion, buries most autonomous robots before they have a chance to explore their surroundings. Like a driver on a cellphone with a coffee in hand, threads don’t always work nicely together, and they may not appear to disrupt each other until your autonomous sub ramming the bottom of the swimming pool. Threads are also more difficult to debug in a not-quite-built autonomous robot– you can’t test the thruster threads with the camera threads until those items have been added. It’s a poor excuse, but one loop was easier to conceptualize, develop, debug, and test. Drawing information from sensors was a serialized task and efficient sensor fusion was near impossible.
With the dawn of Microsoft Robotics Studio, all this is changed. The best thing Microsoft brought to the table with Robotics Studio was a way to gain all the benefits of multithreading without all the hassle. In defining services, protocols for communication bewteen the services, and background processes to host the services, Robotics Studio makes multithreading inherent in a software system. Sensor fusion now occurs as a service that subscribes to two or more other services that distribute sensor data or represent some source of information. The multithreaded, event-driven nature of Robotics Studio eliminates the loop and offers a viable way to intepret and analyze data from multiple sensors.
