Aerius
Canada
Asked
— Edited
Last week we had a discussion about buzzing servo and capability to release it without loosing the mechanical position of the assembly.
One of the issue mentioned was the Inmoov head horizontal movement, where the servo might buzz even in standby.
The next script code , I believe could solution the problem.
SetServoMax(D23, 154 )
SetServoMin(D23,17 )
$Running_Pos=0
:loop
$Present_pos=1
WaitForServoMove(D23 )
####################### RESTART servo ########################
ServoUp( D23, 1 )
ServoSpeed( D23, 0 )
sleep(100)
servospeed(D23,5)
Say("on") # Confirm
######################## Check for servo still mooving #######
repeatuntil($Present_pos = $Running_Pos)
$Present_pos=GetServo( D23 )
Sleep(1000) # as to be long enough for movement to complete
$Running_Pos=GetServo( D23 )
###################### servo released if not mooving #############
if ($Present_pos = $Running_Pos)
Release(D23 )
Say("off") # Confirm
##################### Loop back to top and check for servo move #######
goto(Loop)
endif
endrepeatuntil
Give it a try and everyone is welcome to make it better.
Once again, nice coding.
I may be wrong but it looks here like the script is looking for postion feedback from the ezb. Since servos don't give feedback information won't the Getservo command give you the last postion sent no matter if the servo is still traveling to it or has already arrived? Wouldn't this throw off the timing of the script? Again, I may be reading this wrong.
Dave,
Like you said ... analog servos don't provide the servo position, but the EZB firmware can track the positions sent to the servo, keep the last value and returned when you call GetServo.
The difference to real hardware position, you can query the servo hardware to know is position (moved outside the software)
Under the hood there is no hardware servo function to control the speed, the ezb firmware/software implements the speed control, keeping a delay and adding steps between the current position and the destination position.
the main issue is releasing the servo while the servo is still being moved by the firmware.
A cleaner solution is the firmware take in consideration the release action versus the user script to control servo by servo if is ready to do a release.
The firmware knows about the release call, knows the servo is in motion, when the motion stops do the release.
DJ ?
Thanks PTP. That's just what I was asking. The ezb does not know if the servo has reached its destination or if it's still in motion. All it knows is that it has sent it there and assumes it will be there the next time a movement command is sent. I wanted to know if this new script works with this fact.
Guys, your right. This script needs to be rework. It was to simple to be right.
The only way to use it as it is now, is to make the sleep time longer enough to cover the servo traveling time between min and max before releasing it.
Setting a sleep time that long, will certainly be unacceptable when we move the servo for a small value.
Servo will move at full speed to his previous position if it is released too early.
Nice try though. Don't give up.
To effectively use this script it is necessary to be able to know when the servo comes to a stop. This would be done by the use of a pot.
Just a thought:
Since it is necessary simply to know when a given servo has stopped, I wonder if a current sensor on the main power line to the EZB4 might do the job for all servos. To make it work out the easiest, you would need to run a separate power lead wire to the EZB4 itself. It would be that wire that would be monitored.
This idea would be based on the supposition that a servo will be, by far, the largest current draw where the EZB4 is concerned. There should be a noticeable increase in current when any servo is running and, conversely a noticeable decrease when it stops.
Since you know which one is running during that time, a script would automatically know which one to release when the current draw decreases. The only thing would be the holding current. I'm assuming it will still be less than the running current. This would eliminate the need for variable Sleep periods based on estimates of how long it will take for the servo to go to desired position.
A few turns of this separate positive power wire going to the EZB4 wrapped around a hall effects device might work or a very small resistor placed in-line may also work as a sensing point. Likewise, a coil of wire wrapped around the positive power wire itself. There are any number of devices that can be used to detect current flow. An A-D converter input can be used to monitor the level.
So a looping script could go like this: -Set a variable to the number of the servo that is to be moved. -Start the servo moving. -Begin a loop monitoring the AD port. -When the AD port value goes back down, break out of the loop -Use the variable to release the appropriate servo.
A Command Control call can be used to handle all the details. You would still have to set the variable before using the CommandControl, however.
@WB, that's a very cleaver idea. It's one I'd love to experiment with. I can see how this would work well with one servo starting and stopping. However things may get very messy and completed with many servos of different sizes and load demands moving about. Any ideas on how to script for that kind of dance?
@DaveSchulpius A large diversity of currents would not really matter much. All you would need is to set a level based on the servo type which draws the least current. Anything that reaches that point, or over, would be considered running. Whether it's drawing 1 amp or 30 amps.
The best candidate for the sensor would be a hall effect chip. They have a wide range of currents to which they can respond. Typically, a given sensor setup can take 5 times the rated current. Going over the rated current would be akin to pegging a meter. It's just that if you want a linear output voltage you need to stick to within the rated current. If you go over, nothing bad happens, just that you effectively "pegged" (saturated) the device and you just get the max output even though the current may keep on increasing. Unlike pegging a meter, you don't hurt anything however.
Basically, the hall effect device is placed over a wide circuit trace on a PC board and you run the current to be measured through it. Then you calibrate it running known currents through the trace.
Digikey has a large assortment of such sensors. Sparkfun has a few already mounted on a board. https://www.sparkfun.com/categories/151
Those would probably be the best to experiment with.
If you did calibrate one to the current flow, it would be possible to tell what kind of servo or motor is running by the reading from the device. Generally, however, you will know what servo or motor is running so a script would already know as well.
The problem as I see it would be in cases in which multiple servos/motors are running at the same time. If it is an all or nothing kind of thing as far as the reading is concerned, then the script would have to wait until the last servo is stopped before doing the release. I don't think that will be a big problem. However, if you calibrated the sensor to give a voltage based on the current draw you could tell when a servo has stopped if the servos or motors have a large current differential. For instance if one drew 1A another drew 5A, you could set up a script to look at the amount of current differential when one or the other stopped to determine which needed to be released. A 1A drop would mean the small servo stopped. A 5A drop would mean the large servo stopped. Of course with the holding current still flowing when the servo is stopped, it would not be quite that cut and dried. But it would be workable.
Script-wise it would hinge on telling the script which servos you want to release when the current sensor output drops below the threshold. You could set a variable for each servo you want to release and the script would do that to them when the sensor said it's ok. Or you could set elements in an array to tell the script which ones to release. It would take a lot fewer lines of code to scan an array than individual variables.
Wow WB, that's some impressive deep thought. Thanks for the education and walk through. I'll have to study all this. On the serface it sounds workable but I don't fully understand the whole thing. I've wanting to learn more about hall effect devices. Now sounds like a good time. Thanks
Here is something on hall effect sensors: http://www.sensorsmag.com/sensors/electric-magnetic/measuring-current-with-imc-hall-effect-technology-786
Dave, why don't you hack a servo and use the kangaroo sabertooth combo to dial it in. You know you can do two servos too.
Buzz Control V2 Let's try it again, This version 2 script will monitor a specific servo while it's moving . No matter the speed, the distance, or if the SW ask for a change of direction, the monitoring will follow and adjust itself to finally release the servo when the movement is complete.
This script will automatically apply a release command after a servo has done his last movement If needed, it will be used to stop the buzzing noise when a servo is in standby holding position. 1- make sure there is no physical obstruction 2- define minimum and maximum movement value 3- Caution: use this script only if the mechanism assembly can hold position when the servo is released.
The D23 servo Buzz script will start when a connection is made to EZB
For a demo, run the "Test multiple values" script and observe the servo control window turning to red when released. The servo will be released +/- 1sec after his last movement, no matter how long or at what speed it will do.
SingleServoBuzzControl.EZB
The video is showing the eyes and head scanning for object. Notice the noise when the head is moving (sound is amplified) But at the end, the servo remain silent because it have been release by the Buzz control script.
Guys,
I had similar issues and i made some comments here post #3,#4. I'm working in a solution and the results are good, but I only started last night so is not 100% but i think it can work (at least for me)
I open another thread:
https://synthiam.com/Community/Questions/9081
please leave comments or ask questions.