Well our team has strafing working somewhat. The problem is that two wheels are spinning slower than the other two. For example if I push left (to strafe left) on the joystick the back left and front right wheels will spin slower than the other two. Then the opposite happens when pushed to the right. We took a voltmeter to the jaguars to see how much power they are getting when given the command. It read around 2 volts (yikes) so something is definitely up. When reading on the driver station the pwms to the jaguars show me that two are getting less than the other two. I don’t know what else to list then, but here’s the code we are using (except I changed from two joysticks to one logitech 3d). Oh and ignore that it says gyro dawg. Thanks for the help in advance.
Do you have encoders on your gearboxes, or are they running in an open loop?
the cims are biased in one direction.
No encoders we only have 1 with a mount so I haven’t programmed for them cause we can’t mount them
It seemed to work just fine when rotating and going back and forth with a slight curve though
This is false.
Recalibrate your Victors.
You have a couple clues.
2 volts on a jaguar output side? If the PWM’s are showing different values, then they are telling the jag’s to act differently. That also means that it’s likely your controller is sending different values.
First, create 2 numeric controls in labview and hook THOSE up to your drive. See if you can get all full-speed values that way. I suspect you will be able to, and that this will point back at one of two things - you may not be calling out the axis’ correctly on your new controller, or it may not be acting the way you expect.
Try going back to the logitech attacks and see if they function correctly. Remember - methodically narrow your problem down to one component: then you have the solution to your problem.
well, it depends, brand new fresh cims have no bias, but after a year they are about 3% or something and after two they have like 7% difference between forward and reverse.
What would cause that?
Yeah the wheels spin at full speed, but can’t check the logitechs until school. Would an encoder even help? That would just read me how fast something is rotating wouldn’t it? Also we have had our cims for two years I have never heard of them being biased. Otherwise if it is the joysticks is there some calibration on them?
Edit: Oh now that I think about it I think the pwms were reading higher than what the voltmeter said I don’t remember, but the difference between the fast ones and slow ones was like 2 or something. I could tell a difference in the bars, but I don’t think it was very drastic. Again I’ll have to wait until tomorrow.
as they are used the rotor magnetizes, thus they gain a bias in which ever direction they are used the least.
Oh so I guess I have to check if I have anymore cims then. Hopefully we do or we’re going to be behind.
a better idea is to find out which cims are a little slow, and then program the other ones to go a little bit slower in that direction, this is what my team did last year and it worked pretty good.
They seem to all be slow in a certain direction cause like I said when I push left the rear left and front right will go slow and when I push right the rear right and front left will go slow.
so find out which ones are slow and in what direction, and make them slow in the other direction too, so if motor 1 is 4 percent slow in counterclockwise, multiply all of its inputs clockwise by .96, then it will be the same both ways
I dunno what that means if you mean that in programming terms
Ok I’ll try that too.
Your CIMs may or may not be biased, but that’s not the issue you need to chase first.
this line from your first post is what you need to address first
When reading on the driver station the pwms to the jaguars show me that two are getting less than the other two.
If you expect the wheels to all be getting the same speed command and they aren’t you need to look at your code. I am not particularly familiar with the Labview holonomic drive VI and I don’t have a copy of Labview this year to play around with so I’m not sure which direction to point you in terms of diagnosing the problem with the code.
The reason (or a possible reason) Grim Tuesday brought up encoders is because they can help you in correcting any bias that may pop up due to any issues, be it a mechanical or an electronic issue.
With an encoder, you can perform some higher-level programming and include features such as PID (proportional–integral–derivative) loops to account for error.
For example, if your code is telling the wheels to spin at 2,000 RPMs (I know, not how it actually works, but bear with me), and the encoder says the wheels are only spinning at 1,800 RPMs, you can use your code to dynamically adjust the output until the wheels are all spinning at the same (and/or correct) rate.
Simply multiplying the output by .96 because that’s the error you measured once or twice is not a good programming habit to get in to. These “magic numbers” are bad practice because they make the code difficult to adapt later and the magic number that indeed performs magic may vary depending on the situation.
When reading on the driver station the pwms to the jaguars show me that two are getting less than the other two.
This would indicate to me that there is something wrong with the code. Assuming you are not using the CAN bus or any encoders, the PWM values the DS shows are for all intents and purposes what your Victors/Jags are running at. Thus if those values are off, the wheels are not getting the correct values.
However, be aware that if you aren’t pushing your joystick perfectly in one direction, all four values shouldn’t be the same. I would recommend taking the joysticks’ values and running them through the code yourself to see what is happening and what should (in your eyes) be happening.
Also make sure you are working with freshly charged batteries. Poorly charged batteries can cause a number of problems.
I think the problem may be from me inverting some crap, which I was also thinking through and guess I’ll just have to see that. My program makes it so that the joystick is directly controlling each motor. I have not subtracted the speed from any of the motors or interfered with that, so that’s what is perplexing me. Again this basically only happens when strafing left and right, so that’s just making me think more and more that it’s my code since forward/reverse are near perfect
Edit: Oh that brings up another thing too we did test the voltmeter having the joystick in different directions and the voltage did go up when I was very close to horizontal. I probably need to get a joystick with notches or disable the y axis when the x axis is active then?
Part of that will determine how your team/driver wants to control the robot.
My team has used mecanum for a number of years now with two joysticks. One joystick essentially provides arcade drive (y-axis controls forward/back, x-axis controls rotation), and the second joystick provides strafe on the x-axis. You don’t need to disable the y-axis on the second joystick, you simply don’t use any of the values it gives you.
There are of course other control options that would require tweaking this a little. How are you planning on controlling it?
Right now it’s set up so one joystick does it all (I just did it for fun and ease of carrying things around) Rotation of the joystick rotates the bot (working fine) Forward/reverse on joystick=forward/reverse on bot lastly left and right is strafing. My other set up was one joystick does strafe and forward/backward and the other joystick rotates on the x axis (like call of duty controls) and thinking about it that set up would cause the strafe value to be read a little weird since it’s also reading the y axis and it’s hard to strafe unless all the motors are the same speed