Chief Delphi - Coding conventions

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Coding conventions (http://www.chiefdelphi.com/forums/showthread.php?t=23345)

Re: Coding conventions

As for motor reversals: I believe that we should assume (when sharing code, at least) that to go forward

Code:

left_drive_motor = 254;

right_drive_motor = 254;

and all other movement can be inferred using this as a baseline. If a motor needs to be reversed, it is a simple matter for the team dealing with it to add the one line to thier code. Personally, I believe that this leads to code with maximum readability.

Re: Coding conventions

i agree completely, and i have done it the same way, well, forever, but i wasn't sure what the general consesus was about it.

Re: Coding conventions

Quote:

Originally Posted by Noah

As for motor reversals: I believe that we should assume (when sharing code, at least) that to go forward

Code:

left_drive_motor = 254;

right_drive_motor = 254;

Most people probably use skid steering with two motors, like in this example. You're probably also using the single joystick algorithm to mix the X and Y axis. Have you thought about modelling the robot to match that algorithm instead of setting the speed of the two motors? You would have a forward/reverse component and a rotational component. Something like:

Code:



//data types (from typelib.h, included for clarity)

typedef unsigned char uchar;

typedef unsigned int uint16;

typedef signed int sint16;



typedef struct {

    unsigned int cmdForward;  //range 0-255, 127=neutral, 127=forward

    unsigned int cmdRotate;    //range 0-255, 127=neutral, >127=clockwise

} robotModel;



//global robot variable

robotModel robot;



//map robot model commands to RC PWM outputs

void MapRobotOutputs()

{

    overlay sint16 temp;



    //set the left-hand drive motor

    temp = (sint16)robot.cmdForward + (sint16)robot.cmdRotate - 127; 

    pwm01 = NormalizePWM(temp);



    //set the right-hand drive motor

    //on our robot, the right-hand motor is mounted in reverse

    temp = (sint16)robot.cmdForward - (sint16)robot.cmdRotate + 127;

    pwm02 = 255 - NormalizePWM(temp);

}

 

//keep a pwm value between 0 and 255

uchar NormalizePWM(sint16 value)

{

    if (value < 0)

        return 0;

    else if (value > 255)

        return 255;

    else

        return (uchar) value;

}

If you only set the cmdForward and cmdRotate fields in the robot struct, and call MapRobotOutputs() during each program loop, then you have a standard API for both teleoperation and autonomous. Later you can close the loop on the rotational component by using the gyro within MapRobotOutputs() and add any scaling or filtering as you go. If you scale the values in that function then your autonomous code won't have a big deadband in the middle as you step from 0-255 or vice versa. There is a whitepaper on IFI's web site from last year describing how to do that.

From the teleoperation code you just set cmdForward = Y axis and cmdRotate = X axis. During autonomous you can rotate in place by keeping cmdForward = 127 and varying cmdRotate.

Re: Coding conventions

Quote:

Originally Posted by seanwitte

pwm02 = 255 - NormalizePWM(temp);

The point of my post was to say that lines of code such as this should not be included in short excerpts. The idea is that if a motor is to be reversed, it should only be done in one place in the code, preferably immediatly before output. When writing code, you can assume that if pwm02 (which, following convention 1 at the top of this thread should be R_MOTOR or some other macro) is full forward when it equals 255. Your code sets it to full forward at zero.

The point of my post was not to create a control algorithm, rather to define a convention for all FIRST programmers so that we can more easily communicate.

Re: Coding conventions

Quote:

Originally Posted by Noah

The point of my post was not to create a control algorithm, rather to define a convention for all FIRST programmers so that we can more easily communicate.

wow, this guy keeps stealing my wind. This is exactly what i had in mind.

Re: Coding conventions

Quote:

Originally Posted by Anthony Kesich

wow, this guy keeps stealing my wind. This is exactly what i had in mind.

The point of my post was to show you an example of a standard abstract model that anyone could use. The implementation of MapRobotOutputs() is specific to the robot and would never be shared. If you all agree on a model then not only will you understand each others work, you can reuse it. If you write a really sweet line following function then anyone could use that code because you'd all be coding to the same model.

You've already done it by saying that "drive_motor_right" and "drive_motor_left" are always referenced as 255 being in the forward direction. The sample was just another way to think about it.