Need to confirm

[umangv620]

I'm making the final adjustments to my code, but I need to confirm a few things before I try them out on the robot.

1) Does using the wait timer prevent all other robot functions from running in teleop until the wait timer is over? I'm talking about the wait timer used in this code, but not in that context.

We have a drive shifter that switches between 2 speeds, and it shifts when the joystick trigger is pressed. The problem is that sometimes, our driver holds the shifter for half a second too long, and it shifts more than once. Can I put the wait timer in my code without it preventing tank drive and other robot features from functioning?

2) We are using a window motor for our arm, but due to gravity + inertia + physics, when we move the arm down, the arm just falls down all the way and smacks into the robot. I believe I have the window motor only moving at .4 speed downwards, but is there any way for to prevent it from falling down so rapidly? At the slightest touch of the joystick, the arm falls down all the way, and it takes a while for the window motor to bring the arm back up.

3) I need to code preset arm locations, that use the window motor and a potentiometer. I was looking at team358's sample code to see how it could be done, and they used PID. Im not very experienced using PID, so I just need clarifications for this. Does the PID automatically know if it has a greater or lower voltage than the desired position, and move accordingly? And for the P part of the PID, does it matter how low the number I make it? Its supposed to lower the error on the motor as the number gets smaller, but is there a consequence to making the P number too small?

4) I don't remember the exact error I was getting, but when we run our code, Driver Station fills up with errors saying that Robot Drive either runs too fast or too slowly for teleop.vi / robot main.vi. When we run our code though, we experience no lag (besides the very occasional communication+robot code loss). If I need to, I'll post the exact error I get tomorrow, but I was just wondering is there a known fix to this? As far as I remember, we have been getting this error since day 1 with a clean FRC 2011 cRIO robot project.

If I remember any more adjustments I have to make and don't understand, I'll update this post.
Any help here would be greatly appreciated.

[Greg McKaskle]

The issue with #4 and to answer the question about #1, teleop code shouldn't have a delay in it. You want teleop to return as quickly as possible.

To answer the question, wait delays the sequence or diagram it is in. Because you haven't returned from teleop, the next teleop packet cannot be processed, so it introduces a serious delay in the teleop execution of your robot.

Greg McKaskle

[umangv620]

I don't have any wait timers in teleop at the moment, but im still getting the errors in #4.

[Alan Anderson]

The appropriate answer to #2 is to mechanically support the arm so that gravity is not a large influence on its motion. Either a counterweight or some sort of spring arrangement would work. There is no easy way to deal with it in software, especially with a window motor.

For #3, setting the P constant too low will result in the motor being given so little power that it will stop long before it gets to the set point. The I constant can compensate for this, but it will take some time, and is likely to overshoot badly. What you generally want to do is increase P until you get oscillation, then back it down until you get reliable motion with a reasonably small steady-state error. Then increase I until that error is resolved with a minimum of time and overshoot.

[Doc Wu]

Originally Posted by umangv620

4) I don't remember the exact error I was getting, but when we run our code, Driver Station fills up with errors saying that Robot Drive either runs too fast or too slowly for teleop.vi / robot main.vi. When we run our code though, we experience no lag (besides the very occasional communication+robot code loss). If I need to, I'll post the exact error I get tomorrow, but I was just wondering is there a known fix to this? As far as I remember, we have been getting this error since day 1 with a clean FRC 2011 cRIO robot project.

I have been experiencing the same thing with even the default project. Because the default code generates that error, I've just ignored it.

Wish someone would come up with a fix or at least an explanation of this.

[umangv620]

Originally Posted by Alan Anderson

The appropriate answer to #2 is to mechanically support the arm so that gravity is not a large influence on its motion. Either a counterweight or some sort of spring arrangement would work. There is no easy way to deal with it in software, especially with a window motor.

For #3, setting the P constant too low will result in the motor being given so little power that it will stop long before it gets to the set point. The I constant can compensate for this, but it will take some time, and is likely to overshoot badly. What you generally want to do is increase P until you get oscillation, then back it down until you get reliable motion with a reasonably small steady-state error. Then increase I until that error is resolved with a minimum of time and overshoot.

If I use buttons and PID to move the arm to a certain position, will it prevent the arm from overshooting downwards? Lets say my arm is all the way up, and I want to put it to a 45 degree angle to drop it. If I use PID to move the motor until the certain voltage is hit (lets say 2.5 V), will it stop at the 45 degree angle, or does it still have the possibility to keep falling downwards due to gravity?