Episode One : Pilot

During my first week, I was introduced to the various members of the computer science department and got acclimated to my workplace and was informed of the projects that I would be assigned to help take on. I would then get myself familiar with the Swarmathon code and its various functions and capabilities. At the same time, with the guidance of Jarret Jones and Kelsey Geiger, I assisted with refactoring the Swarmathon code. Taking part in the refactoring allowed me to quickly have a deeper understanding of how the code was working .The refactoring was meant to cleanup bad code and to allow expandability for the students who would be working on the code during the Hackathon.  My contribution was to the refactoring project was to re-factor the Search Controller and the Drop Off Controller, with a lot of help from Jarret and Kelesy.

Episode two : Getting My Feet wet

The majority of our Monday consisted of our group working on the Swarmathon re-factored code and fixed any bugs that would present themselves as we would compile the code. On the same day, me and the rest of the DREU students joined our first technical meeting. The meeting's purpose was to recap the task of the prior weeks and discuss the upcoming task for the next week .  Last week, I was tasked to re-read the DDSA paper and to review the DDSA - ROS Master branch in Git hub. Some of my other tasks included : providing the robots camera the functionality to rotate from left to  right, to implement an algorithm that enables the robots to traverse in a square around the center point, and to bounce ideas off of Jarret Jones for the upcoming week's practice of the Hackathon challenge. Throughout the week I continued to build on my understanding of the code, and accomplished the majority of the task without week. During the halfway point of the week we decided on another majoring refactoring project. This refactoring would see us totally redefine the mobility class, and break up its functionality even more. Lastly, we individually had to determine our own strategy on how we would attack next weeks Hackathon challenge.

Episode three: Hacking away at the hackathon

During this week we tested the Hackathon that the students in Boston would be faced with. The challenge consisted of a set of rovers, aka Swarmies, a center location, where blocks will be dropped off, obstacles for the rovers to avoid, and the blocks to be picked up. The problem domain was that there was four cameras over head that was area of the locations of all tags. So the in a sense, Every robot had the access to the locations of the blocks, the center, and the other rovers. Though the actual Hackathon was meant to take a total of eighteen hours, but our goal was to see how much we could accomplish within a fulls day work. Other than the debugging of the camera, which took a large amount of our time, the biggest issue that occurred had to do with the Localization of the rovers. Though the cameras were able to pickup and return the locations of each agent with an April tag, the camera's lag caused locations to be posted with delay. We were planning to only work on the Hackathon for a day, but we would end up spending up to the entire week working on it. Other than getting familiar with ROS ( Robot Operating System), I was tasked to work with another DREU student, and work on block allocation among rovers. We were able to find a solution, but there was not enough time to actually implement the solution because of other complications and limitations.

Episode four: Preparing for the showdown before the final showdown.

During the fourth week, there was a lot of things that were needed to be accomplished. We had two demonstrations that we had to prepare for, one for a representatives from NASA and the other for a member of the University of New Mexico's Biology department. From there onward, we focused on finishing our groups solution from the previous weeks attempt at the Hackathon. We focused on localization, how the robots would move with the guidance of the cameras, and target allocation, which was how blocks would be assigned to robots to go pickup. We needed to accomplish this task by the end of the week because we were supposed to show another demonstration to a member of the swarmathon organization team. The demo did not go as was planned, but we were able to figure out the causes of  issues. We were hopping to make those changes, the following week, and maybe test it our selves. Aside from the hackathon, I was working on adding the PID function with the Camera joint. This would allow for a later implementation that would see the robot autonomous rotating its camera as it moves.   

Episode five: four day weekend!!!!

This week would be shorten due to the Fourth of July weekend. I was still working on the oscillating camera on the Swarmie rovers. I had just implemented the PID controller in the previous week, and i was trying to fine tune it because the PID controller that I was using was previously meant for the Grippers. With no prior experience using PID controllers, I spent a good time trying to fix the errors that were being associated with the PID controllers. The goal for this week was to have the PID controller working, so that the camera would rotate on the correct axes and would perform correctly in the Gazebo simulator. We also began packing all the supplies and equipment that would be needed for the Hackathon that was being held during the later part of the Robotics: Science and Systems Conference

Episode six: Albuquerque, New Mexico -> Boston, Massachusetts

Since I was able to get the physics of the camera to work in Gazebo, it was time to hard code the oscillation aspect of the code. Since Mobility.cpp contained the state machine and the general logic of the code. My intended plan was to have the Swarmie's camera pan in the shape of a square, meaning it would transition from corner to corner and repeat over and over again. To do so, I created a miniature state machine within the original state machine that controlled the angles of both the yaw and the pitch of the camera. In order for it not to transition at an unnecessary fast speed, I created a timer that would only allow the camera to turn after a few seconds have gone by. This did not come easy because of the fact that I had to play around with SDF file and change the limits of both the pitch and the yaw. When that was completed,  I was tasked to begin implementing the DDSA on the new re factored code. Previously in the summer, in order to get familiar with the code, I was tasked with having an agent in the simulation traverse a spiral. I made a few changes to my original code so that would be working in the new code. On Friday, we flew to Boston and headed to Cambridge to attend the hackathon. I was a mentor that would advise the teams on how to accomplish the goal of the hackathon. It was a great experience because i had never had the opportunity to actually teach things that I am learning to others. It was a great time, all the participants enjoyed themselves, and I had the opportunity to see Harvard's amazing campus.  

episode seven: two day work week...

On Monday we were heading back from Boston. Our Flight left in the mid evening, and we arrived back in Albuquerque at around midnight. We were given the next two days off to recover from running the all night hackathon, and for working the weekends. We started back up work on Thursday, and I continued to work on the DDSA refactored implementation. I was figuring out a way that would allow for the agents to travel in an outward spiral, but when it detects an Apriltag cube it would retrieve it and make its way to the collection plate and then return back to its last position in the spiral route. The new refactored code was completely different from the previous code, so it took some time to figure out how I was going to implement my idea. So after some time of getting familiar with the code, I was able to input my code to make it work. I simply created a boolean variable that would keep track of whether or not a cube has been seen. If the previous is true, then the swarmie would set its current location as a checkpoint. The checkpoint would then be appended to the end of the way-points vector so that when the block has been dropped off, its next point would be about a meter behind the original checkpoint and it would continue the steps until it does not see another cube to pickup. Unfortunately, the Drop off functionality was not working so I was not able to test whether my implementation worked , before the weekend came .  

episode eight: hitting the home stretch

Over the weekend,  our undergraduate mentor, fixed the Dropoff controller issues, so i was able to test the spiral search implementation. My goal was to have the Swarmies, in simulation, begin in a spiral search path around the collection plate. If a Swarmie came across an April tag cube, it would pick it up and set a checkpoint  that was one meter behind the position were the it successfully picked up the cube. Once the cube has been dropped off by the robot, it would make it's way back to the checkpoint. If on its way to the checkpoint, it spots a an April tag cube. It would  pick it up, but it would not set a checkpoint. So after dropping the cube off, it would continue to make its way to the original checkpoint. Checkpoints can only be removed only if the Swarmie reaches it or relatively close to it. Once I was able to get that concept to work in simulation, I collaborated with my another DREU student. They were working on the communication that would occur between the Swarmies and the math behind the spacing and the size of the each Swarmie's spiral search.

Episode nine: Last but not least ...

This week I was focused on fixing all the bugs in the DDSA implementation, such as implementing an Obstacle avoidance method and ensuring that the spiral generated will incorporate x number of rovers. The method that I tried to implement would be a path planning algorithm that had every single waypoint checked by the Obstacle Controller. There, the waypoint will be checked to see if it exist in or near a known obstacle. The only current obstacle in this implementation would be the center collection point, so we checked if the path either was in the center place or the path to the waypoint crossed through the center place. Since we had about a day to get the concept working in the code, it did not pan out as well as we liked. So, we instead choose a simpler method, in which every time that a rover encountered an obstacle it would just turn left and drive forward. To allow for an interlocking spiral to occur among x number of rovers , we need to offset the starting location of each rover. This would allow for each rover need not to converge to the center to start their spirals, but to just got to the initial location at the beginning.  

Episode 10: All good things come to an end

The last week of the DREU program was spent running a bunch of simulations to compare the DDSA versus the CPFA. We also began writing our research paper. The entire program was an awesome experience, I learned more about Robotics and I got a taste of both the theoretical and applied aspects of the field. I really want to thank Dr. Melaine Mosess, Dr. G. Matthew Fricke, Jarret Jones and Antonio Griego for their support and guidance.