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.