Sub-Class CANTalon to represent 3 motors

[wazateer1]

Originally Posted by lethc

Why?

I thought the same at first (when I started writing this), and figured I could use super for most of the functions I needed. But I realized as I was writing this that each function that will get called and actually DOES anything needs to be @Overrid and pointed to all three Talons. Unless there is a function in CANTalon that simply IDENTIFIES the CANTalons, that doesn't DO anything that needs to be overridden (eg public String getType() {return "CANTalon"}, it would be simpler. He has a point, there is no reason TO implement CANTalons unless there is said identifying function

Originally Posted by notmattlythgoe

The SpeedController is the base interface for all of the motor controllers. This way you know you are implementing all of the stuff that needs implemented. Really it should just be calling the same method that you're implementing for each of the CANTalons.

CANTalon does implement SpeedController, by extending it my class inherits all the functions, plus the way CANTalons identify themselves

Ultimately, it comes to not having to call the super constructor, and I will go with notmattlythgoe that directly implementing SpeedController is better

[Oromus]

If anyone is looking to group together multiple motors under a single Motor object (i.e. three drivetrain motors under one object like OP's code), I'd like to point to a library of 1902's that has a class called MotorGroup. It works like so:

MotorGroup leftDrive = new MotorGroup(CANTalon.class, 0, 1, 2);
leftDrive.setPower(1);

MotorGroup rightDrive = new MotorGroup(new CANTalon(3), new CANTalon(4));
rightDrive.setPower(-0.5);

MotorGroup is very flexible because it takes any type of Motor and can contain as many motors as you want, so it should help eliminate having to make awkward wrapper classes or mass-call SpeedController.set().

The link to the source file (and the rest of the repo) can be found here.

To get completely back on-topic and to answer the original question, that wrapper class should work fine. My only suggestion would be to not extend CANTalon.

Disclaimer: MotorGroup relies on other parts of the library to exist, so it does not work as-is without changing it not use BCNLib classes.

[euhlmann]

CanTalons have a Follower mode, where set() takes the CAN ID of a talon to constantly copy speed from. That way, you only need to pass 2 "master" talons to RobotDrive and have the rest copy those.

[ozrien]

Originally Posted by euhlmann

CanTalons have a Follower mode, where set() takes the CAN ID of a talon to constantly copy speed from. That way, you only need to pass 2 "master" talons to RobotDrive and have the rest copy those.

+1. Check out section 16.33 in talon srx software reference manual.
http://www.ctr-electronics.com/talon...ical_resources

[wazateer1]

Originally Posted by euhlmann

CanTalons have a Follower mode, where set() takes the CAN ID of a talon to constantly copy speed from. That way, you only need to pass 2 "master" talons to RobotDrive and have the rest copy those.

Would that be more "reliable" then setting them all in code?

[ozrien]

The slave/follower features of the Talon SRX are reliable. Many teams were successful using this feature last season. You can read more about it in the Talon SRX Software Reference manual.

Check out section 16.33 for a specific example of a solution to your OP.
http://www.ctr-electronics.com/talon...ical_resources

[wazateer1]

Originally Posted by Oromus

If anyone is looking to group together multiple motors under a single Motor object (i.e. three drivetrain motors under one object like OP's code), I'd like to point to a library of 1902's that has a class called MotorGroup. It works like so:

MotorGroup leftDrive = new MotorGroup(CANTalon.class, 0, 1, 2);
leftDrive.setPower(1);

MotorGroup rightDrive = new MotorGroup(new CANTalon(3), new CANTalon(4));
rightDrive.setPower(-0.5);

MotorGroup is very flexible because it takes any type of Motor and can contain as many motors as you want, so it should help eliminate having to make awkward wrapper classes or mass-call SpeedController.set().

The link to the source file (and the rest of the repo) can be found here.

To get completely back on-topic and to answer the original question, that wrapper class should work fine. My only suggestion would be to not extend CANTalon.

Disclaimer: MotorGroup relies on other parts of the library to exist, so it does not work as-is without changing it not use BCNLib classes.

The only problem with that is RobotDrive does not know to call .setPower, it only every calls .set() assuming any class that implements SpeedController uses that method

[Oromus]

Originally Posted by wazateer1

The only problem with that is RobotDrive does not know to call .setPower, it only every calls .set() assuming any class that implements SpeedController uses that method

Yup, that's because MotorGroup is part of an overall wrapper/utility library that effectively creates it's own, better versions of WPILib's classes. To get MotorGroup to work with WPI's RobotDrive, you just make it implement SpeedController instead of extending Motor and rename a few functions.