ASAP Code giving outOfMemory error

[ahwhitley]

Hello everyone and thanks for reading,
I am a programming mentor on rookie team 4998. We are working on finishing our code for competition Thursday but are running into issues. I am getting a outOfMemory error which is then followed by "Robot Drive... Output not updated often enough." continuously outputting once the robot is enabled. It sounds like this is a result of a motor getting declared but not set. I can not seem to solve this no matter how I change the code around. If someone could take a look, it would help me a lot. I will be recreating it completely tomorrow if I do not get a response because it wasn't coded the best way and I need it to work.
I will try and check back a few more times tonight to respond.

Thanks for help everyone!
Andrew

[pblankenbaker]

I took a look through your code and have the following comments/suggestions:

You need to refactor the execute() methods in several of your commands. For example, the execute method in Shoot.java looks like:

    
    // Called repeatedly when this Command is scheduled to run                  
    public void execute() {

        if (catapult.CatapultMSStart())
        {
            while(!catapult.CatapultMSEnd()) {
                catapult.ElevatorMotor1(speed);
                catapult.ElevatorMotor2(-1 * speed);
            }

	    catapult.WaitAfterShooting();

            while(!catapult.CatapultMSStart()) {
                catapult.ElevatorMotor1(-1 * speed);
                catapult.ElevatorMotor2(speed);
            }
        }
    }

As a rule of thumb, you should never run code in the execute() method of a command that takes any measurable time (loops, delays and waits should not be used).

This is fundamental rule that needs to be followed when using the CommandBased framework (the execute() method of one active command must complete before the execute() of the next active command is invoked).

For example, if the code fragment above takes 2 seconds to run. Then none of the execute methods of the other commands on your robot will run for 2 seconds. The driver won't be able to drive the robot and the robot will continue on "cruise control" until the motor safety kicks in and kills your program with the dreaded "Robot Drive... Output not updated often enough." message.

This is most likely the reason you are seeing the "Robot Drive... Output not updated often enough." message. Once you see this message, you are probably done for the match.

To refactor this type of code, you will either need to break the Shoot command into separate simple commands that you can join into a sequential command group: WaitForCatapultReady, WaitAfterShooting, RaiseElevator, LowerElevator.

For example, if the following code fragment raises the elevator:

            while(!catapult.CatapultMSEnd()) {
                catapult.ElevatorMotor1(speed);
                catapult.ElevatorMotor2(-1 * speed);
            }

A RaiseElevator command might have the following execute(), isFinished(), end() and interrupted() implementation (NOTE: I don't know the specifics of your robot - I'm guessing there is a elevator on it and how you go about raising it):

public class RaiseElevator extends CommandBase {
  private double speed;

  public Shoot(double theSpeed) {
     // Register that we need exclusive control of the catapult
     requires(catapult);
     // Save power to apply when moving the elevator
     this.speed = theSpeed;
  }

  protected void execute() {
    // Set motors to raise the elevator
    catapult.ElevatorMotor1(speed);
    catapult.ElevatorMotor2(-1 * speed);
  }

  protected boolean isFinished() {
    // Done once the elevator is at the top position
    return catapult.CatapultMSEnd();
  }

  protected void end() {
    // Stop elevator when in position
    catapult.ElevatorMotor1(0);
    catapult.ElevatorMotor2(0);
  }

  protected void interrupted() {
    // Do normal clean up (stop motors) if command interrupted
    end();
  }
}

In the implementation above, none of the methods have any loops or delays (they run almost instantly). This command achieves an effective delay by only returning true once the elevator is in position. This command might take two seconds to complete, however it never blocks other commands from running while waiting for the completion state to be reached.

If you don't want to break your Shoot command into a group of separate command, it is possible to refactor it by keeping track of states (define a set of states to transition through, have the initialize() method put it in the initial state, have the execute() method do an action based on the state (but no loops/delays), have the isFinished method determine when to move to the next state or when it is done.

Wrapping your head around the CommandBase framework takes some time, but it does have a lot of nice advantages over the SimpleRobot framework (especially on robots with numerous subsystems). Keep at it and I'm sure you work your way through the issues.

Good Luck.

[ahwhitley]

Thank you very much for the detailed reply! It helped a lot to understand how the command/subsystem framework works. I should have realized that the commands were suppose to be recursion based (that's what it looks like is happening) based on some sample code I was using.
Either way thanks for the reply again. This should definitely be enough info to finish the code up.

Andrew

[NotInControl]

Originally Posted by ahwhitley

Thank you very much for the detailed reply! It helped a lot to understand how the command/subsystem framework works. I should have realized that the commands were suppose to be recursion based (that's what it looks like is happening) based on some sample code I was using.
Either way thanks for the reply again. This should definitely be enough info to finish the code up.

Andrew

Commands shouldn't be recursion based if you are using the strict computer science definition of recursion (a function/method which calls itself).

Commands should be seen as instructions to control the hardware tied to a subsystem. A command can do one thing and finish such as set a solenoid in a subsystem and complete, or a command can run forever, and only close when interrupted, such as driving with Joysticks, which will run forever, and if you hit a button to run another command on that subsystem it will stop.

Take a look at the screensteps live wpi site for an overview of commandbase if its still unclear or post questions here.

If you are getting an outOfMemory message, you have a memory leak somewhere. I haven't looked at your code, but look for anywhere you use the new operator in a loop. That is probably not something you want to do.

Hope this helps,
Kevin