Autonomous speed

We’re trying to look at autonomous code and we’re trying to figure out how much time we need to move the robot to travel 19.5 feet. Does anyone know how fast the autonomous loop executes? How many milliseconds?

If you look at main.c you will see this code:

if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
{                                 /* I'm slow!  I only execute every 26.2ms because */
                                  /* that's how fast the Master uP gives me data. */
  Process_Data_From_Master_uP();  /* You edit this in user_routines.c */
  

  if (autonomous_mode)            /* DO NOT CHANGE! */
  {
    User_Autonomous_Code();        /* You edit this in user_routines_fast.c */
  }
}
Process_Data_From_Local_IO();     /* You edit this in user_routines_fast.c */
                                  /* I'm fast!  I execute during every loop.*/

}

From this one could conclude that it loops every 26.2ms because it is within the slow loop area.

While pure timing works, I wouldn’t recommend it. You loose accuracy as your battery dies, or your transmissions become easier/harder to work with. The other way to do that would be with encoders, which take a little more to set up, but should be more accurate.

Another option is to measure your distance based on the camera. If you are already tracking the green light with your camera, it only requires a bit of trig to figure out your distance of travel based off of servo movement.

Yeah, but if you look at User_Autonomous_Code() you’ll see that it enters a while loop there that loops fast until autonomous mode is over, where is returns back to the slow loop.

Do you have any pointers/tutorials/docs on how one would go about doing this? Dead reckoning is the only thing that I can think of, aside from using the accelerometer and an electronic compass (fricken expsensive, $60 :-… and no, my Team doesn’t have external funding).

You’re provided with an “electronic compass”, or rather, a Yaw Rate Gyro. It’s part of the sensor strip that has the accelerometer and gear tooth counters attached.
Look around on the forums here for explanations on how to use it.
In combination with encoders (either binary encoders like the provided gear tooth counters or quadrature encoders, which also determine direction), you can determine your position decently.

Woah, rewind.

I’ve been confused as (heck) with everyone talking about ADC’s, and various encoders. Please, /please/ explain to me what is mean by all of this. I, by all means, consider myself a very compitent coder (probably too much so). However, I’ve never dealt with this sort of stuff before (I do systems security in Linux\Windows*BSD environments).

How would I use this YRG as a compass? Would I have to zero it out at the beginning of every match (so that, on its starting block, it knows that to one side is its side, and on the other side, it must score against)?

What’s this ‘encoder’ stuff everyone speaks of? I’m confused as per the concept, as well as what the HECK a quadrature encoder is.

In addition, where/how do I mount the GTS in order for it to count gears? I don’t understand how they’re supposed to work, so I can’t make much use of them. The guy-in-charge-of-the-operation is too busy just trying to get the launcher mechanism finished and on the chassis to explain this stuff to me (Pretty soon, we might just end up with a very expensive RC Car).

First, for all teams thinking of traveling distances based purely on dead reckoning from timing, I would recommend against it. My team has not been able to get distance sensors working either year and has tried this both years; it is inaccurate, varies by battery voltage and other factors, and takes alot of testing and tweaking to get it somewhat close to right.

The gear tooth sensors this year were deisgned so they could be mounted directly into the transmissions provided in the kit (there are pictures in the Guidlines and Tips section that show where the sensors should be mounted). Wiring diagrams and instructions are also available. If you do not use the provided transmissions, you will have to find your own way of mounting the gear tooth sensors and putting them close enough to a gear to read it. The sensors basically sense when a gear tooth is in their magnetic field, and this information can be used to find distance traveled. Using timers, you can also develop ways to find speed.

Just another point of view. We tried driving our robot in autonomous w/o sensor data and it is fairly impossible. Sending a signal to your victors for a particular speed doesn’t mean your robot will go the same speed every time. As mentioned before, battery voltage and drive train variances will effect the outcome every time making prediction and accuracy hit or miss. Turning only makes the error worse.

As you are a competent programmer I would recommend acquiring Kevin Watsons code (if you aren’t using EasyC) which can be used quickly to get your kit sensors working. Explore these forums some more for various descriptions on what encoders are. Very simply though, encoders is a generic term for a sensor that can count (people feel free to correct me if I’m wrong!). There are few different ways to do this. Optical encoders use a beam of light, usually infrared, that when broken generates a signal (think garage door opener safty device). You can imagine that if reflective strips are placed at periodic intervals on a wheel and an optical encoder is focused at the wheel while it is spinning, an on/off signal will be generated that is proportional to the speed of the wheel. Depending on the application, this can be used as a way determine distance travelled. I believe the KOP this year has such encoders.

A simple mechanical encoder would be a momentary switch device that would signal when activated (think pegs on a wheel depressing a switch).

Now we have the KOP gear tooth counter which is an electromagnetic encoder that works on the Hall Effect which is why it also known as the Hall Effect sensor. It simply generates a signal when its surrounding magnetic field is disrupted which is why it works as a gear tooth counter. The caveat is that since it is based on magnetics, whatever it is counting needs to be ferrous. It just needs to be mounted in close proximity to the meshing face of the gears (1-2mm). As mentioned before, if you are using the KOP transmissions, they already have pre-drilled holes to mount the sensor on the face plate where the motors are mounted. The Tips sheet shows the picture. Just make sure the TAPERED part of the holes are facing OUT not IN, or it wont align properly. Also make sure that nylon washers are used to mount the gear tooth sensors or you’ll short it out.

Encoders are a simple way of getting distance travelled. Not perfect, but ok. You loose accuracy due to slippage and missed counts, but this is the way to implement dead reckoning. Timing in this scenario isn’t really dead reckoning because you don’t know what speed your going or what direction.

Now for a quick yaw rate gyro explanation. Again, Kevin Watson has code for gyros (how he does all this I’ll never know). As the name implies, yaw rate gyros send a signal proportional to how fast it is turning. In our case, since 5 volts is the base line, 2.5 volts means no turning, >2.5 means one way, <2.5 means the other way. Kevin’s code handles all the initialization and timing and integration and junk that makes it useful. Or you can use easyC which has the code built into the WPlib library. Either way the work has already been done.

Soooo if you get the gear tooth counter installed you can get distance. If you get the gyro installed you can get direction. I think I’ve rambled on long enough. I hope I was some help and didn’t confuse anyone.

Last year, my team’s autonomous mode was written at the very last minute, used only time, and worked reliably. However, we didn’t try to drive anyplace.

Our arm was controlled by a pneumatic ram attached to a solenoid that had three positions: 1)In, 2)Out, and 3)All ports blocked. We would turn it to “out”, wait a second or so, then set it to “all ports blocked”. Since we would always start with the same pressure no matter how much power we had in our battery, it was consistent in how far it traveled and would knock off a tetra from one of the corner goals.