25 oz.-in. isn't too shabby for such a small motor -- especially one that's geared for high speed! And with a higher Vin, one should expect to get even higher values.
In England, asking for a conversion to carat-furlongs is the same as saying that something is worth its length in diamonds/// except in nautical references, in which case carat-leagues refers to depth in pearls.
In this context, I think it would have been suffice to say that these little contraptions are worth their weight in gold.
Google has thought to include Velocity conversions to furlongs / fortnight, (eg 5 mph = 13440 fpf), but it seems they did not think to extend that to carat-furlongs
In this context, I think it would have been suffice to say that these little contraptions are worth their weight in gold.
Here we go again, getting set up for more confusion!
The servo torque rating uses a standard ounce=28.4g
But gold is weighed using the Troy scale, 1 Troy ounce=31.1g
So a Troy ounce weighs almost 10% more than a standard ounce.
But a Troy pound has only 12 Troy ounces, equal to 373.2g
So a pound of gold weighs 18% less than a standard pound.
I prefer my torque measurements in parsecs. To get you started, one foot is equal to 9.8779E-18 parsecs. You can use it to better determine how long it will take your robot to do the Kessel Run. (Just remember not to make the same mistake about parsecs as Han Solo did.)
$ units
Currency exchange rates from www.timegenie.com on 2017-03-08
2980 units, 109 prefixes, 96 nonlinear units
You have: 25 oz*in
You want: carat*furlongs
* 0.44743566
/ 2.2349582
You have: c
You want: furlongs/picofortnight
* 1.8026175
/ 0.55474886
You have: barn*megaparsec
You want: tsp
* 0.62603503
/ 1.5973547
You have: barn
You want:
Definition: 1e-28 m^2 = 1e-28 m^2
Here is my version of a spin driver for the fancy new FeedBack Servo.
It provides control for up to four servos in a single cog. It provides methods Set Position, Check Set Complete, Get Position, Set Fixed Pulse Width, and Set Parameters.
Set Position gets within +- 1 degree of the commanded position.
Here is my version of a spin driver for the fancy new FeedBack Servo.
It provides control for up to four servos in a single cog. It provides methods Set Position, Check Set Complete, Get Position, Set Fixed Pulse Width, and Set Parameters.
Set Position gets within +- 1 degree of the commanded position.
Tom
Thanks for writing the code. I have 3 of the Parallax feedback 360 servos. Your programs works very well with 2 of them. However, one of them can't get through the "full scale changes" section of the demo code. The program appears to lock up.
But I think I have traced the issue to the problem servo not passing the
FBS.CheckDone(servo) <> 0
test.
I have tried changing the constant in
cmp AbsError, #2 wz, wc 'desired accuracy
to higher values or commenting out the spin code above.
The result is that the program will continue through the "full scale changes" section of the demo program, but the values reported for the demo position are way off the command values (e.g. 60 degrees instead of 180 when going from 0 to 180 commanded.
When the program goes to the random command section, the problem servo will only print one time (while the other 2 print the rest of the time), and the one time the problem servo prints, the feedback value is way off the commanded value.
I thought I had a bad servo (and I might), but it works well in a simple Blockly program I wrote where I used a manually set position of one servo (turning the wheel by hand similar to Erco's post) to command a different servo to rotate to that position, and then print both the command and feedback positions. I tried the problem with the servo as either the master or the slave and the program worked both times. The error in the position between the master and slave is from 0 to +/-1. The blockly program is here: blockly.parallax.com/blockly/my/projects.jsp#15742
Because the program runs as a simple "while" loop, it takes a number of printouts before the positions change and settle. Unfortunately, The servo360.h library is not yet in a library I can read, so I don't have any details how their driver works.
The only thing that appears different about the problem servo is that it does not seem to move as fast as the other servos. When going from 0 to 180, the others will 'scream'; the problem one moves fast but without the 'scream' you usually get from a servo moving from one extreme to the other.
I'm thinking your "odd" servo is getting stuck in what I call the "dead zone".
The nominal pulse width is 1500 usec; varying that width either direction makes the servo move one way or the other. Except with these, you have to change the width a LOT to get it to move. If you calculate a delta pulse width that is too small, the servo won't move even though you think you are commanding it. That is why I defined the deltamin parameter.
The attached driver has four methods to tune the four parameters for each servo: SetErrorMax, SetGain, SetDeltaMin, and SetDeltaMax.(There was a method to set all four at the same time; this just makes it a little easier). By setting the DeltaMin a bit bigger, you can force it out of the dead zone. BUT that may very well make it oscillate a few degrees; you may have to set ErrorMax a degree or two bigger.
The top program has a section commented out; you can use this to find the minimum DeltaMin for each servo. Let me know how this works for you. If you like it I'll take out all the scope syncs and put it on OBEX.
I have four servos; three are pretty easy to get along with. The fourth has a wider dead zone than the others. That's what led me to these changes.
I also added a little ramp so they don't jerk as much as before.
Tom,
Thanks for your help. When I tried the new program, I had to set Deltamin to 30 for the 2 good servos and 35 for the problem servo. Then they all worked.
However there was a different problem that occurred during the "full scale changes" part of the program. I only have 3 servos so I had changed the CON part of the program to set CP3 = 0 and FP3 = 0
When I ran the program, I did what you suggest - change the repeat limits.
One thing I am going to try to do is write a C program that runs your PASM in a separate cog. My long term goal will be to put together a C library of functions using the 360 servos. I've done things like that for the SPIASM driver in the PropTool library and tonyp12's 17 segment LED driver for the PPDB.
Because you transfer data between the Spin and PASM using PAR it shouldn't be too difficult (although since it's been a while since I done those, I have a lot of relearning to do. At my age I'm finding that I have filled the ROM between my shoulders, and anything I learn replaces something that isn't recently used.)
I also want to thank you for well commented code, I'm a Spin and PASM novice, and your comments really help me to understand what and how.
One question - at the end of the DAT section you have "fit 300". I've always seen "fit" previously used as "fit 496" to make sure the code doesn't exceed cog memory. Why did you use a different number?
I've ported Tom Crawford's SPIN/PASM servo360 driver to SimpleIDE C (attached). The C program runs the PASM driver in a new cog. I didn't have to make any changes to the PASM.
I found that the parameters, particularly gain and Dmin required different values in the C program than they did in the Spin program. In the spin version, I used a gain of 12 for all 3 of my servos. The C version requires approx gain =18 to 24.
Dmin in the Spin program was 30 for my 2 easy servos and 32 for the problem servo. In the C program, I have to use 38 for all the servos. Even then with the full scale changes (0 to 359 to 0) I had to add a long delay (1.5 to 2 seconds) between sending the position command and checking for complete. I also had to increase the allowable error. I can still have the problem servo freeze occasionally.
Due to the increase in program speed from SPIN to C I had to add a 4 second pause between the rotational demo and the full scale demo to allow the printing of the rotation values to finish before starting the full scale demo.
The organization of the C program is not normal. Since I eventually will make the driver functions into a library I arranged things so I can just lift the driver functions along with the declarations and function prototypes out of the larger C program.
I have a few more things to do on this.
1. Clean up unused variable names.
2. Declare some variables as "volatile"
3. Comment things.
4. Try to make an escape if a servo has a problem getting a valid "complete"
5. Add appropriate pauses to make the demo speed work better.
6. Make the different functions consistent.
7. Consider adding some additional demos.
8. Make an include file and a driver function library.
Tom
Edit 11/11/17 - I corrected a couple of errors in the version I attached 4 posts forward.
0. I am about as far from being a "C" programmer as anybody I know. Both by inclination and ability. That said,
1. I am at a loss to explain why any parameters would need to be changed. The PASM code is in a cog by itself, communicating via values in hub memory; it doesn't care how the commands are issued and the servos certainly don't care.
2. I had to add a long delay (1.5 to 2 seconds) between sending the position command and checking for complete. I don't understand this, either. Only thing I can think is that the equivalent of Position(servo, angle) is in a different cog and the driver checks for completeness before the method can set the Complete flag to incomplete.
3. 4. Try to make an escape if a servo has a problem getting a valid "complete" Yeah, I think this is a good idea. As it is now, if a servo gets completely stuck in the dead zone, nobody will help it escape. I still wish I knew how the original "C" guys dealt with this.
4. 7. Consider adding some additional demos. Agreed. My "demo" was more a test program than a real demo.
Good job. You say this compiles and runs runs under SimpleIDE?
0. I am about as far from being a "C" programmer as anybody I know. Both by inclination and ability. That said,
1. I am at a loss to explain why any parameters would need to be changed. The PASM code is in a cog by itself, communicating via values in hub memory; it doesn't care how the commands are issued and the servos certainly don't care.
I don't understand it myself. On the same computer I ran the spin demo with the params noted above & it worked. When I ran it through C even the good servos would lock up (all would move then sometimes oscillating, sometimes not) when trying to go from 0-359-0 until I changed the params. -- a mystery.
2. I had to add a long delay (1.5 to 2 seconds) between sending the position command and checking for complete. I don't understand this, either. Only thing I can think is that the equivalent of Position(servo, angle) is in a different cog and the driver checks for completeness before the method can set the Complete flag to incomplete.
Same answer as above. All the PASM code should run in cog 1 (the C is in 0). The only thing I can think of is that the C code (in cog 0) gets ahead of something happening (it would have to be the speed of the servo, probably causing some issue with Complete as you noted). I'm not sure that changing gain & DeltaMin as much as I did is the solution, possibly doing something with timing or having to do a few intermediate moves rather than the full 0-360 in one shot.
3. 4. Try to make an escape if a servo has a problem getting a valid "complete" Yeah, I think this is a good idea. As it is now, if a servo gets completely stuck in the dead zone, nobody will help it escape. I still wish I knew how the original "C" guys dealt with this.
Hopefully, Parallax will add the servo360.h to the SimpleIDE library documentation soon.
4. 7. Consider adding some additional demos. Agreed. My "demo" was more a test program than a real demo.
Good job. You say this compiles and runs runs under SimpleIDE?
Yes it runs under SimpleIde. I extracted the files to a folder: SimpleIDE/myprojects/servo360. Start SimpleIDE and open the project. Click on the button in the lower left corner of the SimpleIDE frame and the project window should open. Make sure that the spin program is listed along with the C program. If it is not, in the top of the SimpleIDE menu bar one of the options lets you add a tab (not at my computer so I don't recall which one). An open file menu appears. You will have to set file type to all or spin in order to see the spin file. Then double click on the spin file. That will add the spin file to the project and open the spin file in a new tab. click on the C file tab and then click on the run with terminal button.
Comments
So about 170 mNm for those who use SI units :-)
Each servo is commanded to a new (random) position as soon as it completes the current move.
No idea; who uses carat-furlongs?
SI units are the international standard, and apart from a few hold-outs are used world-wide.
It's complicated...
A furlong is 40 rods... and a carat is 0.2gm.
So, the conversion is quite straight forward.
In England, asking for a conversion to carat-furlongs is the same as saying that something is worth its length in diamonds/// except in nautical references, in which case carat-leagues refers to depth in pearls.
In this context, I think it would have been suffice to say that these little contraptions are worth their weight in gold.
Why erco didn't just say this is beyond me.
BAD ERCO!!!
Google has thought to include Velocity conversions to furlongs / fortnight, (eg 5 mph = 13440 fpf), but it seems they did not think to extend that to carat-furlongs
Multiply by 141.7 carats per ounce. Divide by 7920 inches per furlong.
Thus, this servo has 0.447 carat-furlongs of torque. Good to know!
Here we go again, getting set up for more confusion!
The servo torque rating uses a standard ounce=28.4g
But gold is weighed using the Troy scale, 1 Troy ounce=31.1g
So a Troy ounce weighs almost 10% more than a standard ounce.
But a Troy pound has only 12 Troy ounces, equal to 373.2g
So a pound of gold weighs 18% less than a standard pound.
https://www.jmbullion.com/investing-guide/types-physical-metals/troy-oz/
We all good?
Anytime you want to send me a pound of gold, I will gladly pay the shipping!
Jim
I puzzled the twins today with the classic question, which weighs more, a pound of gold or a pound of feathers...?
So far, Ebay Chna is failing me.
Which you'd expect, as Chna is the southern forest region of Endor. Don't you know anything?!
(Okay, so I saw the latest Star Wars trailer.)
https://www.gnu.org/software/units/units.html
$ units Currency exchange rates from www.timegenie.com on 2017-03-08 2980 units, 109 prefixes, 96 nonlinear units You have: 25 oz*in You want: carat*furlongs * 0.44743566 / 2.2349582 You have: c You want: furlongs/picofortnight * 1.8026175 / 0.55474886 You have: barn*megaparsec You want: tsp * 0.62603503 / 1.5973547 You have: barn You want: Definition: 1e-28 m^2 = 1e-28 m^2It provides control for up to four servos in a single cog. It provides methods Set Position, Check Set Complete, Get Position, Set Fixed Pulse Width, and Set Parameters.
Set Position gets within +- 1 degree of the commanded position.
I was going to try to find you one, but I realized you would post right back with a lower price...
Great info in this thread you all! Other projects have kept my 360 degree servos on the bench... Plenty of other robotic fun in Louisiana though!
I had to open one too, it's just in my nature to know how something works.Device on a Wire
Tom
Thanks for writing the code. I have 3 of the Parallax feedback 360 servos. Your programs works very well with 2 of them. However, one of them can't get through the "full scale changes" section of the demo code. The program appears to lock up.
But I think I have traced the issue to the problem servo not passing the test.
I have tried changing the constant in to higher values or commenting out the spin code above.
The result is that the program will continue through the "full scale changes" section of the demo program, but the values reported for the demo position are way off the command values (e.g. 60 degrees instead of 180 when going from 0 to 180 commanded.
When the program goes to the random command section, the problem servo will only print one time (while the other 2 print the rest of the time), and the one time the problem servo prints, the feedback value is way off the commanded value.
I thought I had a bad servo (and I might), but it works well in a simple Blockly program I wrote where I used a manually set position of one servo (turning the wheel by hand similar to Erco's post) to command a different servo to rotate to that position, and then print both the command and feedback positions. I tried the problem with the servo as either the master or the slave and the program worked both times. The error in the position between the master and slave is from 0 to +/-1. The blockly program is here:
blockly.parallax.com/blockly/my/projects.jsp#15742
Because the program runs as a simple "while" loop, it takes a number of printouts before the positions change and settle. Unfortunately, The servo360.h library is not yet in a library I can read, so I don't have any details how their driver works.
The only thing that appears different about the problem servo is that it does not seem to move as fast as the other servos. When going from 0 to 180, the others will 'scream'; the problem one moves fast but without the 'scream' you usually get from a servo moving from one extreme to the other.
Any ideas?
Thanks
Tom M.
I'm thinking your "odd" servo is getting stuck in what I call the "dead zone".
The nominal pulse width is 1500 usec; varying that width either direction makes the servo move one way or the other. Except with these, you have to change the width a LOT to get it to move. If you calculate a delta pulse width that is too small, the servo won't move even though you think you are commanding it. That is why I defined the deltamin parameter.
The attached driver has four methods to tune the four parameters for each servo: SetErrorMax, SetGain, SetDeltaMin, and SetDeltaMax.(There was a method to set all four at the same time; this just makes it a little easier). By setting the DeltaMin a bit bigger, you can force it out of the dead zone. BUT that may very well make it oscillate a few degrees; you may have to set ErrorMax a degree or two bigger.
The top program has a section commented out; you can use this to find the minimum DeltaMin for each servo. Let me know how this works for you. If you like it I'll take out all the scope syncs and put it on OBEX.
I have four servos; three are pretty easy to get along with. The fourth has a wider dead zone than the others. That's what led me to these changes.
I also added a little ramp so they don't jerk as much as before.
tomc
Thanks for your help. When I tried the new program, I had to set Deltamin to 30 for the 2 good servos and 35 for the problem servo. Then they all worked.
However there was a different problem that occurred during the "full scale changes" part of the program. I only have 3 servos so I had changed the CON part of the program to set CP3 = 0 and FP3 = 0
CON _clkmode = xtal1 + pll16x 'Standard clock mode _xinfreq = 5_000_000 '* crystal frequency = 80 MHz #12, CP0, CP1, CP2 ', CP3 = 0 'servo control pins #8, FP0, FP1, FP2 ', FP3 = 0 'servo feedback pins #0, Servo0, Servo1, Servo2, Servo3 'servo names sync = 0 'engineeringBut after the "full scale changes" cycled through servo 0, 1, and 2 it printed 3 and then stopped since there wasn't any servo3.
I recall that the previous version did not try any servos that had CP and FP = 0.
Thanks again for your help.
Tom
I sure would like to know how the "C" guys are dealing with the dead zone with these servos.
Anyway, I'm glad it is working for you. I have that single cog just about busy.
One thing I am going to try to do is write a C program that runs your PASM in a separate cog. My long term goal will be to put together a C library of functions using the 360 servos. I've done things like that for the SPIASM driver in the PropTool library and tonyp12's 17 segment LED driver for the PPDB.
Because you transfer data between the Spin and PASM using PAR it shouldn't be too difficult (although since it's been a while since I done those, I have a lot of relearning to do. At my age I'm finding that I have filled the ROM between my shoulders, and anything I learn replaces something that isn't recently used.)
I also want to thank you for well commented code, I'm a Spin and PASM novice, and your comments really help me to understand what and how.
One question - at the end of the DAT section you have "fit 300". I've always seen "fit" previously used as "fit 496" to make sure the code doesn't exceed cog memory. Why did you use a different number?
thanks
Tom
I will remove all the instrumentation and re-post. That will get rid of maybe 20 longs.
regards,
tom
I found that the parameters, particularly gain and Dmin required different values in the C program than they did in the Spin program. In the spin version, I used a gain of 12 for all 3 of my servos. The C version requires approx gain =18 to 24.
Dmin in the Spin program was 30 for my 2 easy servos and 32 for the problem servo. In the C program, I have to use 38 for all the servos. Even then with the full scale changes (0 to 359 to 0) I had to add a long delay (1.5 to 2 seconds) between sending the position command and checking for complete. I also had to increase the allowable error. I can still have the problem servo freeze occasionally.
Due to the increase in program speed from SPIN to C I had to add a 4 second pause between the rotational demo and the full scale demo to allow the printing of the rotation values to finish before starting the full scale demo.
The organization of the C program is not normal. Since I eventually will make the driver functions into a library I arranged things so I can just lift the driver functions along with the declarations and function prototypes out of the larger C program.
I have a few more things to do on this.
1. Clean up unused variable names.
2. Declare some variables as "volatile"
3. Comment things.
4. Try to make an escape if a servo has a problem getting a valid "complete"
5. Add appropriate pauses to make the demo speed work better.
6. Make the different functions consistent.
7. Consider adding some additional demos.
8. Make an include file and a driver function library.
Tom
Edit 11/11/17 - I corrected a couple of errors in the version I attached 4 posts forward.
1. I am at a loss to explain why any parameters would need to be changed. The PASM code is in a cog by itself, communicating via values in hub memory; it doesn't care how the commands are issued and the servos certainly don't care.
2. I had to add a long delay (1.5 to 2 seconds) between sending the position command and checking for complete. I don't understand this, either. Only thing I can think is that the equivalent of Position(servo, angle) is in a different cog and the driver checks for completeness before the method can set the Complete flag to incomplete.
3. 4. Try to make an escape if a servo has a problem getting a valid "complete" Yeah, I think this is a good idea. As it is now, if a servo gets completely stuck in the dead zone, nobody will help it escape. I still wish I knew how the original "C" guys dealt with this.
4. 7. Consider adding some additional demos. Agreed. My "demo" was more a test program than a real demo.
Good job. You say this compiles and runs runs under SimpleIDE?
Yes it runs under SimpleIde. I extracted the files to a folder: SimpleIDE/myprojects/servo360. Start SimpleIDE and open the project. Click on the button in the lower left corner of the SimpleIDE frame and the project window should open. Make sure that the spin program is listed along with the C program. If it is not, in the top of the SimpleIDE menu bar one of the options lets you add a tab (not at my computer so I don't recall which one). An open file menu appears. You will have to set file type to all or spin in order to see the spin file. Then double click on the spin file. That will add the spin file to the project and open the spin file in a new tab. click on the C file tab and then click on the run with terminal button.
Tom