As the title suggests I am having issues with the Counter class. I am specifically using MA3 encoders and using the Counter and Analog Trigger classes to keep track of rollovers. This works fine when using a single MA3, however, with multiple it seems that only the counter created first in code works. The others don’t throw exceptions, dont give errors, just simply don’t register rollovers and simply don’t count. I know the analog inputs themselves are working fine, as well as the analog triggers, so I have narrowed it down to the counter.
The barebones code I used to test this issue is below. If anybody can tell me where I screwed up I would be very grateful.
public class Robot extends IterativeRobot {
Joystick controller = new Joystick(0);
VictorSP motor1 = new VictorSP(7);
VictorSP motor2 = new VictorSP(17);
AnalogInput ma31 = new AnalogInput(0);
AnalogInput ma32 = new AnalogInput(3);
AnalogTrigger Trigger1 = new AnalogTrigger(ma31);
AnalogTrigger Trigger2 = new AnalogTrigger(ma32);
Counter Counter1 = new Counter();
Counter Counter2 = new Counter();
/**
* This function is run when the robot is first started up and should be
* used for any initialization code.
*/
public void robotInit() {
Trigger1.setLimitsVoltage(0.5, 4.5);
Trigger2.setLimitsVoltage(0.5,4.5);
Counter1.setUpDownCounterMode();
Counter2.setUpDownCounterMode();
Counter1.setUpSource(Trigger1, AnalogTriggerType.kRisingPulse);
Counter1.setDownSource(Trigger1, AnalogTriggerType.kFallingPulse);
Counter2.setUpSource(Trigger2, AnalogTriggerType.kRisingPulse);
Counter2.setDownSource(Trigger2, AnalogTriggerType.kFallingPulse);
}
/**
* This function is called periodically during autonomous
*/
public void autonomousPeriodic() {
}
/**
* This function is called periodically during operator control
*/
public void teleopPeriodic() {
if(controller.getRawButton(1)) motor1.set(0.2);
else if(controller.getRawButton(2)) motor1.set(-0.2);
else if(controller.getRawButton(3)) motor2.set(0.2);
else if(controller.getRawButton(4)) motor2.set(-0.2);
else{
motor1.set(0);
motor2.set(0);
}
System.out.println(Counter1.get()+ " " + Counter2.get() + " " + ma31.getVoltage()+ " " + ma32.getVoltage());
}
/**
* This function is called periodically during test mode
*/
public void testPeriodic() {
}
}
Thanks for the input. I was actually using all four analog inputs before. The code above is only here to demonstrate the issue, and to show that it isn’t caused by anything like multithreading of my own. Again, with all four inputs, the first is still the only one to count, no matter which one it is, 0,1,2, or 3. Each works fine on their own, but no more than one functional counter can be created it seems.
Does anyone know a different way to do rollovers? I’ve been experiencing lag spikes in actual code up to 200ms so simply running code that manually checks for rising and falling edges doesnt quite work. I’t misses ticks sometimes.
I’ll try to use interrupts today to see if I can avoid the above problem (the lag). Will report if it works or not.
Based on the bug report, the issue is that the Analog Trigger -> Digital Source is what’s broken, so Interrupts won’t work either. Perhaps just correct the HAL source (i.e. don’t change the channel if analog trigger bit is set) and rebuild. Not sure when another release will come out of WPI that will have a fix.
Hmm. I’ve got the source here. Any resource on how to build the source and set it up for Eclipse if and when I find the pesky line that’s messing things up?
I’ll try to get this fixed tonight or tomorrow morning and will post a version of the library for you to test to see if it fixed your issue. It looks like Joe correctly identified the issue, I just need to verify an FPGA usage thing. When it’s ready, I’ll post on this thread.
Now that all the source code is public, we’ll put up a page of directions on building the library and the plugins. I’ll try to get to that soon.
Can you try the development version of the library. It finished building about 30 minutes ago. To get it, change the eclipse update site from “release” to “development”. Then just install the plugins from there.
Please let us know if it worked for you. We constructed a test case but want to make sure it fixes your issue.
Yes. One seems fine on its own. Making multiple is however the specific issue here.
Are there any other teams here who are using the ma3 encoders for a swerve drive and don’t have them geared 1 to 1? I would think this issue would pop up much earlier in the build season, but it seems I’m the first one to actually attempt using them like this,which leads me to believe that other teams are keeping track of their modules somehow differently. Are there other methods being used out there?
This issue has been fixed and verified by the AlexanderTheOK in the development release of the plugins. Next time we do an “official” release it will come out there. If you are having a similar issue, change your plugin location to development (replace “release” to “development” in the plugin path) and update the plugins.
Aleksandr, thanks for helping us track down the problem and get it fixed.
One thing I almost forgot to post in this thread. The code I posted in the beginning of the thread WILL NOT WORK reliably to count rollovers on the MA3 encoders. This is because the original code did not make a call to the “setFiltered” method. This takes a boolean and is made specifically to facilitate rollovers. The corrected code looks like this:
public class Robot extends IterativeRobot {
Joystick controller = new Joystick(0);
VictorSP motor1 = new VictorSP(7);
VictorSP motor2 = new VictorSP(17);
AnalogInput ma31 = new AnalogInput(0);
AnalogInput ma32 = new AnalogInput(3);
AnalogTrigger Trigger1 = new AnalogTrigger(ma31);
AnalogTrigger Trigger2 = new AnalogTrigger(ma32);
Counter Counter1 = new Counter();
Counter Counter2 = new Counter();
/**
* This function is run when the robot is first started up and should be
* used for any initialization code.
*/
public void robotInit() {
Trigger1.setLimitsVoltage(0.5, 4.5);
Trigger2.setLimitsVoltage(0.5,4.5);
Trigger1.setFiltered(true);
Trigger2.setFiltered(true);
Counter1.setUpDownCounterMode();
Counter2.setUpDownCounterMode();
Counter1.setUpSource(Trigger1, AnalogTriggerType.kRisingPulse);
Counter1.setDownSource(Trigger1, AnalogTriggerType.kFallingPulse);
Counter2.setUpSource(Trigger2, AnalogTriggerType.kRisingPulse);
Counter2.setDownSource(Trigger2, AnalogTriggerType.kFallingPulse);
}
/**
* This function is called periodically during autonomous
*/
public void autonomousPeriodic() {
}
/**
* This function is called periodically during operator control
*/
public void teleopPeriodic() {
if(controller.getRawButton(1)) motor1.set(0.2);
else if(controller.getRawButton(2)) motor1.set(-0.2);
else if(controller.getRawButton(3)) motor2.set(0.2);
else if(controller.getRawButton(4)) motor2.set(-0.2);
else{
motor1.set(0);
motor2.set(0);
}
System.out.println(Counter1.get()+ " " + Counter2.get() + " " + ma31.getVoltage()+ " " + ma32.getVoltage());
}
/**
* This function is called periodically during test mode
*/
public void testPeriodic() {
}
}
This is unrelated to the issue this thread is about, but future readers who may be using code from chief delphi may come across this and use the original code as an example, so I will leave this here to avoid confusing anyone.
Huge thanks to Brad Miller, Joe Hersh, and Kevin O’Connor. I would be struggling with a lot of communications code and an offboard processor to make our first swerve drive work if it wasn’t for the fast and precise work and diagnosis of these fine gentlemen.