Lab View Code Help

Help! So we are having some serious code issues. We lost our code mentor on Sunday and we are stuck. We are using Talon SRX controllers and versa planetary VEX/CTR integrated encoders on AM breakout boards. We are having an issue when we try to move more than one joystick or make a fast direction change on axis of a stick, our bot arm tries to slam thru our limit switches and tries to destroy itself. We have started completely over on our code so the only thing in the code is just moving the arm. The associated encoders read perfectly and the limit switches check fine, the hard limits stop the movement when manually tripped and moving in the appropriate direction toward it. If you try to move more than one stick quickly at one time is when things go crazy. We tried to eliminate all other code interference and We are down to literally just a block in begin and two blocks in teleop to diagnose and are out of options.

Maybe it’s the inertia of the arm. We have a pretty big gear reduction on our arm (450:1) and it will not be stopped by the limit switches in time.

Try setting the soft limits in the code. This probably can be done in labview but also can be done by going to 10.team.number.2 and clicking on the Talon SRX controller under CAN and setting them there.

Another possibility is that the rapid movements of your joysticks causes the integral to wind up in the PID loop which makes it move quickly into the limit switches

You should think of the limit switches as more of a ‘hard stop’ rather than a ‘home position’, at least that’s how we think of them.

Also, to get your motors to stop faster, put the Talon SRX in brake mode instead of coast. It’s harder on the gearboxes and such, but it will stop the arm faster

Does anybody have a closed loop move to an encoder position. This seems to be part of our problem.

You have 2 days to bag day, and it sounds like you’ve never implemented a pid loop before. I suggest you find a team around you and ask for help immediately.
Another option is to drastically increase your gear ratio and slow down your motions.

We are trying Tom, it’s not the tuning that is the problem, we are having some strange step change responses from the SRXs in the form of jumping in the wrong direction even under manual control. You are correct, we haven’t used the CTR vis before to use implement pid control, and were simple looking for an actual example of a working code example of moving a gearbox output equipped with a functioning encoder to a desired position using the CTR pallet functionality so we might see what simple thing we are obviously getting wrong.

The first thing I would do is look at the setoutput commands you are sending.

A “step condition” suggests that you have a race condition - two functions may be trying to set the motor controllers at the same time.

Look at the set commands you are setting to the output. You’ll probably need to save them to an array to view them because it will set the output too fast and you may miss a single value passed to the SRX’s.

Do you have two locations that both use the set SRX output? Two locations that set whatever global you have feeding the SRX output?

Have you also verified that you are not going ABOVE or BELOW the max +1 / -1 set outputs? We got nailed once by not checking that and the SRX used to roll over. Not sure if it still does that.

Weird step changes in a PID response loop is often overflow (the intergral component is either unstable or saturated).

Start with the basics of PID optimization:

  1. Turn off everything but the proportional control.
  2. Start small. Increase slowly until you’ve got accurate but barely minimal response. Increase until you’ve got a decently responding system, but it will likely have a lot of undershoot.
  3. Then consider adding integral control. Again, start small.

If you can’t get something decent in step 2 (aside from some modest undershoot), it’s not worth farking around with integral control.

Also, do you have a picture of your arm? If it’s a cantilevered arm you’ll have all sorts of problems with a PID controller since the torque is highly asymmetric; raising the arm is hard while letting it fall is easy, and you’ll need to adjust the commanded position accordingly.

Yep - you can help the asymetric nature of the PID by using separate PID gains for up and down. The new library accounts for that by giving you two PID gain “slots” and you can choose which to use.