cRIO - motor controller code (esp. victor)

[ericand]

I think there is a bug in the speed controller init code for the victors.

The default settings for the victor speed controler set the center position as 132. The comments state that the values
used were established "empirically"

The default bounds are:
max 210
Dead Band Top 138
Dead Band Mid 132
Dead Band Bot 126
min 56


Given, as the comments state, the values can vary from victor to victor, and given the values can chage if the victors
are calibrated using the Victor calibration procedure of (give them max PWM and min PWM and push the switch on the
victor)

I think a better default would be centered around 127, with max and min at 254 and 0 respectively.

Better yet would be to have a motor controller constructor that allows these to be set whe the controller is created.

At the very least we need a note to teams to call SetBounds() on their controllers to get values that match their
hardware (instead of values that match the hardware of the WPI library developers.

This may explain why we were seeing the drive moters creep and hum when the joysticks were neutral. For those motors,
neutal was actually just a little bit on.

The code for the Jaguar controller looks more like what I would expect.

[Alan Anderson]

Those empirically established values match the factory calibration of every Victor I have taken the time to characterize. I suspect that if you restore the factory calibration to your Victors, you'll see the "creep and hum" at neutral go away.

[BornaE]

The robotdrive is a high level function created for ease of programmin, and there are multiple assumption in it.
If you was low level of controll you can always use the lowest level dunctions that are in the PWM pallet. then you can set your mins and maxes and centers easily

[Dave Scheck]

I was testing with servos controlled by a Victor class and noticed that I wasn't getting full range on the output. That got me digging through the source of the library (an excellent reason for open source code) and noticed the output limits based on empirical data as well.

Originally Posted by Alan Anderson

Those empirically established values match the factory calibration of every Victor I have taken the time to characterize.

Any idea why they chose to limit to the default factory values instead of letting the full range out and using the manual calibration of the Victors like years past? If a veteran team pulls Victors from a previous year's robot, they're going to have problems if their Victor is calibrated (as Eric has already found out)

Alan, you mentioned setting the factory defaults for the Victor. What's the procedure for that for teams that don't want to mess with SetBounds()?

[Gdeaver]

Seams the victor manual is not on the IFI website any more. Maybe someone could post excerpts from the manual. As far as servo's, The Jag VI's allow pulses less than 1 ms and grater than 2ms. This would allow a team to use the full mechanical range of hobby servo's. Care must be taken not to stress the servos against the mechanical stops. Good way to make a servo eat it's self. This can be useful when using hobby servo's to control a pan-tilt assemble for the camera or Sharp IR range sensors.

[ericand]

I was just looking at the specs and manual (found via google search at
http://www.ifirobotics.com/victor-88...r-robots.shtml and http://www.ifirobotics.com/docs/ifi-...al-9-25-06.pdf)

The spec sheet states that the dead band is centered around 127. The manual describes the calibration process.

I would expect the defaults in the code to match the specs, not some empirical test (with out a lot of explanation as to why the specs are wrong and must be overridden by default).

[Vikesrock]

Originally Posted by ericand

I would expect the defaults in the code to match the specs, not some empirical test (with out a lot of explanation as to why the specs are wrong and must be overridden by default).

What kind of explanation would you like? If you search around on the forums there are numerous teams who have collected data on the Victor's transfer curve and found that the center of the deadband is 132 in factory calibration. The reason why would be a question for IFI.

In this post on the IFI forum, you can see them list neutral as 1260139 which puts the deadband center between 131 and 132.

[Alan Anderson]

Originally Posted by Dave Scheck

I was testing with servos controlled by a Victor class...

That's the root of the problem right there. Why weren't you using a Servo class? The software knows about and exploits the difference between the various output devices. If you lie to it about what you're connecting, you shouldn't be surprised that it doesn't give the results you want.

Originally Posted by Dave Scheck

Any idea why they chose to limit to the default factory values instead of letting the full range out and using the manual calibration of the Victors like years past? If a veteran team pulls Victors from a previous year's robot, they're going to have problems if their Victor is calibrated (as Eric has already found out)

If you use a Victor that was calibrated in a different system, you're asking for trouble in any case. It's easier to reset to factory defaults than it is to calibrate to a new system. In my experience, every Victor acts the same, so it seems quite reasonable to set up the control software to match their behavior.

Alan, you mentioned setting the factory defaults for the Victor. What's the procedure for that for teams that don't want to mess with SetBounds()?

For teams unwilling to mess with reading the manual, you mean?

Remove power from the Victor. Press and hold the Victor's CAL button. Apply power. Wait for the Victor's LED to blink green. Release the Victor's CAL button. All done.

[Dave Scheck]

Originally Posted by Alan Anderson

That's the root of the problem right there. Why weren't you using a Servo class? The software knows about and exploits the difference between the various output devices. If you lie to it about what you're connecting, you shouldn't be surprised that it doesn't give the results you want.

There is nothing in any documentation that I've read that clearly states that this is the case. The only reason that I ever found out about it is that I observed something through experimentation and dug into the source code to figure out what was going on. For years we've tested basic drive code by watching servo behavior on a benchtop setup. When we tested for the first time with the new system, it didn't seem unreasonable to try the same thing. Now we know, and can deal with it.

I have quickly learned that the new system is not the old system. Things that used to work, no longer do. For example, we used to set all motor output to neutral at the start of every loop for safety, then only set the motors that needed setting. With the new system, as soon as a Set is called, the output is set (which makes sense). When we initially tested, we were getting choppy response. It took a little bit to figure out what was going on, but it's a learning process.