CANTalon enabling problem

Technical Java
1

Hi

I am an experienced programmer, but a newbie to FRC. Apologize if this is a silly question. We are using Java, with WPILibJ.

We have just built a prototype robot with 6 talons, three per side driving a single shaft.

I used the IE web user interface to set the IDs for each talon and run a self test on them - all worked fine. I can blink the light of each talon to ensure I have the IDs correct (checked many times).

I set up a drivetrain class extending SubSystem that encapsulated the creation of the talons, a RobotDrive class for driving, then a Command that called the tankDrive() on the RobotDrive.

The problem is that only one of the talons would enable when the drive station is switched to Teleop mode. Web UI self test on the other talons would still work, but show them as not enabled, and their lights would stay flashing orange.

After considerable messing about, I found that if I create CANTalon objects as member variables of the base Robot class and initialize them with the declaration, they all get enabled correctly. Trying to create them as member variables of the SubSystem class, and they do not enable, but I can create them again in SubSystem

While we now have it working, this seems very clumsy to me and makes me wonder if I have either completely mis-understood how the SubSystem class is supposed to work, or if there is a fundamental issue with setting up talons in classes other than the base robot class.

Clearly initializing them as member variables of the Robot class means they get created as soon as the Robot class is instantiated (even before its constructor is called).

I had a look at the source code for the RobotBase class in WPILibJ:


and it looks like there is very little code executed after the Robot class is instantiated before control is handed of to the main scheduling loop.

Is that going to be necessary for other Talons and anything else we have on the CAN bus going forward?

Regards

David

2

AFAIK, all objects should be initialized in the robotInit method. I have not worked with CANTalon objects specifically but this has worked for everything else.

In the Command based robot structure, all physical components (motor controllers, sensors, pneumatics, etc.) should be declared and initialized in a RobotMap class. This makes it very easy to find duplicate declarations, which is important because you can’t declare two objects on the same port / ID.

If you can post your code to Github or a similar site, we would be able to look over it for anything you could be doing wrong. It’s often easier to read the code than someone’s description of what the code is doing.

3

Thank you.

I will set up initialization in a RobotMap class and see if that works, and let you know.

4

Instantiating motor controllers within subsystems is pretty common and should work fine. I prefer the encapsulation of doing it that way, and uniqueness can be pretty easy to verify by configuring the port IDs within RobotMap.

Please post the code that wasn’t working when you get a chance

5

I found this thread that recommends encapsulating in the SubSystem, and that is certainly my preference.

Do you create the objects in the class constructor, or as static member variables?

About to try both and will then post

6

True confession time, in case anybody else finds this thread.

I had set the drive train class up as a singleton, using:

    private static DriveTrain2018 mInstance;
    public static DriveTrain2018 getInstance() {
        if (mInstance == null) {
            mInstance = new DriveTrain2018();
        }
        return mInstance;
    }

Unfortunately, at some point the member variable was initialized like this:

private static DriveTrain2018 mInstance = new DriveTrain2018();

This means that the constructor was called when the class was being initialized by the JVM, before other member variables were set up. The result was very confusing as changes in the order of variable declarations, declaring in other classes, etc produced different and random results.

In short - do not do this.

Thanks to everybody who offered suggestions.

7

Thanks for posting! Glad you found the problem.