Roborio issues??

[2B || !2B]

It turns out that for some reason I do not understand, the ArcadeDrive class of RobotDrive does not work at all in java. Is anyone else having this problem? I am sure it is not the code, because I compared it to WPI tutorials, API, and numerous other examples.

Any suggestions?

[alopex_rex]

You'll probably have to provide some more specific information before we can do much with this. "Does not work" is pretty vague, and not very useful to anyone who can't see you code or test your robot.

My advice is always to break things down into the smallest steps. First try making a RobotDrive object and not doing anything with it, and see if it compiles. Next test your motor controllers directly, to make sure it's not an electrical issue. Next try using the arcade drive function, using constants for the inputs, not joystick input. Go on like this, and once you find something that doesn't work you'll have an idea where your problem lies.

[2B || !2B]

Sorry about the vague description, but we actually isolated the RobotDrive class as the issue, because we can drive the motors directly, and everything else checks out OK. I was more interested in whether or not anyone else has this problem because we were so shocked that arguably the most important class in all of the WPI libraries does not work correctly.

[alopex_rex]

Originally Posted by 2B || !2B

we were so shocked that arguably the most important class in all of the WPI libraries does not work correctly.

Good rule of thumb here: All else being equal, it is far more likely that there is a problem on your end, rather than that you are the only one who noticed a major problem in a widely used library.

This would be as good a time as any to mention I don't actually program in Java for FRC. But, if you can provide some more information about your issue, I'm sure someone around here will be able to help out. To start, what is happening? (or not happening?) When you try to drive, does nothing happen, or does it drive wrong somehow? What code are you using? Is it only the ArcadeDrive function that's giving you trouble, or does none of the class work? If the motor controllers work otherwise, the simplest explanation would be that you somehow initialized the object wrong, although it sounds like you're pretty sure it's not a code issue. I've made plenty of embarrassing mistakes though, never hurts to check again.

[2B || !2B]

I did not work on this project myself, I am just baffled that RobotDrive doesn't work. A mentor and a new student worked on some basic java code to make some motors move with joystick input. The report was that the code does not move the motors at all with ArcadeDrive. He also mentioned that they did get the same test robot to work with TankDrive (in the same class).

I can't provide code because the student who worked on it deleted it after be decided that it was busted. It sounds like it's not a FIRST issue, so I will investigate this further tonight.

[Pratik Kunapuli]

To properly debug the code, try to use System.println() statements and determine where the issue is. It could be that the joysticks aren't in the default port number and the println will tell you that the joystick isn't responding how you expect it to. Remember that with the RoboRIO the port numbers are 0 based indexed, so the first port number is 0 rather than 1, which it previously used to be.

[2B || !2B]

It turns out that robot drive only works with PWM. No CAN support for driving as of yet.

[alopex_rex]

Really? RobotDrive has constructors that take SpeedController objects, which includes CAN motor controllers. You should be able to declare CAN<whatever> variables for each of your motor controllers and then initialize a RobotDrive using those. Now, if you use the constructor with channel numbers as arguments [new RobotDrive(1, 2, 3, 4)], it'll assume you're trying to use PWM talons, and won't work otherwise. That's probably the problem you guys had.

[AubreyA]

I just found a solution to a similar problem today. If you are in fact using CAN and have declared the RobotDrive using new RobotDrive(new CANJaguar(id), etc...) as alopex_rex discussed then this should work.

We discovered that in the wpilibj RobotDrive class there is a member variable m_isCANInitialized which is set to false at construction. (There is a comment by this declaration, "TODO: fix can", which worries me.) This is the variable which controls whether the CAN motor controllers get updated. When true, RobotDrive will call CANJaguar.updateSyncGroup(syncGroup) for the sync group (byte)0x80. (This is the sync group which the class sets for all motor controllers.) However this never gets set to true which is where the problem arises.

We found two possible solutions to this issue. You could extend the RobotDrive class and set m_isCANInitialized to true at construction which would update the sync group indirectly. The other option is to call CANJaguar.updateSyncGroup(syncGroup) after every time you set your drive motors.

[Joey1939]

Originally Posted by alopex_rex

Really? RobotDrive has constructors that take SpeedController objects, which includes CAN motor controllers. You should be able to declare CAN<whatever> variables for each of your motor controllers and then initialize a RobotDrive using those. Now, if you use the constructor with channel numbers as arguments [new RobotDrive(1, 2, 3, 4)], it'll assume you're trying to use PWM talons, and won't work otherwise. That's probably the problem you guys had.

This is correct. Anything that extends SpeedController (Talons, Victors, Jaguars, CANTalons, etc.) will all work. Make sure if you are using CAN to give the the SpeedController objects instead of just the ports because it will assume you mean PWM.

I have been using TalonSRX's over CAN without problem.