Robot traction system shutting down

[ericomoura]

When we are driving our prototype around it sometimes stops moving. The thing is that the rest of the robot works fine (we're using swerve drive and the wheels still spin just fine and the tote lifting mechanism also continues working). The only thing that stops is what is related to the traction (which is controlled by the RobotDrive class functions).

It shows an error saying that "a timeout has been exceeded", so I searched for that specific error and I found that this could happen when you don't update the motors often enough and that printing too much stuff on the Dashboard could cause this to happen. So I left only one variable showing on the Dashboard (which I assume should be fine) and it still happens sometimes. What else could cause this issue, and how do I deal with that? Attached is a screenshot of the error.

[Alan Anderson]

I am slightly concerned about the picture you showed us. It's saying there's no robot communication at all. Was the robot actually connected at the time?

Originally Posted by ericomoura

What else could cause this issue, and how do I deal with that?

Many things can cause it. The proper solution depends on what the underlying problem is. Start by showing us your program. The motors shut down when you're just driving normally, right? Let's focus on Teleop and Begin for now.

[ericomoura]

No, the robot wasn't on anymore because I forgot about the screnshot. Luckily the error hanged around after that still.

The motors shut down randomly (to me). Sometimes the robot is moving, sometimes it's just standing there enabled, sometimes the error keeps coming back after I reboot the thing, sometimes it goes away. I couldn't really find a pattern. I did notice that it never shut down while moving at "high" speeds, though that could be just luck. Below is the code (I hope I did the formatting correctly). Thanks for the attention!

#include <cstdint>
#include "WPILib.h"

class Robot: public IterativeRobot
{

	RobotDrive myRobot; // robot drive system
	Joystick joystickMain;
	Joystick joystickRotate;
	CANTalon FL;
	CANTalon FR;
	CANTalon RL;
	CANTalon RR;
	CANTalon talonSwerve;
	AnalogInput potSwerve;

	float mov, mainMagRAW, mainMag, potSwerveAngle, WrapMinusPiToPlusPi;
	bool movingForward;

public:
	Robot() :
		myRobot(FL,RL,FR,RR),
		joystickMain(0),
		joystickRotate(1),
		FL(11),
		FR(12),
		RL(14),
		RR(13),
		talonSwerve(15),
		potSwerve(0)

{
		//Drive system setup
		myRobot.SetExpiration(0.1);
		myRobot.SetInvertedMotor(myRobot.kFrontLeftMotor,false);
		myRobot.SetInvertedMotor(myRobot.kFrontRightMotor,true);
		myRobot.SetInvertedMotor(myRobot.kRearLeftMotor,false);
		myRobot.SetInvertedMotor(myRobot.kRearRightMotor,true);

		//Pot setup
		potSwerve.SetOversampleBits(5);
		potSwerve.SetAverageBits(5);


		//Camera Setup
		CameraServer::GetInstance()->SetQuality(50);
		CameraServer::GetInstance()->StartAutomaticCapture("cam0");
}

private:
	void RobotInit()
	{
	}

	void AutonomousInit()
	{
	}

	void AutonomousPeriodic()
	{
	}

	void TeleopInit()
	{
	}


	void TeleopPeriodic()
	{


		//1.430 - 2.624 - 3.828
		potSwerveAngle = (potSwerve.GetAverageVoltage()-2.624) * 71.485;

		//------------JOYSTICK DEADBAND------------//
		mainMagRAW = joystickMain.GetMagnitude();

		if(mainMagRAW >= 0.3)
		{
			mainMag = (mainMagRAW-0.3)/0.7;
		}
		if(mainMagRAW <= -0.3)
		{
			mainMag = (mainMagRAW+0.3)/0.7;
		}
		if(mainMagRAW < 0.3 && mainMagRAW > -0.3)
		{
			mainMag = 0;
		}

		//------------MOVEMENT DIRECTION------------//
		if(joystickMain.GetDirectionDegrees() <= 90.0 && joystickMain.GetDirectionDegrees() >= -90.0){
			WrapMinusPiToPlusPi = joystickMain.GetDirectionDegrees();
			movingForward = true;
		}
		else if(joystickMain.GetDirectionDegrees() > 90.0 && joystickMain.GetDirectionDegrees() <= 180.0){
			WrapMinusPiToPlusPi = joystickMain.GetDirectionDegrees() - 180.0;
			movingForward = false;
		}
		else if(joystickMain.GetDirectionDegrees() < -90.0 && joystickMain.GetDirectionDegrees() > -180.0){
			WrapMinusPiToPlusPi = joystickMain.GetDirectionDegrees() + 180.0;
			movingForward = false;
		}

		if(WrapMinusPiToPlusPi < 70.0 && WrapMinusPiToPlusPi > -70.0 ){
			if(mainMag > 0.08 && potSwerve.GetAverageVoltage() >= 1.430 && potSwerve.GetAverageVoltage() <= 3.828){
				talonSwerve.Set(-1.0 * (potSwerveAngle - WrapMinusPiToPlusPi)/90.0);
			}
			else{
				if(potSwerve.GetAverageVoltage() < 1.430){
					talonSwerve.Set(0.5);
				}
				else if(potSwerve.GetAverageVoltage() > 3.828){
					talonSwerve.Set(-0.5);
				}
				else{
					talonSwerve.Set(0);
				}
			}

			if(movingForward)
			{
				mov = mainMag;
			}
			else
			{
				mov = mainMag*-1.0;
			}
		}
		else if(joystickMain.GetDirectionDegrees() >  -110.0 && joystickMain.GetDirectionDegrees() < -70.0){
			talonSwerve.Set(-1.0 * (potSwerveAngle + 95.0)/95.0);
			mov = mainMag;
		}
		else if(joystickMain.GetDirectionDegrees() > 70.0 && joystickMain.GetDirectionDegrees() < 110.0){
			talonSwerve.Set(-1.0 * (potSwerveAngle - 95.0)/95.0);
			mov = mainMag;
		}

		myRobot.MecanumDrive_Cartesian(0,mov,(joystickRotate.GetX()*-1.0));
	}

	void TestPeriodic()
	{
	}
};

START_ROBOT_CLASS(Robot);

[Alan Anderson]

I have two questions.

1) Have you tried debugging the code to make sure that mov is what you expect when you call the MecanumDrive_Cartesian() function?

2) Why are you calling MecanumDrive_Cartesian()? You don't have a mecanum (or 45-degree omniwheel) drivebase. Since you're passing a constant 0 as the first argument, it seems to me that it would be more reasonable to call an ArcadeDrive function.

[ozrien]

I'm kinda surprised your getting driverstation motor safety errors. I don't see a single SetSafetyEnabled(true) in your code. Maybe they are elsewhere?

Good suggestions from Alan, periodically printf-ing mov could reveal the problem.

[Joe Ross]

Originally Posted by ericomoura

What else could cause this issue, and how do I deal with that? Attached is a screenshot of the error.

wireless latency can cause your code to not run often enough. You can see this on the charts tab of the driver station or in the driver station log viewer.

Originally Posted by ozrien

I'm kinda surprised your getting driverstation motor safety errors. I don't see a single SetSafetyEnabled(true) in your code. Maybe they are elsewhere?

RobotDrive enables MotorSafety automatically.

[Ether]

Originally Posted by Joe Ross

wireless latency can cause your code to not run often enough.

@ericomoura: what kind of computer are you using for the DS?

[ozrien]

RobotDrive enables MotorSafety automatically.

Ah your right! Right in RobotDrive::InitRobotDrive().

ericomoura, maybe called RobotDrive::SetSafetyEnabled(false) to see if it affects the robot behavior (only if your NOT leveraging breakpoint-style-debugging). If motor-safety is a red-herring, at least it will remove the DS symptom. But you have a debugger attached, never mind, it's important the motors stop when your breakpoints hit!

[ericomoura]

Originally Posted by Ether

@ericomoura: what kind of computer are you using for the DS?

We use an Asus laptop running Windows 64-bit version.

Originally Posted by Alan Anderson

I have two questions.

1) Have you tried debugging the code to make sure that mov is what you expect when you call the MecanumDrive_Cartesian() function?

2) Why are you calling MecanumDrive_Cartesian()? You don't have a mecanum (or 45-degree omniwheel) drivebase. Since you're passing a constant 0 as the first argument, it seems to me that it would be more reasonable to call an ArcadeDrive function.

1) Yes, mov is behaving as I expected.

2) Just as I posted I realized how stupid that was and changed it to ArcadeDrive immediately. For some reason I didn't see it when I wrote this... It must've been late. Anyways, the issue is still there, no changes.


I also wanted to add that I recently tried deploying a default Arcade Drive example from the Eclipse examples and the error did still show up, which makes me think that the code might not be the only problem. Besides that, we bought an analog breakout for the Talon SRX, so we'll be using the closed-loop functions, which means a great part of that code (the hand-made P kind of thing) will go away. I'm hoping the problem is in there so it will magically vanish.

[bob.wolff68]

Have you done the firmware update/check for the Talon and the PDP? I don't know that those updates address your particular issues, but it is suspicious that you went to a default sample and still encountered intermittent problems. Another thought would be replacing your PWM cables to see if there are connectivity issues. Ooh - one last thought - looking at the logs to see if you are having any other power issues as the roboRIO does have a procedure during brownout whereby it shuts down certain operations, ports, etc.

bob

[ericomoura]

All of our Talons are on the latest firmware as well as the PDP (the 1.4 version). Regarding the PWM cables, the Talons are all wired via CAN. The only PWM cable we have currently, is a light sensor which we're testing with and it has nothing to do with the traction of the robot (they're there so we know when we grabbed a tote successfully).

As for the logs, I never really used them so I'm not sure what I should be looking for. I'll definitely see what I can get from there, even though I don't have the robot available right now.

I don't think it's a power issue, since we have nothing else other than the traction and one more motor which is pretty much always idle. Even with a fully charged battery we still have the same problem. I will pay more attention to see if it happens more frequently when the battery is low or something similar.

Thanks for the help anyways.

[bob.wolff68]

I gotta say I'm surprised about no PWM cables to the Talons. I may be incorrect here, but I thought the CAN connection was ONLY for CAN/telemetry data and NOT for control. I thought the PWM cables were still required. Can someone validate this?

As for logs and graphs - please do look into it. I think it's wise to do ahead of competition anyway so that you have experience and a mental baseline for what these things should look like. The graphs that are real-time this year are quite informative - more so than prior years for sure. And the logs are chock full of data as well.

bob

[Ether]

Originally Posted by bob.wolff68

I gotta say I'm surprised about no PWM cables to the Talons. I may be incorrect here, but I thought the CAN connection was ONLY for CAN/telemetry data and NOT for control. I thought the PWM cables were still required. Can someone validate this?

TalonSRX Software Reference Manual:
http://crosstheroadelectronics.com/T...e%20Manual.pdf

... or if you're asking if it's legal to use CAN for control, see R59.

[ozrien]

ericomoura, did disabling the motor-safety enable remove the symptom of the motor-safety error in your DS and unexplained motor-stopping? Be sure to clear the log in the DS before each test run.

If the DS is reporting motor safety, then a motor controller is absolutely being set to zero throttle. In fact the mode will read "No Drive" in the roboRIO web-based config Self Test. (see section 19 in Talon SRX software reference manual).

[Phiction]

My team is getting the same error. Our C++ code looks pretty much the exact same as what OP has. We have 4 Can Talons connected through the Can Bus. Using mecanum drive, and Using the Sample Robot. Randomly our drive system won't work. It happens after deploying. Sometimes after we enable & disable. If we switch from teleop to Auto, and when it happens, switching modes will not fix the issue. It also just sometimes randomly stops working. We get input from the joysticks, but since the robot is Enabling saftey for some reason. It will not drive.

We have thought about switching the Talons to PWM, but since we have seen it run flawless before on the CAN bus. We would like to try to solve the issue.

OP if you have solved this issue, can you please post how you fixed it. If anyone has any other information on this issue. Dont hesitate to PM me, or post here. Thanks!