Closed cecilialau6776 closed 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.
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.
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.
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?
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. / /----------------------------------------------------------------------------/
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)
**
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.
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.
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. / /----------------------------------------------------------------------------/
void Robot::RobotInit() { m_chooser.SetDefaultOption(kAutoNameDefault, kAutoNameDefault); m_chooser.AddOption(kAutoNameCustom, kAutoNameCustom); frc::SmartDashboard::PutData("Auto Modes", &m_chooser); }
/**
/**
make sure to add them to the chooser code above as well. */ void Robot::AutonomousInit() { m_autoSelected = m_chooser.GetSelected(); // m_autoSelected = SmartDashboard::GetString("Auto Selector", // kAutoNameDefault); std::cout << "Auto selected: " << m_autoSelected << std::endl;
if (m_autoSelected == kAutoNameCustom) { // Custom Auto goes here } else { // Default Auto goes here } }
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() {}
int main() { return frc::StartRobot
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() {
}
}
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;
/**
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
/**
/**
/**
/**
@Override public void teleopInit() { talon.clearStickyFaults(); }
/**
System.out.println(info);
count++; }
/**
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.
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.
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```
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.
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.
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 .
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.
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.
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.
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.
Would it be possible that there's an issue with my pi image?
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
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.
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 .
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.
Appears to have been fixed by disabling FRC-Lock.
Trying to run a motor connected to a TalonSRX gives me these errors in driver station:
Here are the relevant parts of my code:
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.