{"id":180,"date":"2016-10-21T13:48:54","date_gmt":"2016-10-21T13:48:54","guid":{"rendered":"http:\/\/mrsdprojects.ri.cmu.edu\/2016teamc\/?page_id=180"},"modified":"2017-05-13T03:51:25","modified_gmt":"2017-05-13T03:51:25","slug":"system-implementation","status":"publish","type":"page","link":"https:\/\/mrsdprojects.ri.cmu.edu\/2016teamc\/system-implementation\/","title":{"rendered":"System Implementation"},"content":{"rendered":"

Current Overall System Structure<\/strong> \u00a0 \"\"<\/p>\n

Current overall ROS structure for Mell-E<\/p>\n

Figure above shows the current structure of nodes and topics that are being used in various systems. After refactoring the code, now we only have one topic to which the Arduino is subscribed to and only one topic to which the Arduino publishes data. The rest of the heavy lifting is to be done by the PC node. The PC node would handle the state switches, generating motor speed values and navigation. The Arduino would just act as an executor where it runs the motor commands received from the PC node and pass the data from the GPS and magnetometer unit to the PC node. As part of the refactoring, we also included a watchdog that would kill the motor if there is a disconnect between ROS and Arduino (an issue that we faced a lot last semester). This made the Arduino code much cleaner and less reduced the load on the Arduino. Robot base current pictures: \"\"<\/p>\n

In the sections below, we will explain each of the subsystems in more depth. For a more in-depth explanation of how each subsystem interacts with each other, please refer to the poster<\/a>\u00a0and the final report<\/a> as it provides a much clearer view than what could be reproduced in WordPress layout scheme.<\/p>\n

Navigation Subsystem<\/a><\/p><\/blockquote>\n