Pretty recently we decided to pull our Limelight 2+ out of storage so I could begin to program it in our main language, LabVIEW. After a while, I felt that I started to get the hang of it, with one exception. Basically, we programmed the Limelight to look for a target (duh) and once it found one, it is supposed to follow it using the drive train. Our drive train speed when using teleop is set to a constant of .65 (65% speed). However, the Limelight overrrides that when vision tracking is active (which is toggled by a button on our joystick). Anybody got any ideas or fixes? I want the drive train speed to stay the same while also tracking targets.
I really do not know labview, but I would suggest looking at the part in your code where that you are calling when your press the button to follow the limelight. it likely has some logic to adjust the turn speed and forward speed on your drivetrain. Hope that helps.
Select your drive code section in LabView and from the edit menu choose “Create VI Snippet from Selection” This will create a png file which you can upload and others can actually pull into LabView and use.
Do the same for your auto nav routine you are using with LimeLight.
So this is using a P term and the vertical distance to set your forward value. If you really want the limelight to just control the turn and use your joystick for foward then plug the Joystick Y global into the arcade drive (the 3rd input).
That’s what I had previously done, but what I want it to do is to maintain the same distance from the target while simultaneously keeping the vertical drive speed (Y) the same so it doesn’t lurch forward when it finds a target. Honestly I need to do that with the X axis too but I’m more worried about the Y.
I don’t get it. You want it to maintain the distance but you want it to do that maintaining at whatever rate the joystick is at? So do you want the speed constant (like capture what the speed is the first time and use that) or to change with the joystick? What is to say the joystick is giving any speed or pressing in the right direction?
I am guessing what might solve you problem is a lower Proportional Gain value such that the error correction when finding a target is less aggressive. You would probably want to use a separate p value for both forward and turn. Keep your turn the same since you like that and lower the forward.
The joystick’s max output is 1, so you send back to your drive train at most 0.65. However, if the limelight value is greater than 1 (let’s say 2) then you are sending to your drivetrain 0.65*2 = 1.3 (or max power forwards)
What I suggest doing is capping the value. Before passing the limelight value to drive, compare it to 0.65. if limeLightValue > 0.65 send the drivetrain 0.65, else send it limeLightValue. Another way to do this would be to use min(limeLightValue, 0.65). I’m not exactly sure what all you have available in Labview.
(Note: Making this work with negative values as well is left as an exercise to the read, but feel free to ask if you’re still having issues)
Now, for a quick note for OP. Realize that most likely what you are referring to as 0.65% is actually power, not speed. It’s easy to confuse these two, especially in some cases where function literally called “setSpeed” are just setting power. The problem of maintaining a constant speed is a very different problem than the one you described, so some may be confused by your title. I think it would be better renamed: “Capping max drive power while following LimeLight Target”
This is completely unrelated to your topic so I do apologize for going off on a tangent, but if you find your drivetrain is so fast and difficult to control that you turn down the max voltage output in code, you should consider instead increasing the gear ratio of your drivetrain gearboxes so that your top speed is lower. Decreasing the voltage in code will decrease total power output, which will decrease speed (which you want), but it will also decrease torque, which you don’t want to do, and will result in your drivetrain having lower acceleration and pushing power.
By changing the gear ratio instead of slowing down your robot in code, you get to have a slower, more controllable robot without sacrificing mechanical power output from your motors.
I’m not familiar with the limelight, but I’m wondering if the OffsetAngleV stands for vertical? If so then I don’t think you would use this for driving.
It seems to me that what you might want to do is create a Left and Right offset correction that is summed to your normal 0.65 speed. For arcade drive, I think this would add strictly to only one of the arcade inputs, the one that controls left-right movement. (Y goes fwd/bck, X goes left/right).
Here is a quick and dirty sample that might help. The K factor will need to be tuned to get the best response. (It could be negative too if the direction is backwards.)
Another unrelated observation. The standard arcade drive squares the joystick inputs so 0.65 becomes 0.42 to the motors. You can turn this off if you want. If you really want the output speed to be 0.65 than the input limiter would be larger…
