Gold Rush Plan

My plan for the Gold Rush!

• Do a 360 and find the farthest away wall.
• Drive toward it and hit it.
• Repeat steps 1 and 2 until one set of parallel walls are equally away from the robot.
• Execute the built-in DOCK method.

So if walls were equally away from the robot we would try to find the beacon as fast as possible.

RoboCamp Day 1 - Questions about the Survey Route Mission

Before we began on our code, we had several questions about some of the rules for the rover speed challenge.

During this challenge, you will be given bonus points if your robot autonomously returns to the start. Also, your points will be doubled if your robot doesn't hit the side walls.

• What part of your robot must cross the finish line for the time to stop? This is so our robot knows when to start turning around.
• If your robot is doing the "return bonus", does that count as part of its time? If our robot has to go twice the distance, it won't get a very good time. This will help us decide whether or not to do the return bonus.
• How far away from the back wall is the finish line? If we know how far away the finish is, we can know when the robot has crossed the line.

Knowing these minor rules will help us increase the efficiency of your robot, and give it a faster time.

Mentor Post: Turning a Two Wheeled Robot

Our iRobot Create is based on two drive wheels. All movement of this robot can be understood in terms of the relative and absolute speed of these wheels. This post attempts to layout an intermediate method for turning a robot that allows turns to be computed with the robot in motion.
 The geometry of a turn. We can define any turn as a combination of the angle of the turn and the radius of the turn. This is a step forward from last year’s pivots. A pivot being a turn with a zero turn radius.

The advantage of this turn is that we can maintain speed rather than stop to make the turn. This allows the robot to move more smoothly. 

 With a two wheeled robot we need to determine what wheel speed is necessary to make this turn. It is important to realize that the turn can be made at any speed simply by controlling the individual speeds of the wheels. In this post we will only consider constant speed turns, these turns would result in circles instead of spirals. By limiting the turns we simplify the math. The question becomes how do we compute those speeds?

If you look at the drawing above you will see that the left wheel has to travel a longer distance than the right wheel. In order to make this turn correctly the two wheels will need to travel these two distances at the same time. How can we compute the travel distance?

We can see from this drawing that the two wheels each travel an arc of a circle defined by different radii. If we let r be the radius of the turn and d is the distance from the center of the robot to the center of a wheel, a = r + d and b = r - d. Of course these values would be switched if we made a left turn. The actual distance is also a factor of the angle of the turn.

 We will need to compute the arc of a circle. If you need a refresher check out Cool Math. The arc of a circle is the angle * radius. However that result uses radians. If you are keeping your angle in degrees then you will need to convert it.

 Today’s task:

 Right a method that computes the wheel speeds for a turn for a given radius. The method should rely on a call to int[] Robot.getCurrentWheelSpeed() and return left and right wheel speed below Robot.MAX_LEFT_WHEEL_SPEED and Robot.MAX_RIGHT_WHEEL_SPEED. Make certain the routine efficiently handles positive and negative angles. 

 Ending the Turn

 How do we decide when our turn is complete? We can use a sensor that returns our orientation, we could use dead reckoning by computing a time based upon wheel speed or we could measure the actual distance travelled by each wheel. Ideally we would combine all these methods to reduce error.

Computing turn wheel speed is one of the fundamental building blocks for moving the robot in this year’s iARoC competition.

Mentor Post: User Interface

Last year Anthony did a great job of making a functional, if not pretty user interface. This year I am asking him to focus on producing a more informative interface and building it in a way that is understandable to the team and extensible.

The team would like to show a map on the phone display. To allow this to be build without requiring a functioning robot and full scale maze I am going to ask Anthony to port the maze simulator and build a UI for it in Android Studio.

I will encourage him to use MVC techniques to build the interface. This will allow him to apply the same interface to the robot code once it is ready. I am also asking him to at least review the material design techniques. I hope that if he follows some of the patterns he will find it easier to build the user interface and modify it as we move forward.

Maze Simulator Project
Getting Started with Material Design

Mentor Post:Back to Work

As we close out May and head into the competition month it's time to get back to work. The team was sidetracked by preparation for the AP exam. In addition there are more than a few blog posts that never really got completed and are sitting in draft stage. I will probably publish them today as-is but the content may be a bit out of date and not finished.

We still have work to do to get the physical robot ready. The lack of permanent placement of ultrasonic sensors and the phone are slowing us down a little. Today's lesson will have the goal of coming up with a project plan, defining the physical changes to the robot and starting work on the UI and some new robot functions.

With robot camp less than a month away it's time to really focus on the work at hand make progress on this year's entry.

The Wonderful World of Sensor Limitations

Let's be honest. Sensors are not perfect. I know, after chocolate, sensors are one of the most helpful things in a strategy, but in order to use them efficiently, you have to distinguish between the thing you want to sense and the things that are background noises. When the multiple difficulties stack up, the sensors can be rendered useless (no pun intended). So! What are the main sensor troubles, and how can we troubleshoot it?

SENSOR FLAWS:

File One: Analog to Dialog

The first of many different possible problems the numbers you are getting is that a sensor lacks the smoothness that an actual graph would have. See the left. While the beautiful, smooth, continuous, almost-fluid, even,  unvarying bell curve you see on the left may be what you want (and yes, it had to have that many adjectives), instead, a sensor will give you only segments of data. As the distance between two reads increase, the accuracy of your readings decrease. Which is bad.


File Two: Noise
Another annoying part of sensors is NOISE. If you don't know what I'm talking about, here's the short version: think about listening to music. Easy... until someone else nearby turns on their music. In other words, noise is the little things that are happening around the sensor that you aren't interested in. There are many algorithms that can fix this, but none are perfect. The key is knowing the accuracy of the sensor, lest you misread data as something fatally important when, in reality, it is noise.

File Three: Bias
Finally, the last of the sensor difficulties: bias. This is basically when a sensor has a reading that is constantly off by the same amount. Every. Single. Time. The solution is simple: find the bias at the beginning of the program and get rid of it every single time. Although this may seem like a trivial bug, when combined with the above two, can make reading sensors much more than meets the eye.

Mentor Post: What I Learned Last Week

What should students be doing in a Java programming class? What should they be doing to get ready for an autonomous robotics competition? If you said programming or writing code you would be correct. There is always the need for some small amount of lecture, but I found myself at the end of class on Friday realizing that I had spent too much time talking and the students spent too much time working on the board rather than writing and running code.

Preparation is the key to having a good classroom experience and that preparation falls into two categories, environment preparation and lesson preparation. Environment preparation is typically a one time investment with recurring dividends. It involves ensuring that the computers, applications and repositories are available and ready to go. Lesson preparation needs to be done for each lesson and adjusted in real time.

At the school the students are using Apple computers for writing their code. Unfortunately we occasionally run into problems logging into these machines. This can eat valuable class time waiting for the system to become available. In addition to the machines, they need to be configured with the correct version of software for Java development. In our case that is Eclipse with the Android Development Tools correctly configured for our target platform. In addition the students need to have access to the correct repositories of code so they can quickly get to work. I will need to make some time outside of scheduled class times to attempt to resolve these issues so that class time can be more productive

With four students in the mix it's hard for them all to be working on the same tasks. My future lesson plans will be developed so that the students are broken into two pairs. One pair will focus on hardware specific programming and the other will work on simulator based programming. Teams will be changed frequently and everyone will have the opportunity to work in both domains, hopefully moving previous projects from the simulator to the robot and vice versa. In order to accomplish this goal I will need to have more specific tasks outlined for them. I will be attempting to develop these tasks much like the recipes that are used in the curriculum and posting them with repository links as they get created.

Finally, the only real way to improve is to review performance. I will be doing a better job of coming up with a lesson plan and making myself accountable for sticking to the schedule. This will help me identify what elements are working and what elements need more attention.

Differences from 2014

Last year, we had this awful Class that had a billion methods and fields and was hard to use. This year, we will use separate Classes for all of the different rules. Some examples are:

• Right Hand Rule
• Left Hand Rule
• Center Rule
• Random Rule
• Wall Follow Rule

And so on.

What We Learned About Quaternions

         Quaternions. Quuuaaaaternions. What an interesting word. Quaternions. Quaternions. Quaternions. Okay, that's enough.

So, at this point, you are probably already getting ready to ask 3 things:

1. What are quaternions?

2. What does quaternions have to do with the iARoC competition?

3. When will I stop saying 'quaternions'?

To answer the first question, let's talk about vectors first. For those of you that don't know, a vector can be defined as an direction and a magnitude (see diagram). A vector can be 2D or 3D. If you set a body coordinate system (i.e. with the x and y (and z) axis), where the tail is the origin,  you can define a vector with a point (e.g. (3,4), or, for 3D, (3,4,1)). In this same way, a quaternion is pretty much a 4D vector. 

You: But wait, this isn't a sci-fi competition! Are you intentionally trying to confuse me?

Me: No! Wait! I'm not done yet! Bear with me...

So, it would seem pretty obvious that a quaternion can be, say, (6,3,1,4). And this has to do... with rotation! See, you can define an object's rotation with a 3D vector representing the direction of spin and another number representing the amount of spin. Sound's familiar? Yep, it's a quaternion. That 6, 3, and 1 tells us the direction... and that 4 tells us the spin! 

Now let's answer the second question: what does this have to do with the iARoC? I mean, yabayabayaba, interesting math stuff, but where does programming play a part in this? Well, right now, in order to code the robot, we first code on the computer, and then have the phone download from the computer. Then, we have the Roomba (the robot) to use the code on the phone! If we attach the phone to the robot, then we'll be able to use some of the phone's tools to our advantage, so what we want to utilize this year is the phone's gyroscope and accelerometer. These two nifty tools can do similar, but different things. The gyroscope senses what direction the phone is tilted in. This will give us back a quaternion, so it is essential to know what quaternions are. The accelerometer senses how the phone is, well, accelerating, giving us a 3D vector. What we'll need to do is get rid of gravity's affect on the phone, or else we'll get flawed responses. 

As for the third question, well, let's just say it's... not going to happen. Quaternions. Quaternions. Quaternions.Quaternions. Quaternions. Quaternions...

Strategy and Controller Symbiosis

We have split the code our robot will execute into two parts. In the strategy, we have all the methods our robot will use to solve the maze, do the drag race, etc. It will contain rules that will decide what the robot does. They will be prioritized so the robot can do the important ones, for example, keeping from crashing into the wall, before doing others. 

The robot controller is the other part. This is where we physically control the robot. We read the infrared sensors and move. Then the controller class, sends the information to the strategy class. The strategy class can decide what rule to do, based on the information.

As you can see, both sections rely on each other. Without the strategy, the robot would have information but no way to construct it and no instructions. Without the controller, the robot would not be able to go anywhere. For our robot to win, both must work and interact well. 

Collaboration Flaws

We used GitHub and are still using GitHub to collaborate. Unfortunately, it is not always the easiest thing to collaborate on different computers. The problem lies within merging. In case you don't know, GitHub, and most other similar applications, allow for multiple people to work on a single project separately, and then combine their new versions using the power of merging. This way, a person can see the differences between two different versions and decide which change to add.

One thing that was a bit (well, very) problematic to us last year was that we'd use different styles of code. One person may do this:

if (condition) {

    //code

}

While another may do this:

if (condition) 

{

    //code

}

It is a pain to go through every single difference and say, oh, let's do it with/without the enter. So this year, we are planning to have a unanimous formatting preference. We are using Eclipse as our IDE for Java, so we are using a slightly changed version of the Eclipse [Built-In] formatting preference.

What We Learned About Quaternions

What are quaternions? Think of anywhere in existence as X, Y, and Z. Now rotate it any way you want to. W is that rotation.

body coordinate system

vector

rotation

gyroscope

accelerometer

Welcome to our blog!

My first post of our blog!

So, for your information...

We are a team of young programmers preparing for the upcoming 2015 iARoC competition. For those of you who don't know about this exciting coding/robotics event,  the iARoC, or International Autonomous Robot Competition, is an event in which many young (and not-so-young) programmers work in small teams (usually three to five people) to code a robot that'll complete specific tasks. The winning team gets some MONEY (but, alas, no chocolate) and glory. The robots most teams use are hacked Roombas (such as us), but I've seen Legos and even hand built robots. What we do is set up our robot at the beginning of a task, inject insert a program to the robot, and let it run by itself. There are 3 tasks at this competition: recover data, a race in which we see which robot go the quickest while staying within the boundaries, survey route, which is basically a maze, and claim mineral resources, which is a mad dash of all the robots to get to the infrared beacons first. I don't pretend to remember these names (we call them by.... simpler names), as I have the website in another tab. Get more info here: http://iaroc.org/!

This is our 3rd time competing (2nd for Anthony). On each of these 3 times, we used a Roomba, and we used Java to code and control the robot. Our first year was me (Ruoya), Russ, and Greg (another programmer, but he left us later). On our second year, we got Anthony, and we got 3rd place in the drag race (aka recover data). In the drag race, we had used the ultrasonic sensor to turn the robot when it strayed from the center of the lane. Also, we had used a strategy for the maze which we had dubbed the cookie crumb strategy, but unfortunately the ultrasonic sensors had collided with the wall, which pretty much plunged our robot to our doom. Let's hope this year will turn out better!

Ideas for Robot Design

We need a design for a robot, and for that we need a name. The name of our robot helps other people identify it. We have some names:

1. Glitchless
2. public Robot r;
3. Snowball

We have a design for Snowball. It will be a dome on top of the iCreate, with little holes for the sensors. The other robots don't give any design inferences, so we still have yet to decide. For our first week, we all came up with names and voted/vetoed them.

We had also made a list of concepts and themes, and we matched our concepts to our themes, and our themes to our robot names. 

Mentor Post: First Class

Friday was our season launch for team Nerd Herd and as mentor I was caught unprepared or as the Scots say “The best laid schemes o' Mice an' Men, Gang aft agley,". I had been preparing for the season by pulling out the robot and ensuring that all the parts worked. I also had to change the sample project to run with the phone I had available as the phone I used last year was returned to my company's inventory. There were some changes that I made that I will put back into github as soon as possible.

Due to unforeseen circumstances I worked from home on Friday and because of holiday traffic did not attempt to go by the office before class. Therefore I did not have either our engineering journal nor our robot at class.

However, not everything went wrong. We did get to discuss the branding concepts, talk about physical design and start on our blog and presentation. I think that we got into a position to build upon but I left the class feeling a lot like last year, namely frustrated about the lack of time and feeling if I had prepared better we might have made better progress.

I am intentionally keeping this post short but leaving with a question, I want the team to chose a robot name and build up a look and branding strategy around it. Do you have suggestions for them in choosing a product name? What techniques would you recommend for them to come up with ideas and then choose one that they could build upon?

Thanks in advance for your ideas.

Mentor Post: 2014 Lessons Learned

Last year was a struggle for me as a mentor in a lot of ways. I did not know the team, I did not know the robotics platform and frankly I was used to control of hardware that did what it was supposed to do when it was sent a command.

However, I thought the team did very well last year. As the youngest team in the competition they still placed very well. This year, with the team coming back for a third time and with one year under my belt, I expect us to do even better.

One of the key things we are doing early this year is taking stock of what we learned at last year's competition and working to improve in those areas. If you are an iARoC mentor or team you may benefit from what we learned as well.

• Physical structure of the robot 
• One of the things that became apparent late in our development cycle was that the placement of our ultrasonic sensors on the outside base of the robot was ill conceived. It made the robot wider and the jutting sensors would catch on the wall and turn the robot. We plan to review the placement of the sensors and mount them where they will still work but will not interfere in the free movement of the robot.
• Our robot's functionality was also limited because we never permanently mounted the phone that controls the robot. This prevented us from being able to use the phone's gyroscope and accelerometer features. We are looking at 3D printing as a possible way to permanently mount the phone as well as a way to improve the overall look of the robot.
• Robot concept
• I was struck by the creativity of the teams in naming and designing their robot's look and image. Our team didn't even have a consistent robot name when the competition started. This year I have emphasized the need to come up with a "brand" and "product" strategy. I hope this helps the team focus and gives them some flair in their presentation at the competition. I am encouraging this by having them consider the robot's physical design and also design of other team items like T-Shirts.
• Coding Practices
• Last year, just ahead of the competition, one of the team members changed his coding preferences in his IDE and attempted to commit his code. The resulting merge, under pressure was a nightmare. This year I will have the team agree on a coding standard and stick with it. We will also be working on our git skills and doing more code reviews in class.
• Beginning programmers tend to write all their code in very large classes with many very large methods. A lot of our class focus over the past year has been on object oriented principles like encapsulation and inheritance. I am expecting the team to bring these skills into the competition this year. I am hopeful that this will allow them to be more productive especially when things get busy during robot week.
• Movement
• As beginning programmers last year the team through about robot control in a very linear fashion. I am hoping to introduce more parallelism into the process this year. One example of this is through the basic robot movement. Last year's code base was broken into forward motion and turning. Some parallelism was introduced in the data recovery mission. Last year one robot completed the survey route mission and one came very close. Both teams used a move one space and reorient strategy. I am hopeful that we will see several teams complete the mission this year, as such I think it will be important for time that the team achieve a continuous motion through the survey. In addition this will be important because it will reduce the errors systemic in rotating while stopped using the Create platform. We will be attempting to develop a spline navigation technique to optimize continuous motion through the route. With the addition of the sensors from the phone I believe that continuous accurate motion is achievable by the team.
• Claim Mineral Resources Strategy
• This mission received very little attention from the team last year. Coming up with a strategy for this mission is very difficult. If time permits I hope to introduce evolutionary programming to the team to solve this problem. This will allow the team to combine simple parameterized strategies and test them using simulation to determine which have the highest likelihood of a win.

The team may decide to focus on other areas, as the mentor my job is to present these ideas and facilitate them. I will continue to stress good coding practices, teamwork and communication but leave the decisions about the design and development of the robot.

Mentor Post: Origin of the Blog

Having the Nerd Herd use a blog was a new idea for me this year. Last year when I began as mentor for the Nerd Herd I brought with me a concept from work, an engineering journal. The concept behind an engineering journal is to capture all of the work, ideas and issues. These journals are saved and can be used as the basis for establishing claims for intellectual property.

The Nerd Herd did okay with their engineering journal last year, but I thought we could do better. What I really wanted to impart was an ability for the team to keep track of their progress and be able to look back at the work when preparing their presentation.

The use of a blog allows simultaneous posts from each team member and allows the team to add content outside of class. I will be adding posts to the team's blog that hopefully will be of use to other mentors. The other aspect of the blog will be to help the Nerd Herd with their communication skills. This will help not only with the competition but is a key work skill that can be imparted through this competition. Fortunately for me I have a parent who has experience in this domain and will be assisting the team with their posts.

I am looking forward to a great season with the team and I hope that our readers find the blog useful.

2015 iARoC Kickoff

This is the third year The Nerd Herd will be competing in the International Autonomous Robot Competition. We have officially begun work on our robot and soon we hope to post a video of our progress. Stay tuned for more updates and information.