Multiple Counter objects with Analog Triggers issues.

[AlexanderTheOK]

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 your time and advice in advance.

[jhersh]

Originally Posted by AlexanderTheOK

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 your time and advice in advance.

At first glance your code looks fine. Maybe there is a problem with the Java implementation.

[Jared]

Try using analog inputs 0 and 1 if possible.

Only these two are have accumulators in the FPGA and may behave differently than the rest for other features too.

[jhersh]

Originally Posted by Jared

Try using analog inputs 0 and 1 if possible.

Only these two are have accumulators in the FPGA and may behave differently than the rest for other features too.

All analog inputs are equivalent wrt analog triggers.

[AlexanderTheOK]

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.

[jhersh]

https://usfirst.collab.net/sf/go/artf4010

[jhersh]

Originally Posted by AlexanderTheOK

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.

[AlexanderTheOK]

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?

[BradAMiller]

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.

[AlexanderTheOK]

Thanks a ton! I was just about to start blindly fenageling things. I'll be looking forward to the fix!

[BradAMiller]

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.

[vamfun]

FWIW, the analog trigger output worked as a digital source for us using the counter class but seemed broken with the encoder class. Ref: http://www.chiefdelphi.com/forums/sh...analog+trigger

This counter command
Counter1.setUpSource(Trigger1, AnalogTriggerType.kRisingPulse);

seemed to work in setting the source. Would have liked a similar function for the encoder. E.g.

Encoder.setUpSource1(Trigger1, AnalogTriggerType.kRisingPulse);
Encoder.setUpSource2(Trigger2, AnalogTriggerType.kRisingPulse);

[AlexanderTheOK]

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?

[jhersh]

Originally Posted by AlexanderTheOK

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?

We use the absolute encoders 1:1. Not doing that loses pretty much all of their value and you may as well just use a digital encoder.

[BradAMiller]

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.