1. Research
2. Resources
3. Math
4. Execution
5. Troll

Do your research: Always do your research first. If the field you are working in is unchanging and you are already an expert, you can skip this step. However, if you are an expert, you’ve already done your research and ultimately step one still applies. Doing research first can save so much time, headache, and can give good solid inspiration for your work.

Know your resources: Understand the system you are working with and what is available. For example, DTCC Swarmathon this year spent a long time worrying about stuff that was already done and available for them. If the leadership had spent more time examining what was provided to them and figuring out how it worked, they would have spent less time trying to write code that they didn’t need and inevitably never used.

Do the Math: There’s a part in the Martin and I’m not sure if it is from just the trailer, if it was in the movie or also in the book, but I know for sure its in the trailer. Anyway, in this part, it’s Mark Watney says, “let’s do the math.” This is a lesson that is so incredibly important. Not only because if there is math to be done, you should do it, but it is also a broader lesson. If there is a problem, or something, make sure you know exactly what the problem is before you go diving in with solutions. If you don’t, you can end up wasting a lot of time.

Do the thing(Execution): After you have done the first three steps to the point where you can defend every aspect of what you are trying to do… then and only then should you execute. Obviously there are fringe cases where the first three steps may need to be skipped, but if you only want to skip them… don’t. Whatever you do will end up being far worse than if you’ve seriously given the first three steps your all.

Troll: Small harmless pranks and teases are a good way for teams to bond and keep morale high…

My current implementation of the State Machine uses a Waypoint System to move from point to point within an arena. The problem is, due to fuzzy localization, the waypoints are usually shifting about a meter around their “actual” location. The shifting does not occur in the simulator, which I know, but I also didn’t realize it was going to be such an issue for precision driving in the real world. If I want the Rover to drive one meter exactly forward, it cannot. My current technique for managing this is just using some trig to generate a waypoint one meter straight in front of the Rover. However, it cannot drive straight, because to its perspective, the waypoint is always drifting. For example, if the waypoint is drifting to the left, it will cause the Rover to curve its path to the left to try and meet it. This is a major problem.

The reason this is a major problem is that for things like picking up a cube, or dropping off a cube, in the real world, the Rover needs to be able to take commands allowing it to drive as straight as possible! Since the cubes and the actual Rover aren’t drifting, if I set a point in front of the cube the Rover is trying to pick up, that waypoint drifts away and the Rover doesn’t end up in front of the cube.

So, does it seem like my current implementation won’t work at all. Luckily, it will work great for general motion. For example, he’s a picture of the Rover driving around sweeping out an expanding square spiral area.

While this is a virtual map of where the Rover thinks it went, the combination of Navsat, Odometry, and IMU has it echoing this pretty close in the real world. All is not lost! However, I am in the process of implementing a better way to deal with specific driving in the short term.

What a day! What a view! I slept well that night.

Ever wonder what a robot sees? This is what ours can see with its little camera. After mapping that out cone out, we also spent a bit of time outdoors (the weather has been perfect)!

We had to get a feel for what the base code could do without any modifications. Only two members (Lex and myself) on the team had any idea what that was like, as they had participated in NASA Swarmathon 2017. Also, we may have had to use “human walls.” It’s not the most ideal testing area…

All in all, needless to say, monotony broken! As I write this, we have moved past the research stage (though, does one ever move past the research phase? I mean… truly?) and are doing a lot more of these types of experiments now and writing a lot more code!

With the dominoes falling into place, my successful placement with a mentor at an institution not my own and my lease coming to an end, I had to find a new place to live for just two months during the summer. Two month leases are not really a thing. Thankfully, my mentor Dr. Isaacs was instrumental in helping me find a place. He lives in a townhouse complex that is adjacent to the school where we would be doing our research. He posted on NextDoor for his neighborhood and within a few days we had multiple hits. I was able to make contact with him and negotiate a reasonable price. I believe, in this sense, I got very lucky. I could see this process being much longer and frustrating.

The biggest downside of this being distributed is not having access to a car. While, of course my host family (this is what I call the people I live with) obviously has a car, they have been gone for the first four weeks and did not feel like letting me drive their car. Unfortunately for me, it may be a suuuuuuuper convenient walk to campus, it is many more miles than I want to walk to the closest grocery store. For the past three weeks, I’ve been having to get Lyfts to go get food. This is an extra $20 added to my grocery bill every time. However, I imagine that when my hosts return from their vacation, I will be able to ride with them when they go grocery shopping.

About the team, I haven’t really talked much about the people I am working with. I was surprised to find them to all be around the same age as me (given that I am a 30 year old undergrad… it is great to see I’m not the only one!) and three of the four of them are also undergraduates. The three other undergraduates are all participants in a local REU called Summer SURFer program that is offered through their school. The fourth is a grad student who is simply here for the experience, and surprisingly enough, he’s the youngest among us. One of my fellow undergrads was a participant in the NASA Swarmathon this year, and as such is familiar with the platform. We have been slowly educating the other three on its operation when we need a break from all the reading we are doing for research.

Since there are five of us in total, we have broken down our pject into five specific tasks. Each fellow will develop an algorithm for their specific task covers a field in swarm robotics and our job will be tailoring them to the NASA Swarmathon competition and platform. The tasks are find home, pick up, drop off, obstacle avoidance, and the state machine. We are not worried about searching, and if we have time we will play with it a bit. However, as a collective, we believe that we must have a solid foundation before focusing on search and our foundation is the five things we listed above. Of the five tasks mine is the State Machine.

While our research in the first week was focused on going up and down the chain of the Beyond Pheromones article, the second week has all been about State Machines. And let me just say, I’ve learned a lot. I already have plans for the information I’ve learned so far, and now plan to augment the current program that operates the payload on my HASP project to use a State Machine. The goal is to bring a higher level of efficiency to each iteration of the programs operation, which is something I have been internally struggling with lately. The program works, but it is time to make it better. This is the internal struggle of the artful programmer, “make it work, then make it good. Refactor, refactor, refactor.”

Also, I think mini-projectors are so cool! The projectors are so affordable, portable, and of pretty good quality! Just like the Raspberry PI! Making these two components a match made in technological heaven!

It was my first weekend here in California and I decided to go on a hike! It was amazing exercise, it was amazingly dry (I brought water), the sights were so different than I am used to (which made for some amazing views), but it wasn’t all good… I got a little sunburned. Anyway, he’s a quick google stylized video of the photos I took:  https://goo.gl/photos/DhNBByLUeGxshPHB9

After day 3, I felt very lucky to have had an English teacher like Sonny Haynes. Thanks to him, I did not feel like I was unprepared to do what needed to be done. His teaching style and his presence always pushed me to be better at both research and writing. The fact that I had done a multitude of annotated bibliographies before had greatly prepared me for the first part of the internship. And while it is probably a general require of the Durham Tech English department to teach and do what he did, I felt particularly prepared because of Mr. Haynes.

And while I may not be entirely fond of research, I do feel like I am more prepared than EVER to tackle the challenges of Swarm Robotics thanks for the research that my mentor Dr. Jason Isaacs is having us do. So, like the many snails in the photo above, I slowly slug towards my goal of actually getting to write some code. Some well researched, and thoroughly thought out, code.