From the wizard in Window>Configure Joysticks, you can choose a controller and assign the value of one of these variables, say joystick.joy1_x1, and set it to one of the values for another variable. joystick.joy1_x1 can be assigned to the value of the right y-axis and joystick.joy1_y2 can be assigned to the value of the left x-axis. At first glance, this feature seems rather unhelpful, but if you find that it’s easier to think of the right joystick being joy1, then you can switch the values. It’s also helpful if you are using controllers that have joysticks with 3 axes of motion, you can make one of the existing variables be the left z-axis.

Although this could be useful, it will not be for FTC teams, because we may not use it due to the way the field control software works, but FRC teams may use it, making the world of 3-dimensional joysticks more easily accessible.

The game manual (part 1) of the 2013–2014 season was released on 1 July 2013 here. It details what the non-game-specific rules for the coming season are going to be (eg. what size sizing cube your robot must fit in).

We assume you know all the rules from last year, so we’ve compiled the differences from last year to this year.

The tournaments will, with the exception for a couple of things will be the same. There will be new super-regional tournaments that teams must qualify for in order to qualify for worlds. You qualify for super-regionals, and from there qualify for worlds. There also is going to be a new Control Award, awarded for outstanding use of sensors and software.

The engineering notebook has had a suggestion of a summary page at the start; a page talking about how you inspire, design, or control (connect, motivate, think, innovate, promote, compass) in a one-page statement.

In the past, the power switch on the robot had to be easy-to-see and accessible. Now this year, it must be labeled with a sticker, seen below. The game manual does not specify as to whether you make customize the sticker, but we have asked and are awaiting response.

The sticker you have to put on your robot near the power switch

If your team invested in the new Lego Mindstorms EV3, you will not be allowed to use it for your robot.

In the section about what COTS (commercial off-the-shelf) parts allow, a whole host have been added, and we list them here:

This year, unlike previous years, you can weld your robot together. Brazing and soldering are also allowed.

Microprocessors, like Arduinos, will be allowed again this year, and will be allowed a little more liberally. You may have one doing function on your robot if it is powered by the Tetrix SuperPro prototype board or the NXT prototype board. They still will be allowed if they are only powering decorative LEDs.

This year, in addition to the servos we’ve been allowed, there also will be quarter-scale servos, but there are a lot of rules surrounding them. On one servo controller, you may have only two of them, and if you have two on one controller, you may only have one standard-size servo on that controller. If only one mini servo is on the controller, you can have up to four standard servos.

For wires that need to disconnect and reconnect frequently on your bot, you may use Anderson PowerPole or other similar crimp or quick connect style connectors. You also may use power splitters in you circuits.

If you have decorative LEDs, they can be powered by an external battery, but if the LEDs are used as visual cues for drivers, then they must be powered by a prototype board.

The connectors on the TETRIX and MATRIX battery packs may be replaced or augmented with any compatible connector described in <R08.q> (about two thirds of the way down).

This year, having a camera on your robot for recording matches has been specifically allowed, provided the camera is for post-match entertainment and does not have wireless capabilities.

3D printed parts are allowed this year, but they must be designed by the team or a team member.

The new Control Award was mentioned above. This is what FIRST™ wrote about the control award:

Control Components must enhance the functionality of the robot on the field

Control Components must work reliably

Teams are encouraged to demonstrate control components to the Judges

Advanced software techniques and algorithms are encouraged

Prototyped sensors and custom hardware are encouraged

Note the part where it said, “Engineering Notebook with an Engineering Section.” You will need to have an engineering section in your notebook. This section is also required for the PTC Design Award and the Rockwell Collins Innovate Award.

And on to my personal favorite (non-Inspire) award, the Promote Award. This year, the prompt is, “Leadership is.”

For most FTC teams, the Judges’ Award has not changed, but for those of us in Los Angeles, you will recall that upon winning the award, your team will have registration in LA for the next season for free.

Of course the rules will be subject to change in the form of FTC updating the document and in forum posts, so check up on those to see any changes in the rules.

Imagine this: you’re coding your autonomous one day. At the end of the day, it works fine, but it’s incomplete. One of you coding people says that he will take the code home and finish it. At your next meeting, you run the updated autonomous and nothing works; not even the stuff that worked last time you met. How do you fix this without reverting back to the old version?

The answer is simple: debugging.

What is debugging? Say you have a function that places a ring on a peg for the Ring it Up! game. After your coding person got his hands on the autonomous, for whatever reason the ring doesn’t get placed. The code looks like this:

// ex.c
void place_ring() {
do_stuff_so_the_ring_is_placed();
}

Debugging won’t magically make your program work; it won’t get the ring on the peg. All debugging does is tell you what the robot is doing. You can use debugging tools to see if a function is executing, or you can use it to see what in a program is going wrong. The debugging tool might be something visual, like text or a light, but it can also be auditory, like a noise. Here are some examples of debugging tools:

LEDs attached to your robot that get turned on through software are one debugging tool.

This works very well, but you need to spend quite a bit of money for it. You would need a prototype board, which is $49.95 from HiTechnic, and LEDs, which are $3.49 per at Radio Shack (assuming you want all the colors). You’d also need to wire it, which is a lot of work for simple debugging. Although use of LEDs in this way has their place, it is not the most effective form of debugging.

We use LEDs to indicate a sensor in our hand is activated, letting our drivers know we have a weighted ring (although this is not strictly debugging)

The NXT comes shipped with several noises on it, and the kind people at RobotC have made them available for the debugging process.

A better explanation as to how to use the sound functions is given by the people at RobotC. This way is very good; you need to spend extra money, since you already have an NXT, and all you really have to do in software is add a couple extra lines of code. There are drawbacks, though. When we’re running autonomouses, we’re sharing a room with two or three other teams, and it becomes hard to hear the NXT making the noises.

The NXT comes with an LCD display that RobotC gives functionality to. It has the advantage over other debugging devices in that it allows you to speak plain English.

We used this method for a program that we ran that told us what data our IR sensors were reading. We ran into problems where we had to duck to see the screen of our NXT, but we were later told that there are ways of viewing the NXT screen from a computer that is plugged in.

The method of debugging that the people who make RobotC recommend is through the debug screen. The debug stream is a window in the RobotC interface that will display text given to it with a special function. It is depicted on the right.

The debug stream is accessed from Robot/Debug Windows/Debug Stream. The steam is shown on the right.

Before we get to the debug method, the preprocessor must be explained. In C-related languages (C, C++, Java, RobotC), most lines that begin with a pound sign (#) are preprocessor lines. When you run a program, most of the time things in your program will only be evaluated when your program is running. A preprocessor directive will be evaluated when your program is compiled. Take this example:

When the program is run, the C compiler will fetch Autonomous_Base.h and make it so you can use functions from it. When the program is later run, it will evaluate IRmax_sig(), a function from Autonomous_Base.h.

There are other preprocessor directives, as well. You might have seen #pragma before. For purposes of debugging, we’re going to use #ifndef.

A detailed explanation of the preprocessor is available here. If it seems confusing, that’s because it is.

This debug mechanism is used in combination with others. You have with your functions a bool type for debug mode (shown above) and you say #ifndef _debug, which translates to “if debug is not defined,” and you put below it a main task for when debug mode is off. You have after the task an #else, which operates like the standard else. You have then a different main task that has all the debug mode bools set to true.

But when is debug mode defined? After you hit F5 to send a compiled copy of your code to your robot, a window opens, much like this:

When “Start” is pressed in the Program Debug window, _debug is defined.

Pressing start will define _debug for you. This isn’t our favorite method, but it does have it’s place.

We hope that you have found this tutorial on debugging helpful and that coding your autonomouses goes smoother.

And that drive function is good because it only takes up two lines of code, but it’s bad because it’s difficult to use. It assigns the y-value of the left joystick to the left drive motor and the right drive motor to the y-value of the right joystick. This makes turning very confusing.

The first priority in writing a drive function should always be make it convenient for the driver. This is a drive function that we recommend:

This is an arcade drive function where the joystick makes the robot behave like a joystick in a video game. If you push forward on the joystick, the robot goes forward; push the joystick down and to the left, the robot rotates to the left while moving backwards.

This method works very well for us, but even it can be improved. The Logitec controllers employed by FTC do not always center at (0, 0). Sometimes they’ll give some minute value like (2, -1). Although setting your drive motors to that much is unlikely to move your robot, it will try and move you motors to no avail. That’s bad because it puts stress on you motors, which can lead to smoking. Here’s our solution:

We recently contacted Finding Blue Moose FTC team 5468 in regards to how to run team meetings. Here is what they said:

Hi Fletcher!

It’s great to hear from you. We’re happy to help you out in any way we can. Our team is a little bit different in that we are not affiliated with our high school and run our meetings out of team members basements, garages, and kitchens. (This results in many all nighter style meetings.) Making “To-Do” lists is pretty helpful. Having a list of chores/deadlines is something that usually helps us. We are procrastinators, so having some sort of set deadline can give us the motivation we need to get stuff done. Also, try and make as much progress as you can outside of meetings. (For example, if someone is struggling with programming, their homework is to look up as many videos and tutorials as they can before the next meeting. This will help you keep moving forward!) About how much time do you have a day to spend meeting? How did you rank in San Diego and what sorts of changes do you hope to make before the next event? Have you qualified for World before?

Something that has helped us during competitions is making sure to decorate our pit area as much as we can. It’s impossible to have too much team spirit! This season, because we have so many rookies, we also did a practice run of our judges interview. Some of the veteran members asked our newbies some sample questions we have had in the past to give them a feel for what the judges room would be like. Maybe doing some sort of prep like that can help your team.

Let me know if we can assist with anything else. I could talk about FTC all day!

Thanks,

Chase

Finding Blue Moose

5468

After answering their questions, they followed up with this:

Hi Fletcher,

Glad I could help! I talked with some of my other team mates and we came up with a few more tips for you:

Some things that we have seen teams do before is make a handout about your robot. At the Vermont Championship last weekend, there was a team that passed around pamphlets in the pit area that included notes and information on their design. It was a neat idea. This made it much easier for scouts during the alliance selections.

One thing that our team tried doing at our first two competitions was setting up a Help Station. (This will probably be easy to implement, seeing as your team is hosting.) We had a table set up with basic parts and supplies and a sign out sheet to keep track of it all. (We borrowed this idea from our friends Team 5454 “dent in the Universe.”) We received good feed back from it. Doing something like this can show the Judges your Gracious Professionalism!

Color coordinating your table is a great idea and your interactive video software sounds awesome! Balloons are also a pretty good way to fill up your pit space. Our team also made some backboards highlighting our team members, robot design, and community outreach. You may have seen this on our Facebook page, but we also have a wooden moose that we painted blue and set up in the pit area. We had other teams autograph it throughout the course of the day, which was pretty fun. I’m not sure if there is something simplier than that, that your team could try. But it’s a thought! We also cut our team number out of cardboard so we could hold it up during our matches. That’s a pretty quick and easy way to show spirit.

I didn’t realize this initially, but I have watched some of the videos on the Suit Bots website. Your weighted ring detection system is very cool. Best of luck this weekend.