I’m working on a Wall-e toy conversion making it into a Spark controlled robot over OSC. I’ve basically got everything working, however I have one problem to solve.
If you watch the above video, you may notice that when I trigger some of the servos, they actually interfere with some of the other servos, causing twitching or movement when they shouldn’t (A good example is when I trigger Wall-e’s left hand track, the right hand track also turns when it shouldn’t).
On this project, room is an ABSOLUTE premium so I can’t afford to have separate power supplies so I need to find a way to cut out the chatter as best I can.
I’m not sure if how I connect up all the servos is a problem, as I use a little board to plug them all into to share the power and then send the signal lines to Spark. The Spark is also powered off the same power rail.
I’ve heard adding capacitors in certain places might help, but I’m not quite sure of those places. Can anyone suggest any mods to my power rail I can make to try and minimise the chatter going on?
Wow that’s absolutely super cute @mattbrailsford, and a very sweet technical and mechanical achievement!
I would say try to place a 100uF or larger low voltage 6.3 or 10V (to keep the size small) on the power leads of the affected servo and if possible the servo that is the cause. Right on your servo jumper board would be good.
It seems like the servo is interpreting a change in the pulse width of the neutral PWM output. You could correct this in software by applying a bit of counter rotation pulse width. So for example if it always seems to spin a bit backwards when activating another servo, it might be too close to the backwards throttle point so you can trim it by moving the pulse width a bit closer to the forwards throttle point. This neutral (no motion) zone is called the deadband zone, in which there is a range of values that don’t cause movement. The wider this zone is, the less sensitive the servo or motor control system is to noise and voltage change.
If you have an o’scope, you can monitor the pulse width of the affected servo while operating other servos and see if it’s just noise, a voltage drop or if the Core is changing the pulse width a bit incorrectly. If the latter is true, I believe adding caps won’t help you.
Thank @BDub I like the challenge of converting something and keep it as stock looking as possible. Always a fun task (I have a cool RaspberryPi + Spotify cassette player that’s had a fair bit of attention of late that was a similar challenge)
Unfortunately my electrical knowledge isn’t as good, so always cutting and pasting from places without always knowing exactly what’s going on.
I’ll give the capacitor a try (I think I have some lying around) and I should be able to solder directly to the bottom of the board so shouldn’t require a major mod.
Regarding the trimming, should this be the case even when the servos are released? (when you see me press the button bottom right, that button is told to release / Servo.detach() all servos). Happy to try giving a negative pulse though to see if it helps.
Unfortunately I don’t have an o’scope, just a multimeter so not sure how I to monitor the servos performance.
Thanks so much for the tips thus far, and if you have any other pointer, it’d be greatly appreciated. I’ll go try these out first though.
The cassette player is way cool! I can remember my first cassette player… so much fun.
Oh so I just realized you have proportional controls on both tracks. Perhaps some of the issue is just that the control doesn’t get back to center completely when you go to turn it off. I’m not sure how you can change that with the TouchOSC interface. When you see one track start to move a bit in relation to the other track being driven, try trimming the control on TouchOSC. If it is in fact snapping back to the center… then you’ll have to apply an offset to whatever TouchOSC is saying the current position is. Does that make sense?
Hmmm, I think I should be handling that. The code I use to set the servos is:
void mapServo(Servo &servo, int servoPin, float value, long fromMin, long fromMax, long toMin, long toMax)
{
if(abs(value) >= SERVO_THRESHOLD)
{
if(!servo.attached()) {
servo.attach(servoPin);
}
int tv = map(value, fromMin, fromMax, toMin, toMax);
servo.write(tv);
}
else
{
if(servo.attached())
{
servo.detach();
}
}
}
So if the servo value is below a threshold (less than 10) then it will class it as centred and detach from it, only re-attaching if it falls back outside that threshold (either positively, or negatively).
Hard to say I guess. Is this your attempt to create a deadband zone? I’m just wondering why you wouldn’t just leave them attached. To create a deadband zone would be a good reason. I don’t have any continuous rotation servos so that part is kind of new to me. Instinct is telling me there is no inherent deadband on the CR servo though, since it’s likely operating without a position feedback potentiometer in the servo.
I suppose the zone could be too small and when you think you should be detached, you are not. Maybe add some Serial print statements or LEDs to see if you have attached or detached your servos. You could also play with increasing the SERVO_THRESHOLD to widen the deadband zone, and as soon as the value is less than SERVO_THRESHOLD you can explicitly set the servo.write to whatever OFF is and then detach.
Thanks @BDub, I hand’t thought about needing to set the servos to deadzone before detaching them so will defo give that a try.
In this instance, I’m preferring to detach (especially for the arms) so that the servos are completely released and under no strain. The reason I create this zone in my software is because the TouchOSC controls don’t snap back so I’m having to create a larger zone for absolute zero so it’s not a complete pain to stop them (trying to stop him moving while you found zero on the tracks was a pain).
Thanks again for the advice, tones for me to be trying out so really appreciate it.
