RobotDrive Bug?
 

Hi Guys,

I have a weird situation that I've come across. I'll start with the back story:

Using last year's cRio setup, we have 4 Jags and 4 Victors. I have implemented the CAN interface using the Jags. Our robot requires 5 Jags to drive. Hence, I have a dilemma where I'm short one Jaguar. So the quick fix was to use 4 Jags and 1 Victor. This would not be the final configuration, but I figured it would work for the meantime. Just to get something up and running quickly, I made use of the RobotDrive class. I instantiated the class in its 4 wheel drive mode and used the arcade function using 3 Jags and 1 Victor (again, I know this isn't necessarily a good idea). The 4th Jag is being used for position control using the closed-loop position mode on the Jags over the CAN interface. I then make use of the ArcadeDrive method of RobotDrive. Now, all the parts work separately, but when put together I can't get position mode anymore. Hence, the potential bug I'm seeing.

When I remove the Victor and replace it with a Jag, the code runs just fine. HOWEVER, I'm not sure why this SHOULDN'T work because the constructor for the 4 wheel drive method uses the SpeedController class from which both the Victors and Jags are derived. Thus, I'm at a loss to determine why this is happening. Everything seems fine in the provided WPI source code, but for some reason using a Victor hoses something else which then kills my CAN control. The position Jag will then move, but it won't move with feedback (like it's in kPercentVoltage mode or something).

Does anyone have any ideas?

- Bryce

Re: RobotDrive Bug?
 

I'm having trouble following what you are doing in your code. Are you constructing a RobotDrive object with 3 CanJaguars and one Victor?

Regardless of whether you can get the software to work, I would not mix Jaguars and Victors in the same drivetrain and especially not in the same transmission. Look at these speed curves and think about what happens when you have an output of .1 to both the Jaguar and the Victor and the Jaguar is going 10% speed and the Victor is going 50%. You're motors will be fighting the whole time.

Re: RobotDrive Bug?
 

Thanks for your reply Joe, but how many times did I mention that this is only a temporary hack? Regardless of whether it's a smart thing to do, the code should still work. And yes, essentially it breaks when I instantiate with 3 Jags and 1 Victor. What's worse is that it breaks other code that isn't even part of the same class.

- Bryce

Re: RobotDrive Bug?
 

Bryce,

Can you describe exactly what happens? It's possible you found a bug, but we'll need you to do more experimentation to narrow it down.

You are using C++, right? I can't tell since you are in the generic Programming forum.

Are you getting any errors (in the diagnostics tab on the Driver Station)... the C++ classes use the ErrorBase and depending on where the errors get passed could cause this type of behavior. Other than that, I have no idea what could cause it.

-Joe

Re: RobotDrive Bug?
 

If you have 4 jags and 1 vic, put the 4 jags on drive and the vic on position control. I would do that much much much faster than putting a drive motor on a jag and a drive motor on a vic. The software will probably thank you too.

What is the advantage of using the CanJaguar's position control? You have analog inputs on the cRio, and since programmable controllers in FRC (back in the day... 1997?) people have been writing simple code to control position.

Re: RobotDrive Bug?
 

Joe,

I'll look for messages tonight and try to get back to you.

apalrd,

Yes, you are correct about your description. We could set it up that way you specify with closed loop calculations being performed on the cRio itself. I started on SPAM 10 years ago and have seen the capability of even the old controllers (back in the PBasic days). But currently, our final assembly has a motor with quad encoder attached, hence the reason for trying this. I was using the Jag in position control mode because that is what the final configuration will be. Why write code for something that will not be used again? I will repeat myself again though...that is not the focus of my original post. The point is, however stupid it may be, that the RobotDrive class hoses another Jag (at least that appears to be what I'm seeing) when two different SpeedController inherited classes are passed to the RobotDrive class. We meet tonight and I will try to post a more detailed description.

- Bryce

P.S. It's really just a moot point because I have already replaced the Victor with a Jag in the box. I just thought I'd bring up some weird behavior that I witnessed.