The First Two Weeks... This post is a little bit behind, but it has been a busy and productive first two weeks here at University of New Mexico!
The first day after arriving, we were already getting to business with our tasks. There was some discussion and we unanimously decided that the codebase was in serious need of a refactor and an update to a more modern version of C++, C++11- so we jumped right in, not wanting to waste time. The other DREU participant who was assigned to the same task had never touched the codebase before, so we spent some time bringing him up to speed and doing a cursory check over the main module ourselves. I had participated in the Swarmathon competition for the previous two years and was fairly familiar with the codebase at this point, so I had started brainstorming ideas for the refactor. We decided that the main module took on far too much responsibility and did not handle the smallest amount of functionality that it should have at that point. What we decided on initially was to split that functionality into several main Controller classes- SearchController, PickUpController, DropOffController, and the new ObstacleController. Each of these controllers would then be fed input from various signals received from the ROS ecosystem (camera and ultrasound information, mostly) and would determine if they needed to send an interrupt signal to the main loop running in the primary module. If they did, then they would be given some amount of control over the rover's driving, until they no longer needed to interrupt the main driving behavior. By the end of the first week, we had implemented this system and gotten it mostly working- I took the DropOffController refactor and helped design the ObstacleController code. Partway through this initial stage of refactoring, I had noticed a similarity with this system and how an operating system's kernel will register interrupt handlers for various hardware and software interrupts. The main difference was that the modules controlling the sent interrupts also controlled the handling of them. Noticing this similarity and pointing out that hard-coding the order in which interrupts were handled was not particularly beneficial, I proposed a generic system in which all Controllers implement a shared API, represented with the Controller abstract base class. You could then register controllers into a priority queue, where the priorities could be modified in data instead of in code. This way, instead of switching the code path taken using conditional statements, a simple re-assignment of priorities would allow for different behaviors at different stages of the robot's control. This became the task of the second week. We verified that our changes from the first week still created the same behavior as in the base code, and then created a new Controller type, the LogicController. LogicController itself implemented the Controller interface (potentially allowing for recursive strategies of control), and is responsible for the management of other controllers, passing them information and determining what is to be done with their output. This was the most complex portion of the refactor and is still not complete after the second week- it involves taking almost the entirety of the 1000+ line mobility.cpp file's functionality and passing it on to the various Controllers, and making sure that all the states and transitions still behave as they did before. At our Thursday tech meeting, one last change was proposed in which we eliminated all ROS dependencies within the Controller framework and moved them to another module, and also moved the remainder of mobility.cpp's functionality (at this point, only the functionality relating to actually driving the rover from waypoint to waypoint or sending out precision driving commands) into a new Controller, DriveController. These changes make the entire module independent of the environment it is implemented in, and remove the need to understand specifics about it. This way we can focus entirely on the algorithms we are meant to implement instead of quirks in the simulation or operating system. While we did not make much progress in the implementation of the DDSA directly, these changes will make that implementation much easier and much quicker, and will lead to more maintainable code for the future.
0 Comments
Leave a Reply. |
AuthorKelsey Geiger: a maker, learner, teacher, and doer. Proud to be out and proud of her work. Archives
August 2017
Categories |