cRIO - motor controller code (esp. victor)

[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.