Advice from your friendly CSA

[auscompgeek]

Hey all! Congrats again to 5663 for winning at South Pacific.

Just wanted to note down some things I noticed on Sunday somewhere.

So I noticed that 5663 were getting CAN timeouts at some point, potentially pointing at a motor controller failure of some sort. However, this was in teleop, so those messages would also be indicative of waiting for a set acknowledgement in your main control loop, which could potentially make the robot uncontrollable in the event of a CAN bus failure. And indeed…

2018-PowerUp/5663/src/cpp/components/Lift.cpp

Lines 106 to 117 in 605b409

	void Lift::ResetEncoder() {
	motor1->SetSelectedSensorPosition(0, 0, 10);
	}
	// Override MotionMagic and limit switch control in favour of PercentOutput
	void Lift::OverrideLift(bool overridden) {
	encoderOverride = overridden;
	}
	// Run periodic tasks
	void Lift::RunPeriodic() {
	if(lowSwitch->Get() && motor1->GetSelectedSensorVelocity(0) > 0) ResetEncoder();

… which then leads to another thing to note: the Talon SRX is capable of re-zeroing off a limit switch, so it's surprising that you have limit switches that aren't wired to the Talons as limit switches. The SRX mag encoders provide solder pads to wire limit switches to, so getting this working at champs shouldn't be difficult :)

Wiring the switches to the Talons would also provide the benefit of the motors immediately stopping once they hit the limit switch too. Would also be a good improvement for 5333's bot for DDU :)

[JaciBrunning]

Hi David,

The CAN timeouts are normal, since the motors are (as I believe) overallocated. It hasn't proven an issue so far.

As for the limit switches, it's easier for us to wire them directly to DIO than to solder them onto an SRX breakout (we don't use mag encoders).

@NonayMete @swan58 ya'll are free to take a look here.

[auscompgeek]

Hm. From the somewhat brief look at the robot I had, I believe I saw a VersaPlanetary Integrated Encoder? Those are indeed SRX mag encoders.

[JaciBrunning]

The VP integrated encoder is mag, yes, but its quite a ways away from where the 2nd limit switch is mounted

[NonayMete]

Hi, David the CAN timeouts are due to TalonSRX's being allocated but not existing and as Jaci said other 'normal' CTRE behavior. It is a lot less effort for the limit switches just to be wired to the RIO, and especially as we are only really using them for software input, not as a hard stop. Plus we are planning to replace them with IR sensors at some point, and limit switches break often so it was easier just to avoid soldering altogether.

TLDR: I'm too lazy, thanks for the advice though I will make sure to follow it next year.

[auscompgeek]

So the particular CTRE CAN timeout I noticed was a SetSelectedSensorPosition call timing out (during teleop, IIRC).

From a quick search, the only Talons you're zeroing an encoder, with a timeout (as timeouts wouldn't be reported otherwise), are your master drive motors and lift motor. I would presume you aren't allocating those without the corresponding motor controllers existing. These are all happening within the control loop, if I'm reading the code correctly.

CTRE's recommendation is to only have blocking calls (i.e. calls with a timeout) on robot boot, with any calls in the robot loop having no timeout.

Regarding the microswitches though, fair enough.

Good luck at champs!