View Single Post
  #17   Spotlight this post!  
Unread 23-05-2010, 20:57
kgzak's Avatar
kgzak kgzak is offline
Registered User
AKA: Kris
FRC #4392 (Decievers) FRC #2075 (Enigma)
Team Role: College Student
 
Join Date: Dec 2008
Rookie Year: 2008
Location: Grand Rapids, Michigan
Posts: 418
kgzak is a splendid one to beholdkgzak is a splendid one to beholdkgzak is a splendid one to beholdkgzak is a splendid one to beholdkgzak is a splendid one to beholdkgzak is a splendid one to beholdkgzak is a splendid one to behold
Re: Swerve vs. Mecanum Programming

Quote:
Originally Posted by apalrd View Post
While I can't look at your code since I don't have LV on this computer, I can say a few things in general:

1. P should be good for steering, unless you have a lot of friction.
2. You should rely on the sensor. Not too much, but don't program all kinds of safeties like it going in the wrong direction. good limits are out of bounds, lost sensor (0 volts), and not moving if you are really worried about it. We have no mechanical limits on our swerve, except the wiring, and we leave a lot of extra wire. Using window and globe motors (especially the window motors), it doesn't have enough power to damage much in our application.
3. Use the same code in auto as teleop - best to put it in a new thread.
4. Make kP (gain) a front-panel control or global to tune it. If you are using four identical motors (e.g. window motors), you would probably be fine with one gain and volts/deg, and x centerpoints (where x is the number of controllers), if you mix motors (e.g. window+555 or window+globe), then you would need a different gain for each motor and volts/deg for each different sensor (e.g. when sensor gearing or # of turns is different).
5. Pots never completely fall off. We have had many problems with set screws coming loose and pots loosing connection, but never completely fall off.
6. Don't be scared of code changes. We change our code quite frequently, and generally try to test it before playing, depending on how major the change was (we don't generally test autonomous kick distance changes, for instance).
The safeties were there just as a challenge for me to do. In one of the versions I have I can turn them on and off. Our pot was held on by friction on the shaft and had some sort of way to keep the pot itself from actually turning. (it was a practice robot but some of the parts needed to be used on the final robot). Everything in that VI I posted can be changed through the front panel. It is made to be modular so we can use it for steering, driving a certain distance, and what ever else involves moving from one number to another. I was not afraid of changing our code, our mentor was afraid he would have to re-machine the disks if we went to far. {We had aircraft wire screwed into 5 discs, 4 on the swerve assemblies-1 on the motor. If we turned to far either our wire would snap or the screws would break. The safeties were just to keep people in the room safe while it was running.}