1) The description of the TJoystick structure is missing the TeamColor field. Note that joystickdriver.c does document the values for TeamColor. I suggest adding some #define or enum values for teamColorRed and teamColorBlue.

2) The description of the TJoystick structure does not say what the possible values of UserMode are. Note that joystickdriver.c does not currently document the values for UserMode. I suggest adding some #define or enum values for userModeAuto, userModeDriver.

3) Likewise, I would suggest adding an enum or set of defines for the tophat positions:#define topHatIdle -1#define topHatNorth 0#define topHatNorthEast 1#define topHatEast 2....

4) I'm not real keen on the functions joy1Btn() and joy2Btn(). It seems inconsistant to have getJoystickSettings() take a TJoystick parameter but joy1Btn() and joy2Btn() always use a specific instance of TJoystick which is pretty much hidden from the user. Either hide the instance of TJoystick the way that joy1Btn() and joy2Btn() do for all fields of the TJoystick structure or have all of the functions take a parameter. Doing it half one way and half the other will be confusing and error prone.

One alternative would be to provide a macro that looked like this:

#define joyStickButton(buttons, n) ((buttons) & (1 << (n-1)))

The user code would look like this:

if (joyStickButton(joystick.joy1_Buttons, 2)).....

Or, you could do what we've been doing which is to define a set of values like so:

#define Button1 0x01#define Button2 0x02#define Button3 0x04....

Then the user code looks like this:

if (joystick.joy1_Buttons & Button2).....

5) I'm a little confused about the plan for this year's competition template. For the showcase tournament the competition template worked great. We just needed to provide the Initialization() function and the Autonomous() and HumanControl() tasks. I liked the simplicity that the main() in the template would start and stop the team's tasks as needed so that the team did not have to (and in fact could not) screw up the state transitions. Is there a reason you aren't using the same model now?

6) For this example: while(nMotorRunState[motorD] != runStateIdle){} //wait for motor to become idle //Above Line: Do nothing until motorD gets to the targeted position.Wouldn't it be better practice to insert a small wait into the body of the while to release unneeded CPU cycles for background tasks?

7) I know that the FTC Motor Controller supports additional functionality such as the difference between running at a constant power v/s running at a constant speed. It would be nice to have those differences explained in this guide.

8) You might also want to document how to use the HiTechnic Touch Multiplexer. We ended up writing our own accessor functions to interpret the raw sensor values.

Jeff

_________________Jeff McBrideBenson Robotics Club

Fri Sep 26, 2008 2:25 pm

tfriez

Site Admin

Joined: Wed Jan 24, 2007 10:42 amPosts: 620

Re: FTC Functions Guide - Version 1

Jeff McBride wrote:

1) The description of the TJoystick structure is missing the TeamColor field. Note that joystickdriver.c does document the values for TeamColor. I suggest adding some #define or enum values for teamColorRed and teamColorBlue.

Unfortunately this feature was removed by FIRST and National Instruments. ROBOTC still supports it, but there's no way to toggle the variable in any version of the Field Management System or Controller Station. It's useless, so I left it out of the documentation.

Jeff McBride wrote:

2) The description of the TJoystick structure does not say what the possible values of UserMode are. Note that joystickdriver.c does not currently document the values for UserMode. I suggest adding some #define or enum values for userModeAuto, userModeDriver.

Not a bad suggestion. I can update to explain which value is true and which value is false. I'm not sure an enum is required, however, since it is a Boolean value.

Jeff McBride wrote:

3) Likewise, I would suggest adding an enum or set of defines for the tophat positions:#define topHatIdle -1#define topHatNorth 0#define topHatNorthEast 1#define topHatEast 2....

We'll leave this up to the user, but it's not a bad suggestion.

Jeff McBride wrote:

4) I'm not real keen on the functions joy1Btn() and joy2Btn(). It seems inconsistant to have getJoystickSettings() take a TJoystick parameter but joy1Btn() and joy2Btn() always use a specific instance of TJoystick which is pretty much hidden from the user. Either hide the instance of TJoystick the way that joy1Btn() and joy2Btn() do for all fields of the TJoystick structure or have all of the functions take a parameter. Doing it half one way and half the other will be confusing and error prone.

Our testing showed that using joy1Btn(btn) and joy2Btn(btn) was well understood by teams. I'd be up for changing it, but we'd have to leave the legacy version in place to avoid breaking teams already developed code. I agree with the inconsistency of the structure, but these are macro/functions and not variables.

Jeff McBride wrote:

5) I'm a little confused about the plan for this year's competition template. For the showcase tournament the competition template worked great. We just needed to provide the Initialization() function and the Autonomous() and HumanControl() tasks. I liked the simplicity that the main() in the template would start and stop the team's tasks as needed so that the team did not have to (and in fact could not) screw up the state transitions. Is there a reason you aren't using the same model now?

To make programming easier for teams, all three software languages switched to a "two-program architecture". By keeping the auto/teleop code separate, you do lose the ability to transfer variables between the programs, but it makes programming much easier for new programmers. The old style template could still be used, but it seems like everyone is promoting the two-program style. I'll try and make something up to illustrate how this works.

Jeff McBride wrote:

6) For this example: while(nMotorRunState[motorD] != runStateIdle){} //wait for motor to become idle //Above Line: Do nothing until motorD gets to the targeted position.Wouldn't it be better practice to insert a small wait into the body of the while to release unneeded CPU cycles for background tasks?

Yes. I'll update this in version 2.

Jeff McBride wrote:

7) I know that the FTC Motor Controller supports additional functionality such as the difference between running at a constant power v/s running at a constant speed. It would be nice to have those differences explained in this guide.

Agreed. This is more of a motors/sensor setup explanation though, which may be a separate guide. The PID capabilities have been simplified to a checkbox under the motors tab.

Jeff McBride wrote:

You might also want to document how to use the HiTechnic Touch Multiplexer. We ended up writing our own accessor functions to interpret the raw sensor values.

A USB game controller will allow you to add remote control capabilities to your robot. RobotC includes a tool that reads the joystick and button settings from one or even two game controllers and packages them up as bluetooth messages for the NXT.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum