Programming Issue or Parts Problem. Need Help Please!

[prem17]

Hello to anyone out there,

My team is having a problem with the program we are using. I programmed three servos one continuous and two 180 servos for three different buttons. But for some reason when I press the flag raiser it activates the other two servos. Also when I got to my schematic editor and try enabling the continuous servos it also activates the 180s. We don't know where we went wrong. If anyone could help us it would be awesome!

Thanks.

Team 6552

[mathterizer]

It is pretty common to experience what has been termed as 'servo bleedover'  when in the schemtic editor - a problem you just need to put up with while you use the schematic editor to determine your servo positions (and directions for the CR Servo) - this means that all the servos twitch a bit.

This 'bleedover' can occur in the autonomy program too. So the avoid this we create a variable for each servo that tracks the last desired (known0 position of each servo, and whenever we move a servo we push stored values out to ALL the servos - this maintians their positions and avoids 'bleedover' messing up the 'other' servos.

In teleop you can do the same thing if it becomes a crtical issue, but sometimes we find we can get away without it there.

Today I had a team that had a servo issuse that came up when they had re-mapped their servos on the robot - and in the Schematic Editor. They had switched the servo controller ports around. In the RC Editor remnants of the old assignments seemed to remain, even when we had reassigned the buttons to the new configuration.  We actually had to switch each button to 'None' for the servo and 0 for the servo number, before we switched the action to 'none' --- we SAVEd --  then we went in and assigned the buttons with the new servo names and positions.  Otherwise, the servos were not moving right for the buttons. We were using both continouos and 180 degree servos. I have no idea why this happened, but that is what we had to do to get the servos to behave.

Hope you find this information helpful. (Note: we restarted LabVIEW during this fuss too, to try to get the new Schematic Editor defiitions recognized by the RC Editor correctly.)

[jerry_dcjx]

well, i have also met this problem, and after i reduce the number of servo, the problem was solved.

i just connect two servo on each controller, and i always define the two servo at the same time.

[prem17]

We are not using the servo's for automous so it is fine. If I replace the motor controller could it fix the bleedover? The srevo's are not cruial but important for normal functions. And is there an actual reason why the servos bleed over? Thank you!

[rsthj]

This is normal behavior as the controllers cannot address servos individually.  Rather, a command is always sent to all six.  The trick is to make sure your code initializes all your servos to their desired neutral position.  After that, LabVIEW automatically keeps track of the last known command and there is no need for variables or other tricks to keep your servo from moving.  Without initializing the servos, there is no known "last position" and the first time servos are called, LabVIEW defaults to sending every servo a value of 127(?)  Initialzation is very simple and looks like this:

This behavior can make using the schematic editor tricky as initialization is not possible.  Our work around is to simply unplug all but the servo we are testing.

[prem17]

Could you send a pciture with everything you did becsaue we can't test out the suggestion becaue it says the conditional terminal is not wired to anything and must be wired to a boolean data source such as a button or the result of a comparison. What do we do? This is for tele op not automous. Thanks.

[rsthj]

The only part of the code that is necessary is the servo block on the left--Just put it outside your main program loop and put a wire to the loop and the servos will initialize before any other code executes. The rest of your code should be unchanged. 

[mathterizer]

Thank you SO much for that initialization insight for the RC Editor gnerated code (teleop)! I hadn't realized that LabVIEW would do it's own tracking of 'last postion', but that explains why we 'got away without tracking servos' in the teleop portion. I was always a bit concerned about trying to 'track' in there anyway, worried that we would end up in the classic 'LabVIEW race' situation where the variables were not keeping up as expected.

Yesterday I worked with a team that had the same 'Continuous Rotation/180 degree servo' problems when using Schematic Editor as they were trying to get their 'positions'.  The student struggled with the CR Servo running while she was trying to determine a single 180 degree servo position - she noted that it always RAN (Continuous) in whatever direction she had last apppllied to the CR servo. She determined that by setting that CR Servo Value to 0 (zero) and 'Enable'-ing it for a bit, that it would then sit still when she was testing her 180 degree servos [NOTE: you DO have to 'enable' the zero, or it wont' stick].

It was really important that she figured this out, as some of the 180 degree servo positions would mechanically entangle when the CR Servo started to move into 'forbidden' areas of the robot!

Can't wait to test out how initializing the servos inside (ie. 'outside')  the RC code works for the kids this season! We have done this in the past when the robot has had to 'hold' the autonomous game element, while waiting to run - just didn't realize the other benefits doing so offered

Happy coding!