For the week of July 31st, the main tasks were to finish the fix of the DDSA implementation, gather statistics on how it ran so that it could be compared to the CPFA. However, the DDSA implementation was not running properly after a merge halfway through the week with another DREU intern's addition of path-planning behavior to avoid the center between points (my previous addition only kept the points themselves outside the center). The bug introduced by this merge caused the spiral to be offset by about 1.3 meters to the West and South, and also start larger than intended. This offset severely hampered the effectiveness of the DDSA because it was avoiding several decently-sized clusters that it would normally collect from.
The cause of this behavior wasn't found before Friday, when we were due to give a presentation on our findings so far, with some preliminary statistics collected that day. The DDSA performed extremely poorly in comparison to the CPFA given the state it was in- around 12-13 blocks collected per 30-minute run compared to 50-60 collected by the CPFA in the same amount of time, with the same exact distribution of cubes. The base code, which implements a random walk (Brownian motion-like search) performed slightly worse than CPFA, at 45-55 blocks in a 30 minute round. After the presentation, we took the code for the DDSA alone (not including the center-avoidance code that caused the bug when it was merged in) out of the branch and merged it in with the base code- the problem was fixed and the algorithm performed normally.
0 Comments
For the week of July 24th, I continued to work on the DDSA implementation as much as it needed to be fixed and revised. Additionally, some improvements to the base code were made and incrementally merged in- issues due to the merges were fixed each time they were identified, before moving on with the implementation.
The math described in the paper was sufficient for the rovers if the dimensions of the rover were accounted for in terms of 'g' (the gap between lanes in the spiral)- there were no terms to add or other factors to multiply in besides the modified gap, based on the length of the diagonal of the rover plus a small gap defining the closer blind spot of the rover (each of those terms had to be measured from the simulation, because our physical rovers were not fully assembled at the time). However, we did have to adjust the spiral pattern as a whole to account for our non-point center dropoff zone. A small term is added to the first circuit and the "north" and "east" portion of the second circuit in order to offset the overall spiral from the center, since we do not want rovers driving through it. From July 15th to July 17th, the DREU interns were in Boston to run the Hackathon and take care of packing and shipping the supplies back to Albuquerque, before returning ourselves.
The RSS Hackathon had some technical issues (someone had done a `git push --force` incorrectly and overwrote our progress) but nevertheless was a useful experience for everyone involved. We stayed up overnight helping all the teams- some of them had significantly more experience than others, others didn't know C++. All-around, it was a good learning experience, both for the competitors to learn more about robotics software, and for the mentors as teachers and organizers. When we returned from the Hackathon, we had an extended weekend due to the strenuousness of the event. We got back to work on the 19th, and I started working on the code refactor to fix a few remaining bugs. After most were taken care of and Jarett (one of the long-term, non-DREU interns) had claimed the last few, I began work on the implementation of the Distributed Deterministic Spiral Algorithm. I worked out how the rovers would determine their index and the overall size of the swarm and adapted the math to account for the dimensions and sensing capabilities of the rovers, and another DREU intern worked on the generation of the spiral pattern itself. Because of the short week due to the July 4th holiday, I'll merge the two weeks together for this update.
From July 5th to July 7th, my main work was to work on the camera plug-in for the Gazebo simulator, which was done by working with a fellow DREU intern. He mainly wrote the code, while I mainly did the math required for figuring out the coordinate system, constraints of the camera joints, and force to use for turning the camera joints, as well as research into the plugin system used in Gazebo. I also wrote the appropriate sections in the model.sdf file used to represent the rover in the simulation. Final prep was also done for the RSS Hackathon. I started printing "stand-offs" for the rovers, packing up supplies to ship out, and preparing for the competition itself the next week I learned a bit how Gazebo models coordinate systems through this minor project; joints are relative to the first parent "link" (a physical point on the model), while links are based on absolute coordinates relative to the base of the model. Revolute joints are the most common type, which are joints that can be rotated around an axis or set of axes located at a certain point. They can be constrained to particular axes, and those axes can have particular constraints on the angles possible for the joint to turn to. From July 10th to July 14th, I mostly prepared code and tested it for the competition. It was more or less final by Wednesday- Thursday was left to test it and get packed to leave Friday morning. We flew out to Boston from Albuquerque on Friday morning at about 11AM MST and arrived in Boston sometime around 9:30PM EST, got situated in the on-campus building we were staying at, and prepared for the Hackathon from Saturday to Sunday. |
AuthorKelsey Geiger: a maker, learner, teacher, and doer. Proud to be out and proud of her work. Archives
August 2017
Categories |