Last minute autonomous help

[IRunOnJava]

My team is scrambling to create a working autonomous.

Our code, so far, is a modified version of the Java sample line tracker. We had to change our code to work off of two sensors because, unfortunately, one of our three line sensors came broken.
We understand that all the sample code does is move the robot forward for 8 seconds, but even with this sample code loaded on the robot, our robot does zilch. We're just trying to get our robot to show some sign of life while put in autonomous mode.
Can anybody help us out? All suggestions are appreciated.

Here's what we have loaded, autonomous-wise:

    public void autonomous() {

        getWatchdog().setEnabled(false);
        getWatchdog().feed();
        //Timer.reset();  //Resets the timer
        //Timer.start();  //Starts the timer
        int binaryValue; 
        int previousValue = 0; // the binary value from the previous loop
        double steeringGain; // the amount of steering correction to apply

        // the power profiles for the straight and forked robot path. They are
        // different to let the robot drive more slowly as the robot approaches
        // the fork on the forked line case.
        double forkProfile[] = {0.70, 0.70, 0.55, 0.60, 0.60, 0.50, 0.40, 0.00};
        double straightProfile[] = {0.7, 0.7, 0.6, 0.6, 0.35, 0.35, 0.35, 0.0};
        double powerProfile[];   // the selected power profile

        // set the straightLine and left-right variables depending on chosen path
        boolean straightLine = ds.getDigitalIn(1);
        powerProfile = (straightLine) ? straightProfile : forkProfile;
        double stopTime = (straightLine) ? 2.0 : 4.0; // when the robot should look for end
        boolean goLeft = !ds.getDigitalIn(2) && !straightLine;
        System.out.println("StraightLine: " + straightLine);
        System.out.println("GoingLeft: " + goLeft);


        boolean atCross = false; // if robot has arrived at end


        // time the path over the line
        Timer timer = new Timer();
        timer.start();
        timer.reset();

        int oldTimeInSeconds = -1;
        double time;
        double speed, turn;

        // loop until robot reaches "T" at end or 8 seconds has past
        while ((time = timer.get()) < 8.0 && !atCross) {
            int timeInSeconds = (int) time;
            // read the sensors
            int leftValue = left.get() ? 1 : 0;
            //int middleValue = middle.get() ? 1 : 0;
            int rightValue = right.get() ? 1 : 0;
            // compute the single value from the 3 sensors. Notice that the bits
            // for the outside sensors are flipped depending on left or right
            // fork. Also the sign of the steering direction is different for left/right.
            if (goLeft) {
                binaryValue = leftValue * 4 + rightValue;
                steeringGain = -defaultSteeringGain;
            } else {
                binaryValue = rightValue * 4 + leftValue;
                steeringGain = defaultSteeringGain;
            }

            // get the default speed and turn rate at this time
            speed = powerProfile[timeInSeconds];
            turn = 0;

            // different cases for different line tracking sensor readings
            switch (binaryValue) {
                case 1:  // on line edge
                    turn = 0;
                    break;
                case 5:  // all sensors on (maybe at cross)
                    if (time > stopTime) {
                        atCross = true;
                        speed = 0;
                    }
                    break;
                case 0:  // all sensors off
                    if (previousValue == 0 || previousValue == 1) {
                        turn = steeringGain;
                    } else {
                        turn = -steeringGain;
                    }
                    break;
                default:  // all other cases
                    turn = -steeringGain;
            }
            // print current status for debugging
            if (binaryValue != previousValue) {
                System.out.println("Time: " + time + " Sensor: " + binaryValue + " speed: " + speed + " turn: " + turn + " atCross: " + atCross);
            }

            // set the robot speed and direction
            robotDrive.arcadeDrive(speed, turn);

            if (binaryValue != 0) {
                previousValue = binaryValue;
            }
            oldTimeInSeconds = timeInSeconds;

            Timer.delay(0.01);
        }
        // Done with loop - stop the robot. Robot ought to be at the end of the line
        robotDrive.drive(0,0);
    }

[davidthefat]

You say two? Good luck with that, it can be done, but you will require either gyros or encoders. Keep a record of the speeds, or the angle it has veered off to. Mount a line tracker in the front, and the other one in the back so it always is triggered. Do some calculations. I too have to work on the autonomy. I will be writing my own from scratch.

[alexhenning]

We don't use line tracking, we use encoders we drive a fixed distance straight and place a piece.

Since you're running so late. try code that powers your drive forward at say 1/3 power for 5 seconds. Tune it until it just bumps the wall and then place a piece. Make sure you keep a good battery, but I think that's your best bet for a last minute autonomous BEFORE you ship.

Alternatively, look up teams going to your first regional and see if there's anyone like my team who hasn't used there line sensors and wouldn't mind giving you one.

[Patrickwhite]

Are you getting any response when you deploy? If the robot does nothing, the robot is probably quitting unexpectedly, which you would receive. As for working with two photosensors, if you are dead set on using them (instead of other sensors or dead reckoning as has been suggested) I would place them directly adjacent to each other, so they can both be tripped by the tape at the same time and working with that. There may be some interference however (one receiving the reflected light from the other and returning a false positive) and it obviously won't be ideal.

[AlexD744]

Personally I find the encoders a more reliable way of making an autonomous algorithm. You simply drive until you hit a certain number of encoder counts. Then you move your manipulator. Then you drive some more. Then you place. Then you reverse.
If you're using the Iterative Robot template, the easiest way to do this is do create different state machines for the drive and each of your mechanisms. Then you create a main state machine that simply feeds these other machines values and waits for the drive or manipulator to be in place. Once the structure was created, fine tuning the numbers only took a few hours, and now we can place on any of the high pegs and the middle second level pegs reliably (as long as we're using a fresh battery that is).

[davidthefat]

Originally Posted by AlexD744

Personally I find the encoders a more reliable way of making an autonomous algorithm. You simply drive until you hit a certain number of encoder counts. Then you move your manipulator. Then you drive some more. Then you place. Then you reverse.
If you're using the Iterative Robot template, the easiest way to do this is do create different state machines for the drive and each of your mechanisms. Then you create a main state machine that simply feeds these other machines values and waits for the drive or manipulator to be in place. Once the structure was created, fine tuning the numbers only took a few hours, and now we can place on any of the high pegs and the middle second level pegs reliably (as long as we're using a fresh battery that is).

I personally would disagree with you on that: because our robot is driven by chain, there are a lot of noise in the encoders from the chain jerking around. I suggest one day just put the robot on blocks and let the motor run through from 0 to 255 PWM and graph the encoder data vs the PWM. You will be surprised at the noise.

[alexhenning]

Originally Posted by davidthefat

I personally would disagree with you on that: because our robot is driven by chain, there are a lot of noise in the encoders from the chain jerking around. I suggest one day just put the robot on blocks and let the motor run through from 0 to 255 PWM and graph the encoder data vs the PWM. You will be surprised at the noise.

My team used encoders and we have a reliable autonomous even though our robot has chain. The noise is minimal, I haven't graphed it, but after ~30 successful runs, I wouldn't worry about it unless your chain is really lose or otherwise acting up.

The other thing about encoders is that with some math, you can convert it to feet. You know how far back you start, so drive N feet forward and then place the piece. All the fiddling is with the arm then.

[PriyankP]

Originally Posted by alexhenning

My team used encoders and we have a reliable autonomous even though our robot has chain. The noise is minimal, I haven't graphed it, but after ~30 successful runs, I wouldn't worry about it unless your chain is really lose or otherwise acting up.

The other thing about encoders is that with some math, you can convert it to feet. You know how far back you start, so drive N feet forward and then place the piece. All the fiddling is with the arm then.

Sorry to bring up this relatively old topic but I was wondering how are you using encoders to go to a certain distance? Do you just have PID and Setpoint encoders to some number? Or are you using something else too?

Any other teams out there willing to share how they use their encoders in autonomous?

[alexhenning]

Originally Posted by PriyankP

Sorry to bring up this relatively old topic but I was wondering how are you using encoders to go to a certain distance? Do you just have PID and Setpoint encoders to some number? Or are you using something else too?

Any other teams out there willing to share how they use their encoders in autonomous?

I have two encoders hooked up to jaguars running CAN one for the left side and the other for the right side. The autonomous does P (No need for ID) so that it slows down as it gets closer until it hits the wall going pretty slowly. This runs reliably as long as it's lined up and the left and right sides act the same. i.e. You jam both joysticks forward and it actually drives straight-ish.

Here's the relevant code.

	    leftDist = bot.dt.getLeftDist() - leftStart;
	    rightDist = bot.dt.getRightDist() - rightStart;
	    
	    double left = gain * ((distance - leftDist) / distance);
	    double right = gain * ((distance - rightDist) / distance);
	    
	    bot.dt.drive(left, right, bot.gyro);

distance is the distance you wish to travel in feet.
gain is the initial value that gets toned down as you drive (Currently using 0.7)

Hopefully the rest of the code is clear enough that it makes sense. If you have anymore questions feel free to ask. Also, you can PM me if you want to see our full autonomous code.

[PriyankP]

Originally Posted by alexhenning

I have two encoders hooked up to jaguars running CAN one for the left side and the other for the right side. The autonomous does P (No need for ID) so that it slows down as it gets closer until it hits the wall going pretty slowly. This runs reliably as long as it's lined up and the left and right sides act the same. i.e. You jam both joysticks forward and it actually drives straight-ish.

I was thinking of putting on two encoders to get the base to stop within 6 inches of the target distance without overshooting and without travelling slowly. Not sure if that's possible yet because we don't have encoders on the base yet but I would imagine I'll need I and D. The biggest problem that I'll have is momentum because I plan on running the auto at close to full speed.

If you don't mind, can you please send me the code that has to do with your base? I'm sure I can learn from it as I can't find many resources that explain the concepts. :O

[alexhenning]

Originally Posted by PriyankP

I was thinking of putting on two encoders to get the base to stop within 6 inches of the target distance without overshooting and without travelling slowly. Not sure if that's possible yet because we don't have encoders on the base yet but I would imagine I'll need I and D. The biggest problem that I'll have is momentum because I plan on running the auto at close to full speed.

If you don't mind, can you please send me the code that has to do with your base? I'm sure I can learn from it as I can't find many resources that explain the concepts. :O

Chiefdelphi has a number of helpful post on PID, for starters: http://www.chiefdelphi.com/media/papers/1823

Is there any reason you can't overshoot? Fast speed to wall, then slowly backing up 6 inches may be better, unless it smashes your arm or something. Don't forget, you have 15 seconds, consistent even if slow is better than inconsistent and fast.

Hope that helps a bit.