guidance for coaches

Technical Programming
1

In my experience as a programmer, There’s been a lot of people not understanding what’s necessary to create functional code.
That’s all fine and dandy, when they have their own job. But when they’re your coach, you run into problems.
They don’t know what to expect of you. They don’t know how to support you. They sometimes don’t know how to tell whether a problem with the robot is due to programming, wiring, field communications, or mechanical.

I’d like to relieve rookie teams from a lot of that stress and misunderstanding.

Is there a document that would help solve this problem, or do I have to make one?

2

This probably isn’t exactly what you’re looking for, but one thing I would highly recommend for this scenario is a good dashboard. Having a good dashboard, and having a coach that understands how to read it is very helpful for diagnosing on field robot problems.

3

Good idea!
I might modify the dashboard this year to include info on the percentage of packets that are being received on time.

How might you convey what the needs of a programmer are?
I guess a better question is, What are the needs of a programmer?
I’ll just throw this list out here:

paper, pencils, eraser, binder
flat surface
good light
food and water and warmth and access to bathrooms
an understanding of how the robot is supposed to work
metrics and goals for the performance of the robot
laptop that they can take home
internet access
plenty of time for testing
some method of backing up code
someone to talk to and ask for help (a mentor on your team, a mentor on a different team, a knowledgeable student)
a plan or timeline of when they expect to finish each part of the robot, so they can prioritize on features
printed resources on how the control system works (including motor controllers)
resources on their programming language of choice
a process for how to approach the task

4

Just for clarification for those who might not realize that (such as rookies):
One of the ways to interpret “Understanding how the robot works” is understanding what actions does the robot take in the Autonomous time; In Teleop - What are the key mappings on the joysticks to control different aspects of the robot, how do these buttons work and what are the states of the robot when using each button(auto arm up by pressing once, or manual arm up as long as you hold the button).

Most of the understanding is done by observing the robot’s behaviour in test driving/drivers training.

5

In addition to that, the programmer must know what sort of actuator is being used - variable-speed motor, a relay-controlled motor, a pneumatic piston
as well as how that actuator is actually coupled to the claw or arm or drivetrain, or whatever it may be
so that the programmer can determine what sensors should be used and where they should be placed. (theoretically, the electrical or mechanical team pick the sensors, but not without a programmer’s input)

6

Just as a warning … usually the programmers get the least amount of time with the robot. The mechanical group takes for ever testing and changing things, while the electrical is given no room for any of there components and the programmers get very little time and are rushed to show results.

The programmers should try to be involved or at least listen to the discussions by the other groups. Once you get an idea of what they want you may want to write a few programs to cover the different situations. i would highly recommend that you start with the drive and maneuverability of the robot first. Determining if the “Drivers” (not programmer, mechanical, electrical) wants to have tank drive, single joystick, or the ability to quickly change from single to tank will help with the development of the driving program. After having radio controlled driving finish I would work on Autonomous until other programs are need, because the other groups will come to the programers asking for a simple program to test some of their designs.

I guess the best advice I can give is to make sure that all of your groups communicate, that is the job of your coach to make sure that everyone is on the same page.

-Oris-

7

For clarification, are you referring to drive team coaches (roboCoach or Field Coach) or are you referring to team coaches (the person in charge of the team administration)? Or maybe both? :confused:

8

You have some good input, Oris. I’m going to elaborate one part of your post that I think needs more emphasis.

I’ve definitely encountered this, and it’s one of the problems I’m trying to address here.
The design should take place initially as a group, with everyone participating, and that’s where the metrics and goals are decided upon.
After the first week, there should be a design everyone can work with, including drawings for layout.
If your rookie team builds a kit-bot at the kickoff, then they have a robot they can drive. It will drive with the default code. (the main thing holding them back there is that the wiring probably won’t get finished until the next day, unless your team brings a panel of plywood to mount the control system components to).
On the layout drawings you made in your design process, there should be the components of the control system (easily accessible), as well as the mechanical components (hopefully still easily accessible).
You can have the programmers and mechanical working at the same time without major conflictions. The programmers work mainly with the sensors, and the mechanical works mainly with the superstructure. Actually, if you mounted your whole control system on a single piece of plywood, then the programmers can borrow the control system, and the mechanical borrows the frame.
How do you know it will fit back together? Follow the drawings.

9

One of the most important things you can do is sub-team integration. We have 3 robot sub-teams - mechanical, electrical, and programming, and each sub-team has one or more dedicated mentors working with them. That means every area gets some great coverage and guidance, but often the team uses it as a crutch. For example, the electrical team might be wiring everything together on the robot and ask a mentor “which PWM port does this victor plug into?”… Well, we don’t know, its your robot! It takes a lot of work to get the sub-teams talking on a regular basis and sharing this information between themselves.

All that being said, there’s a lot that the programming sub-team can do to help make diagnosing problems easier. A lot of times you look at a robot and say “why did it do that?” or “Why didn’t that arm stop when it was supposed to?” A diagnostics program would let you run through every input and output on the robot and test its expected functioning. For example, if you had a limit switch somewhere, it would sit there and do nothing until you manually pressed and released the switch - then it would do something (like output to a dashboard) that told you that test was successful. Do that for every switch on the robot. Do that for any other sensors you may have (encoders, potentiometers, range finders, etc). Once you’ve run through all of those, the diagnostics program can run through the motors - drive forward for 1 second, back for one sec, move and arm one way then the other, etc. base all movement on pressing a button on the OI so you avoid injuring someone.

With a program like that, you’ll be able to quickly eliminate problems:

  • If the program doesn’t detect when your pushing a limit switch, something is wrong with the switch (not wired correctly, broken and not working, etc) - call the electrical team over to fix it.
  • If the switch is working, but your real code doesn’t seem to be working with it, you can manually move arms and parts through their normal motion, and see if they are properly triggering the switch with the diagnostics program. If not, call over the mechanical team to mount things correctly.
  • And if none of the above work, then the problem is probably somewhere in the code.

And as a last note, even experienced programmers with years of experience in FIRST can’t always tell what the problem is right away. The best you can do, as a team, is to set up a systematic approach to debugging problems that everyone is involved in and doesn’t put the burden on any small subset of the team - that only leads to drama, pressure, hurt feelings, and a bad time for everyone.

And if it helps, here’s a debugging issue I had to deal with in my Autonomous Robotics class in college that I relate to my students all the time. The class was set up very similar to FIRST - we had a KoP, a small team, a limited deadline, and in the end were paired up in alliances to play a game. Getting near the end of the “build season” for the class, we were debugging our robot and running into a few problems - it would be working fine, then suddenly start behaving extremely oddly. Back then, we had a small (3 characters x 10 characters) screen for output. No tethering or dashboards for us!. So we started putting in more debugging statements - simple print statements that don’t do anything except display stuff on the screen. And the problem got worse. We did more, and it got even worse. We said to ourselves, “this can’t be a code problem, we aren’t changing anything!” Well, it turns out that the control boards we were using had a little hidden bug in them - if you tried to output anything to the screen that was an odd length, it would end up corrupting your program. Going through the code and deleting all those debug statements fixed it. The moral of the story is: even when you do everything right, things can still go wrong. You may not know why, and that’s ok - the key to the whole program is understanding the process you go through to figure it out and solve the problem.

10

If you’re a rookie team, the cRIO from the Kit of Parts won’t come with a program pre-installed that can drive a robot. You’ll have to give it one. That means you’ll have to load the FRC programming software onto a computer, find the example “default” program, compile it, and download it to the cRIO.

If you’re a veteran team, you almost certainly don’t have “default” code in your cRIO. You can start fresh the way rookies will, or you can try to wire your robot to match the code that is already installed.

In the days of the IFI controller, a team could plug stuff in and have a running robot without anyone touching a computer. Now, the programmers have about as big a job to do as the mechanical and electrical groups in order to get a robot doing anything.

11

That statement sounds good on paper, but with FIRST the design you come up with during the first week will not be that same as the one you ship because you will continue to revise and improve your design.

As for your controls you should put them on a piece of plywood, even screw down a motor to let the programmers play with it. This will allow for you electrical and programming team to get familiar with the components. On our team the mechanical group usually decides where the electrical components will go. Once this has been designated the electrical group will start laying out the final locations for the competition robot.

In the end it will fit together because the team will find a way for it to work.

-Oris-

12

What do coaches expect of programmers?
What should coaches expect of programmers?

13

Like i said in your other thread… That depends on the team. If your programmers haven’t done any programming in the past, keep it simple and expect to spend most of the time teaching. If they know what they’re doing… keep it simple, and expect to spend most of the time improving on the simple start you know is working. One of the most important things to remember is the more complex you make something, the easier it is to break - the same is true about code. Our first goal every single build season is to get it working as simply as possible. Once that’s accomplished, then we can start playing around with the camera, or with additional sensors, or feed back loops or whatever we feel is needed that year.

Sometimes the best solutions are the simplest. A great example of this comes from 2008 for our team. One of the students wrote our autonomous mode as simply as possible - drive forward for x seconds, turn left for x seconds, drive forward for x seconds… and it worked pretty reliably, almost always getting us 3-4 lines. Later that summer, we decided to redo it with PID loops… and never got it working.

As mentors, we need to be able to judge the teams limits, and set attainable goals.

14

I have always found a big help for the programmers is if electrical makes a big poster that they put on the wall, they then fill in the PWM’s as they assign them. Then the programmers and electrical are on the same page.

15

With programming you need knowledge of the electronics to understand exactly where each signal goes. You know that you can only control the cRIO and so you need to know how and where everything works/is (like how a sensor works. Does it send an analog or digital signal? Things like that)

For my team, we group the programming and electrical teams together. You can’t be a programmer without being an electrician.

As for what to expect: like eagle said. Simple first, and then get more and more complex. Just remember that with the controls that safety is the number one priority. Last year we had to program an all-stop for our roller mechanism in case of problems. We had to make an exception to the simple rule and my coach wasn’t satisfied until we could keep the same functionality with an all-stop button.

16

Marshall,
The thread seems to have drifted from this first query so I will answer this only. Determining where a fault may lie is a not a science but more of a black art. A document for determining faults would be almost robot specific. As Alan has pointed out, default code is not universally used now that we are using the cRio. There is one thing that I try to get team members to follow which is not robot specific. That is LISTEN to the robot. The sound it makes, the reaction it performs, the way it drives are all messages that are spoken in robot. You must listen to the robot to determine if there is a fault. Two drive motors wired in opposition make a sound that is almost discernible from across the pit. A good maintenance person often may not speak robot but can understand the language.
I remember a robot problem from two years ago in Atlanta that a team struggled with for most of a day. They called me over on Saturday to help diagnose the problem. When I had them run the robot forward and reverse, there was no doubt that the drive chain was loose and jamming against a frame part. The robot spoke but they didn’t hear. Others heard it but were ignored or failed to speak. I know many people who would have understood the problem because they would have listened to the robot. They won’t all tell you they “listened” to what the robot had to say, but they would have diagnosed the problem in the same time and arrived at the same conclusion.
Listen to your creations, they speak all the time. If you don’t listen, they will get your attention in a much more spectacular fashion using smoke, cracked parts, metal shavings or a lost Einstein trophy.