kauailabs / allwpilib

Fork of Official Repository of WPILibJ and WPILibC, which contain in addition a HAL for the KauaiLabs VMX-pi.
Other
1 stars 3 forks source link

CAN Talon SRXs always disabled even when using Kauai Labs-provided example Java code. #12

Closed cecilialau6776 closed 5 years ago

cecilialau6776 commented 5 years ago

Trying to run a motor connected to a TalonSRX gives me these errors in driver station:

  (VMXCAN.cpp [317]) 
 Mon Jul 15 13:38:32 2019 - INFO :  VMX HAL:  Cleared CAN HW Receive Overflow.   
  (VMXCAN.cpp [426]) `

Here are the relevant parts of my code:

public void robotInit() {
    c = new ArrayList<TalonSRX>();
    for (int i = 0; i < 40; i++) {
      c.add(new TalonSRX(i));
    }
  }
public void teleopPeriodic() {
    UnmanagedJNI.JNI_FeedEnable(100); // Enable Phoenix CAN Devices for 100 Milliseconds, needed for VMX-PI CAN devices to function
    for (int i = 0; i < c.size(); i++) {
      c.get(i).set(ControlMode.PercentOutput, .25);
    }
  }

I've successfully controlled a PWM motor, though (Talon SR).

Additionally, I cannot check firmware or ID of any talon connected to the VMX-pi, since I can't install a Pheonix Diagnostics Server on the VMX-pi. If there's any other solution, I'd like to know.

kauailabs commented 5 years ago

A couple of questions on this:

1) Do you actually have 40 CAN Talons (that's how many are being added in the roboInit()? How many CAN Talons are actually physically connected to the CAN bus?

We have only tested a typical number (4) of talons, so I'd like to make sure I understand what you're trying to do.

2) Do any of the Talons operate as expected (e.g., do the LEDs flash Green or Red, indicating they are outputting voltage to the motors they are connected to?

Even if the HW receive overflow occurs, I expect that communication should still continue. How does everything behave before the overflow? And how does everything behave after the overflow condition has been resolved?

--

NOTE: On the firmware check, you currently must use Phoenix tuner on a RoboRIO to check the firmware status.

cecilialau6776 commented 5 years ago

I don't actually have 40 talons; I was adding 40 because I didn't know the talon ID. I only physically have one talon connected. I'm not sure if the talon's LED flashes the correct color, but the motor it's connected to wasn't turning.

The HW overflow seems to always be occurring; there is no behavior before or after.

kauailabs commented 5 years ago

Using the release from two weeks ago, we're able to get Talons working.

As to the H/W overflow, we'll look into it further here. It's very possible that if every teleop periodic (every 20 milliseconds) 40 talons are being commanded that the CAN bus is getting very busy (the bus is being used even if the talon isn't there, and the VMX-pi receives every single packet on the bus. My hunch is the overflow condition is in part triggered by trying to control 40 talons simultaneously.

However, except for the moments after the H/W overflow starts until when the H/W overflow is cleared, the talon communication should proceed normally.

cecilialau6776 commented 5 years ago

I have 8 talons connected now, and I'm trying to control one. However, all of the talons' leds are still flashing orange. Could you send me your working code?

kauailabs commented 5 years ago

Attached to this comment is the code that's working. Two notes:

1) This code only tests 1 talon. We're looking into the CAN RX Overflow; it appears with the current firmware, when that happens and talon communication is underway, no further CAN communication occurs. We're working on firmware fix to recover from this condition, but until then you're encouraged to try to replicate the functionality in the code below.

2) Just in case, I'm Not sure if you have the talons connected to motors or not, but the motor controllers don't always blink the LEDs GREEN or RED if motors aren't actually connected, and the talon isn't receiving input power.

Here's the code that works w/a CAN talon.

/----------------------------------------------------------------------------/ / Copyright (c) 2017-2018 FIRST. All Rights Reserved. / / Open Source Software - may be modified and shared by FRC teams. The code / / must be accompanied by the FIRST BSD license file in the root directory of / / the project. / /----------------------------------------------------------------------------/

include <frc/IterativeRobot.h>

include <frc/Timer.h>

include <ctre/phoenix/motorcontrol/can/WPI_TalonSRX.h>

include <ctre/phoenix/cci/Unmanaged_CCI.h>

using namespace frc; using namespace ctre::phoenix::motorcontrol::can;

class Robot : public IterativeRobot { public: Robot() { }

void AutonomousInit() override {
}

void AutonomousPeriodic() override {
    Wait(0.02);
}

void TeleopInit() override {
    talonSRX.ClearStickyFaults();   // This doesn't appear to be necessary, but it can help in certain conditions
}

void TeleopPeriodic() override {
    talonSRX.Feed();
    c_FeedEnable(100);  // Needed to enable the motors for 100ms (in systems w/out the FRC reference implementation).

    ctre::phoenix::ErrorCode errcode = talonSRX.GetLastError();
    std::string srx_name = talonSRX.GetName();
    if (errcode != ctre::phoenix::ErrorCode::OK) {
        wpi::outs() << "TalonSRX " << srx_name << " Error Code:  " << errcode << "\n";
    }

    bool is_alive = talonSRX.IsAlive();

    double new_talon_srx_output = count % 100;
    new_talon_srx_output /= 100;
    new_talon_srx_output *= 2;
    new_talon_srx_output -= 1;

    new_talon_srx_output *= .25;

    double bus_voltage = talonSRX.GetBusVoltage();
    double temp = talonSRX.GetTemperature();
    int firmware_version = talonSRX.GetFirmwareVersion();
    double motor_output_percent = talonSRX.GetMotorOutputPercent();
    double motor_output_voltage = talonSRX.GetMotorOutputVoltage();

    /**
     * @return applied voltage to motor  in volts.
     */
    talonSRX.Set(new_talon_srx_output);

    double talon_srx_output = talonSRX.Get();

    wpi::outs() << "TalonSRX " << srx_name <<
            " " << (is_alive ? "Alive" : "Not Alive") <<
            "Firmware:  " << firmware_version <<
            " - Output:  " << talon_srx_output <<
            " - Requested Output:  " << new_talon_srx_output <<
            " - Bus Voltage:  " << bus_voltage <<
            " - Motor Output V:  " << motor_output_voltage <<
            " - Motor Output %:  " << motor_output_percent <<
            " - Temperature:  " << temp << "\n";

    count++;
    Wait(0.005);
}

void TestPeriodic() override {}

private: WPI_TalonSRX talonSRX{2}; // Talon at ID 2 int count{0}; };

START_ROBOT_CLASS(Robot)

**

cecilialau6776 commented 5 years ago

Our team writes in Java, so could you provide some working Java code? If not, I'll make a new project to test this next Tuesday, and see if I can make it work in Java.

kauailabs commented 5 years ago

We have a new firmware update (v. 3.0.409) which has much improved performance, and has recovery from the CAN HW Receive Overflow condition; please update your VMX-pi firmware to this version and let us know if your results are as good as ours.

kauailabs commented 5 years ago

If you still need java code, I've attached to this what was tested working on our side (after fixing Phoenix-vmx.json):

/----------------------------------------------------------------------------/ / Copyright (c) 2017-2018 FIRST. All Rights Reserved. / / Open Source Software - may be modified and shared by FRC teams. The code / / must be accompanied by the FIRST BSD license file in the root directory of / / the project. / /----------------------------------------------------------------------------/

include "Robot.h"

include

include <frc/smartdashboard/SmartDashboard.h>

void Robot::RobotInit() { m_chooser.SetDefaultOption(kAutoNameDefault, kAutoNameDefault); m_chooser.AddOption(kAutoNameCustom, kAutoNameCustom); frc::SmartDashboard::PutData("Auto Modes", &m_chooser); }

/**

/**

void Robot::AutonomousPeriodic() { if (m_autoSelected == kAutoNameCustom) { // Custom Auto goes here } else { // Default Auto goes here } }

void Robot::TeleopInit() {}

void Robot::TeleopPeriodic() { talonSRX.Feed(); c_FeedEnable(100); // Needed to enable the motors for 100ms (in systeetms w/out the FRC Reference implementation) ctre::phoenix::ErrorCode errcode = talonSRX.GetLastError(); std::string srx_name = talonSRX.GetName(); if (errcode != ctre::phoenix::ErrorCode::OK) { wpi::outs() << "Talon SRX " << srx_name << " Error Code: " << errcode << "\n"; } bool is_alive = talonSRX.IsAlive(); double new_talon_srx_output = count % 100; new_talon_srx_output /= 100; new_talon_srx_output = 2; new_talon_srx_output -= 1; new_talon_srx_output = .15;

double bus_voltage = talonSRX.GetBusVoltage(); double temp = talonSRX.GetTemperature(); int firmware_version = talonSRX.GetFirmwareVersion(); double motor_output_percent = talonSRX.GetMotorOutputPercent(); double motor_output_voltage = talonSRX.GetMotorOutputVoltage(); talonSRX.Set(new_talon_srx_output);

wpi::outs() << "TalonSRX " << srx_name << " " << (is_alive ? "Alive " : "Not Alive ") << "Firmware: " << firmware_version << " - Requested Output: " << new_talon_srx_output << " - Bus Voltage: " << bus_voltage << " - Motor Output V: " << motor_output_voltage << " - Motor Output %: " << motor_output_percent << "\n";

count++; }

void Robot::TestPeriodic() {}

ifndef RUNNING_FRC_TESTS

int main() { return frc::StartRobot(); }

endif

cecilialau6776 commented 5 years ago

This appears to be C++... Am I missing something here?

Additionally, here is my Java code for a single talon on a timed robot that doesn't seem to work:

/*----------------------------------------------------------------------------*/
/* Copyright (c) 2017-2018 FIRST. All Rights Reserved.                        */
/* Open Source Software - may be modified and shared by FRC teams. The code   */
/* must be accompanied by the FIRST BSD license file in the root directory of */
/* the project.                                                               */
/*----------------------------------------------------------------------------*/

package frc.robot;

import edu.wpi.first.wpilibj.Joystick;
import edu.wpi.first.wpilibj.TimedRobot;
import edu.wpi.first.wpilibj.smartdashboard.SendableChooser;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;
import frc.robot.components.Globals;

import com.ctre.phoenix.motorcontrol.ControlMode;
import com.ctre.phoenix.motorcontrol.can.TalonSRX;
import com.ctre.phoenix.unmanaged.UnmanagedJNI; 

/**
 * The VM is configured to automatically run this class, and to call the
 * functions corresponding to each mode, as described in the TimedRobot
 * documentation. If you change the name of this class or the package after
 * creating this project, you must also update the build.gradle file in the
 * project.
 */
public class Robot extends TimedRobot {
  private static final String kDefaultAuto = "Default";
  private static final String kCustomAuto = "My Auto";
  private String m_autoSelected;
  private final SendableChooser<String> m_chooser = new SendableChooser<>();
  TalonSRX t;
  Joystick joy;

  /**
   * This function is run when the robot is first started up and should be
   * used for any initialization code.
   */
  @Override
  public void robotInit() {
    m_chooser.setDefaultOption("Default Auto", kDefaultAuto);
    m_chooser.addOption("My Auto", kCustomAuto);
    SmartDashboard.putData("Auto choices", m_chooser);
    //Globals.init();
    t = new TalonSRX(32);
    //joy = new Joystick(4);
  }

  /**
   * This function is called every robot packet, no matter the mode. Use
   * this for items like diagnostics that you want ran during disabled,
   * autonomous, teleoperated and test.
   *
   * <p>This runs after the mode specific periodic functions, but before
   * LiveWindow and SmartDashboard integrated updating.
   */
  @Override
  public void robotPeriodic() {
  }

  /**
   * This autonomous (along with the chooser code above) shows how to select
   * between different autonomous modes using the dashboard. The sendable
   * chooser code works with the Java SmartDashboard. If you prefer the
   * LabVIEW Dashboard, remove all of the chooser code and uncomment the
   * getString line to get the auto name from the text box below the Gyro
   *
   * <p>You can add additional auto modes by adding additional comparisons to
   * the switch structure below with additional strings. If using the
   * SendableChooser make sure to add them to the chooser code above as well.
   */
  @Override
  public void autonomousInit() {
    m_autoSelected = m_chooser.getSelected();
    // m_autoSelected = SmartDashboard.getString("Auto Selector", kDefaultAuto);
    System.out.println("Auto selected: " + m_autoSelected);
  }

  /**
   * This function is called periodically during autonomous.
   */
  @Override
  public void autonomousPeriodic() {
    UnmanagedJNI.JNI_FeedEnable(100); // Enable Phoenix CAN Devices for 100 Milliseconds, needed for VMX-PI CAN devices to function
    switch (m_autoSelected) {
      case kCustomAuto:
        // Put custom auto code here
        break;
      case kDefaultAuto:
      default:
        // Put default auto code here
        break;
    }
  }

  /**
   * This function is called periodically during operator control.
   */
  @Override
  public void teleopPeriodic() {
    UnmanagedJNI.JNI_FeedEnable(100); // Enable Phoenix CAN Devices for 100 Milliseconds, needed for VMX-PI CAN devices to function
    t.set(ControlMode.PercentOutput, 0.25);
    System.out.println(t.getLastError());
    //Globals.tick();
  }

  /**
   * This function is called periodically during test mode.
   */
  @Override
  public void testPeriodic() {
  }
}
kauailabs commented 5 years ago

Here's the Java program we used to verify this using the latest Phoenix-vmx.json:

/----------------------------------------------------------------------------/ / Copyright (c) 2017-2018 FIRST. All Rights Reserved. / / Open Source Software - may be modified and shared by FRC teams. The code / / must be accompanied by the FIRST BSD license file in the root directory of / / the project. / /----------------------------------------------------------------------------/

package frc.robot;

import edu.wpi.first.wpilibj.TimedRobot; import edu.wpi.first.wpilibj.smartdashboard.SendableChooser; import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;

import com.ctre.phoenix.ErrorCode; import com.ctre.phoenix.motorcontrol.can.WPI_TalonSRX; import com.ctre.phoenix.unmanaged.UnmanagedJNI;

/**

cecilialau6776 commented 5 years ago

This doesn't work for me. I've made sure that both my motor and talon work (and I've set the correct talon ID). The VMX-PI firmware version is 3.0.410 (Is this the latest?). I have the VMX-PI on the CAN bus, along with a talon and a CTRE PDP as the other termination point. I've also updated the custom GradleRIO to the latest version.

kauailabs commented 5 years ago

What version of firmware are you using? We have multiple teams working with TalonSrx-Application-4.22-season2019.crf

I'm also assuming you've updated to the latest, greatest Phoenix-vmx.json file

Using the Java program supplied, what kind of output messages do you see? If we could see the output from the java test program we sent (a driver station log would be good), I'm hopeful we can figure out what's happening.

cecilialau6776 commented 5 years ago

Phoenix Tuner says that the talon firmware version is 4.22, but I'll try updating it. EDIT: Nothing has changed after updating the talon firmware.

Output messages from driver station:


 TalonSRX Talon SRX [32] - Requested Output: 0.01 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.01 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.01 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.02 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.02 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.02 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.02 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.03 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.03 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.03 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.04 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.04 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.04 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.05 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.05 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.05 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.05 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.06 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.06 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.06 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.07 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.07 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.07 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.08 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.08 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.08 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.08 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.09 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.09 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.09 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.10 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.10 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.10 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.11 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.11 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.11 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.11 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.12 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.12 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.12 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.13 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.13 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.13 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.13 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.14 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.14 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00 
 TalonSRX Talon SRX [32] - Requested Output: 0.14 - Bus Voltage: 12.90 - Motor Output V: 0.00 - Motor Output %: 0.00```
kauailabs commented 5 years ago

Earlier in the log, when the application started, do you see anything printing out the Talon firmware version number? This will confirm that basic CAN communication with the TalonSRX.

kauailabs commented 5 years ago

One other question - is the RoboRIO also connected to the CAN network while attempting to control it from VMX-pi? If so, the RoboRIO (if it is not enabled) will actively disable the TalonSRX. So if you haven't already, ensure that RoboRIO is not turn on when controlling TalonSRX from VMX-pi.

cecilialau6776 commented 5 years ago

The RoboRIO is completely disconnected

On Wed, Aug 21, 2019, 02:27 Kauai Labs notifications@github.com wrote:

One other question - is the RoboRIO also connected to the CAN network while attempting to control it from VMX-pi? If so, the RoboRIO (if it is not enabled) will actively disable the TalonSRX. So if you haven't already, ensure that RoboRIO is not turn on when controlling TalonSRX from VMX-pi.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kauailabs/allwpilib/issues/12?email_source=notifications&email_token=ALFM74X5L4ZKWEGOX7WLLZTQFTN6XA5CNFSM4IIBCPEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YSYAA#issuecomment-523316224, or mute the thread https://github.com/notifications/unsubscribe-auth/ALFM74SSOKMONNAUALBSNUDQFTN6XANCNFSM4IIBCPEA .

kauailabs commented 5 years ago

Can you post a complete driverstation log? I’d like to see what this code is printing out during unit:

if (alive) { System.out.println("TalonSRX (CAN Device 2) has firmware " + String.valueOf(firmware_version)); }

And I’d like to see if there are any other errors, warnings or other clues that help identify the root cause of the problem.

kauailabs commented 5 years ago

Per the TalonSRX User's Guide, blinking off/orange indicates the TalonSRX thinks it's disabled. The Phoenix libraries periodically feed the motor controller via:

UnmanagedJNI.JNI_FeedEnable(100); // Enable Phoenix CAN Devices for 100 Milliseconds

And the WPI Library class that manages the TalonSRX also has a "motor safety" mechanism (which might disable motor controller usage), which is fed periodically via:

talon.feed(); // Feed the talon motor safety object.

Both of these are in the teleop periodic code posted on this issue, so it seems that part's covered. So I'm trying to come up with a plausible theory what else could be disabling the TalonSRX motor controllers.

Do you know if it's possible that some persistent configuration information is still stored in the TalonSRX flash memory? If so, it could make sense to clear this via the Phoenix Tuner, so that defaults are used for all settings.

Also, is it possible there are "sticky faults" that might be latched into the TalonSRX? This code in teleopInit() ~should~ be clearing that:

talon.clearStickyFaults();

But maybe there's a problem in this area - if so Phoenix tuner would provide information about that.

kauailabs commented 5 years ago

Thought of one other piece of data that might help debug the CAN issue.

When the talons are in the disabled state, could you let me know what's happening in the driver station on the "CAN Status" section? Are we getting lots of CAN RX/TX errors (this could occur if there was an intermittent wiring issue), or are we getting any overflows?

There's also a green LED on the VMX-pi board, it should be lit during this time.

cecilialau6776 commented 5 years ago

It prints out that the talon has firmware 1046. The light between the CAN IO and termination toggle on the VMX is a solid green.

cecilialau6776 commented 5 years ago

Would it be possible that there's an issue with my pi image?

cecilialau6776 commented 5 years ago

Every value under CAN Metrics is 0, and I get this error in the console after running the program for a while: ERROR: (-20018) VMXCAN::RepeatingPacketThreadFunc() - error sending message for ID 0x02040081

kauailabs commented 5 years ago

I think we may have found a key problem, it has to do with the TimedRobot. If you change your code to inherit from IterativeRobot rather than TimedRobot, I'm wondering if this will work.

I don't think it's a pi image problem; the fact that the Talon firmware is acquire means CAN bus communication is occurring. If the hypothesis about the TimedRobot is correct, then what's happening is your teleop periodic function is no longer getting called, at which point the Talons disable themselves (they get fed from the periodic function). The drive station indicates it's still enabled (because the thread communicating w/the drive station continues running. I believe if IterativeRobot is used, this issue won't occur.

As far as CAN metrics, all the metrics are implemented except the CAN bus utilization %. The CAN "Bus Off", "Transmit" and "Receive" counts are actually "error counts", so they should be 0. If you disconnect the CAN wires from the VMX-pi, the green led should go off - and at that point when your program is running you should see "TX Full" counts going positive - because the transmit buffer fills up because it can't send the CAN packets.

Please let me know if Iterative Robot helps your situation; we've been able to reproduce something like what you are seeing sporadically when using TimedRobot.

cecilialau6776 commented 5 years ago

I've tried an iterative robot before, but I'll try again. I've moved the code that prints out the firmware version to teleopPeriodic, so I'm sure it's being called.

On Tue, Aug 27, 2019, 19:40 Kauai Labs notifications@github.com wrote:

I think we may have found a key problem, it has to do with the TimedRobot. If you change your code to inherit from IterativeRobot rather than TimedRobot, I'm wondering if this will work.

I don't think it's a pi image problem; the fact that the Talon firmware is acquire means CAN bus communication is occurring. If the hypothesis about the TimedRobot is correct, then what's happening is your teleop periodic function is no longer getting called, at which point the Talons disable themselves (they get fed from the periodic function). The drive station indicates it's still enabled (because the thread communicating w/the drive station continues running. I believe if IterativeRobot is used, this issue won't occur.

As far as CAN metrics, all the metrics are implemented except the CAN bus utilization %. The CAN "Bus Off", "Transmit" and "Receive" counts are actually "error counts", so they should be 0. If you disconnect the CAN wires from the VMX-pi, the green led should go off - and at that point when your program is running you should see "TX Full" counts going positive - because the transmit buffer fills up because it can't send the CAN packets.

Please let me know if Iterative Robot helps your situation; we've been able to reproduce something like what you are seeing sporadically when using TimedRobot.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kauailabs/allwpilib/issues/12?email_source=notifications&email_token=ALFM74QYH6NNEQX5PK7JT2DQGW3QRA5CNFSM4IIBCPEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5JN4BA#issuecomment-525524484, or mute the thread https://github.com/notifications/unsubscribe-auth/ALFM74QVSKJ6NDLWWFFCGP3QGW3QRANCNFSM4IIBCPEA .

kauailabs commented 5 years ago

The name of this issue has been renamed, to better reflect the current discussions on the topic.

The CAN HW Receive Overflow recovery code is available in VMX-pi firmware 3.1.403 or later.

It is also currently believed that the issue w/disabling of Talons is due to the TimedRobot-based code, which in previous VMX-pi 2019.4.1 Beta Releases would sporadically stop invoking TeleopPeriodic; this issue is resolved in VMX-pi 2019.4.1 Beta 13. But we'll leave the issue open until we heard back from the @PixelGaMERCaT.

cecilialau6776 commented 5 years ago

Appears to have been fixed by disabling FRC-Lock.