You're an inspiration WB! I love your axiom about the 10%. It's so true. Like you I'm fighting a motor control PID issue with my B9 arm. It's turning out to be some minor settings that are throwing off the entire elbow motor tune. I don't know what your process of finding bugs in scripts is. To find bugs do you have strategies, methods or do they just pop up and you need to backtrack and rewrite sections to make them go away? With PID motor control issues like I'm the ones I'm fighting, engineers usually have strategies or methods of finding the best settings in the software for smooth motor movement. They use the Z-N Method (Ziegler-Nichols), C-C Method (Cohen-Coon), T-L Method (Tyreus-Luyben), exc. Most often engineers in frustration will resort to the methoid I usually use all the time; the WAG Method (Wild A** Guessing). I was just curious if this last method ever pops up in your field of interest?
@fxrtst I just saw the clip you posted over at the other thread...amazing! I will have to take a look at that sequencer you used! I hope that we will be able to transfer correctly timed motion from 3ds max to ARC soon, thanks to @WBS00001 who made this project possible...my rudimentary scripting abilities are way to limited to create something as sophisticated!
I will supply a rigged JD with animation control so everyone interested will have a common testing scene for creating motion to be played back on a JD!
I am on the train for eight hours today...so hopefully I can make some progress!
Yes still interested. The sequencer is free software created by Flowbiotics. It controls any brand of the SSC-32. For that example I used the new usb version from Lynx . You can also connect 4 inputs or use the a PS controller.
@Dave_Schulpius
Thank you for your thoughtful praise. This rambling post may disabuse you of the notion of my being an inspiration (or even of any use at all), however. But I thought I should answer in some way before more time passes.
WAGs seem to be a way of life in many fields, not the least of which is software. That's where all that testing comes in. You just try anything out of frustration. It can often turn out to be the source of the problem even though you thought it would be wrong. You just could not see how it could be the source of the problem until you see that it IS the source of the problem. Then you can backtrack and figure it out. Sort of like writing a mystery novel backwards. Start at the end and figure out how that end came about.
The advantage in software, however, is the guess can be tried and implemented much easier than in a mechanical system and results can be seen immediately. That is one of the reasons I changed from electronics as my fun thing of choice to software. Same mental challenge, none of the physical mess. Not to mention instant results.
In this particular case, most of my problems with the software is simply out of ignorance. It's the usual steep learning curve and, with enough research and testing, I manage to get things going ... eventually. Other times I just have to stop and think of another way to proceed. Good or bad just another way. And then there are the "that's impossible" things that occur. Eventually I find it is indeed possible and its because I forgot a comma or a pair of parenthesis at a certain point or had to enclose some part of the code in them at another. Little things, that can take forever to track down.
Mainly though, it's a process of getting better at analyzing the symptoms and coming up with an appropriate diagnosis. Getting better at looking at the pieces and what the crash report is really saying that finally gives me a clue as to what's wrong.
I think that is much like what you are doing with the tuning control. Controlling a process through a PID loop is one of the hardest things to do, period. People study that problem for all their lives. Get degrees in the field even. Write copious numbers of books on the subject and come up with all sorts of equations.
I was sent to a couple of courses at Allen Bradley, in PID control by the company I worked for at the time so I could better know how to control a group of machines that worked in tandem to produce a product. What I learned from that, plus talking to people who had done that sort of thing for years, as well as educating myself on the formulas and techniques, came down to one thing. All that stuff just gets you close. After that you have to tweak it. Seemingly endlessly.
And that is where you are now, apparently. The advantage someone who has done that sort of thing for years would have in your situation is their ability to read the symptoms and come up with a diagnosis. They know, by observing what is happening and, what part of the control is making that happen like it is. That is to say, is it the Proportional, the Integral, or the Differential portion of the PID control process which needs adjusting? That is the trick.
I had hoped to be of more help when writing a response to your post by looking more closely at your posts on the B-9 but I just have not had the time to do so. Usually that sort of thing is for connecting disparate units of something and adjusting the overall process so as to be able to adjust the input side so as to get the output side to do what is desired. Because there is a delay involved in that sort of process, the PID controller is employed to attempt to better respond to variations in the overall loop, especially the input, so as to maintain a good, average output. They don't try for perfection, just a good, statistical average. Usually the process is so slow there is time to do that.
In your case the process is fast, but has repeatable variations in loading as the arm moves through it's course. The tuning process is trying to smooth out those variations for better motion. At least I think that's what is happening. As I said, I had hoped to get a better grasp on the problem before posting.
Having said all that, in my usual overly wordy way, were it my problem, I would backup and punt. I have no real idea why the first arm seems to have worked out so well compared to the second one. Perhaps it only seems to have worked out that way. Regardless, I would go back and see if there wasn't some way to use a linear actuator for the operation. I know you have space constraints, but I would be looking for a way to overcome that. For example, it is not currently possible to place servos in the fingers of a robot hand so the movement is done through a linkage such that the servos can be placed in the arm or the palm. Similarly, it may be possible to locate the actuator vertically someplace where there may be more room and link it to the slide mechanism in some creative way. Some of them have built in potentiometers which could eliminate the need for that thin variable resistor you are using now. Come to think of it, It's even possible that device is what is causing this tuning to be so much more difficult. Maybe this one is noisier or has flat spots on it. It is what provides the feedback for the loop, is it not?
Sorry if I'm way off here in suggesting a linear actuator, I know it's been suggested before, but it would be my device of choice here. Hopefully this lengthy missive I've written has been of some small benefit nonetheless. When I have time, I will look more closely at the problem, but that is no help to you NOW when you need it. So I have offered what I can off the top of my odd but reasonably functional head. By the time I get around to being of better assistance, you will have already solved the problem anyway.
Cheers, and try to have fun, difficult though it may be sometimes.
Well, WB, as usual you've astounded me. Thanks for the thoughtful reply to my post comparing our two processes. I'm flattered and thankful you're willing to lend me your brainpower and expertise with my issue. However I don't want to hijack this thread and I know you have lot of other things on your plate.
I've been able to fine tune my arm PID to the point that I think it's acceptable. I really won;t know how close it is till I have it mounted on the B9 and start feeding it movement commands from ARC. That won't be for weeks or months down the road. At time I'll post the results in my project thread. If needed and you have the time then I'd welcome your experienced and wise input. Thanks again!
Hey guys...as I am sort of finished with my rig of the virtual JD, that will be used to drive the animation of the real world model by using a max script which @WBS00001 is currently developing, I thought I will post the progress to get more people interested in our project!
The software used is currently available on the Autodesk website for download, and it can be used for free if it is on a student licence...I will attach the scene, so hopefully anyone interested in animating motion for a JD can have fun fooling around with it!
The rig offers custom blending of forward and inverse kinematics for the legs, all the rest is straight Forward Kinematic!
It will be still some tweaking until me and @WBS00001 find the final working solution, but I could not resist posting it here...hope you guys gonna like it!
That's great! Carry on gentlemen!
You're an inspiration WB! I love your axiom about the 10%. It's so true. Like you I'm fighting a motor control PID issue with my B9 arm. It's turning out to be some minor settings that are throwing off the entire elbow motor tune. I don't know what your process of finding bugs in scripts is. To find bugs do you have strategies, methods or do they just pop up and you need to backtrack and rewrite sections to make them go away? With PID motor control issues like I'm the ones I'm fighting, engineers usually have strategies or methods of finding the best settings in the software for smooth motor movement. They use the Z-N Method (Ziegler-Nichols), C-C Method (Cohen-Coon), T-L Method (Tyreus-Luyben), exc. Most often engineers in frustration will resort to the methoid I usually use all the time; the WAG Method (Wild A** Guessing). I was just curious if this last method ever pops up in your field of interest?
@fxrtst I just saw the clip you posted over at the other thread...amazing! I will have to take a look at that sequencer you used! I hope that we will be able to transfer correctly timed motion from 3ds max to ARC soon, thanks to @WBS00001 who made this project possible...my rudimentary scripting abilities are way to limited to create something as sophisticated!
I will supply a rigged JD with animation control so everyone interested will have a common testing scene for creating motion to be played back on a JD!
I am on the train for eight hours today...so hopefully I can make some progress!
Good to see that you are still interested!
Yes still interested. The sequencer is free software created by Flowbiotics. It controls any brand of the SSC-32. For that example I used the new usb version from Lynx . You can also connect 4 inputs or use the a PS controller.
@Dave_Schulpius Thank you for your thoughtful praise. This rambling post may disabuse you of the notion of my being an inspiration (or even of any use at all), however.
But I thought I should answer in some way before more time passes.
WAGs seem to be a way of life in many fields, not the least of which is software. That's where all that testing comes in. You just try anything out of frustration. It can often turn out to be the source of the problem even though you thought it would be wrong. You just could not see how it could be the source of the problem until you see that it IS the source of the problem. Then you can backtrack and figure it out. Sort of like writing a mystery novel backwards. Start at the end and figure out how that end came about.
The advantage in software, however, is the guess can be tried and implemented much easier than in a mechanical system and results can be seen immediately. That is one of the reasons I changed from electronics as my fun thing of choice to software. Same mental challenge, none of the physical mess. Not to mention instant results.
In this particular case, most of my problems with the software is simply out of ignorance. It's the usual steep learning curve and, with enough research and testing, I manage to get things going ... eventually. Other times I just have to stop and think of another way to proceed. Good or bad just another way. And then there are the "that's impossible" things that occur. Eventually I find it is indeed possible and its because I forgot a comma or a pair of parenthesis at a certain point or had to enclose some part of the code in them at another. Little things, that can take forever to track down.
Mainly though, it's a process of getting better at analyzing the symptoms and coming up with an appropriate diagnosis. Getting better at looking at the pieces and what the crash report is really saying that finally gives me a clue as to what's wrong.
I think that is much like what you are doing with the tuning control. Controlling a process through a PID loop is one of the hardest things to do, period. People study that problem for all their lives. Get degrees in the field even. Write copious numbers of books on the subject and come up with all sorts of equations.
I was sent to a couple of courses at Allen Bradley, in PID control by the company I worked for at the time so I could better know how to control a group of machines that worked in tandem to produce a product. What I learned from that, plus talking to people who had done that sort of thing for years, as well as educating myself on the formulas and techniques, came down to one thing. All that stuff just gets you close. After that you have to tweak it. Seemingly endlessly.
And that is where you are now, apparently. The advantage someone who has done that sort of thing for years would have in your situation is their ability to read the symptoms and come up with a diagnosis. They know, by observing what is happening and, what part of the control is making that happen like it is. That is to say, is it the Proportional, the Integral, or the Differential portion of the PID control process which needs adjusting? That is the trick.
I had hoped to be of more help when writing a response to your post by looking more closely at your posts on the B-9 but I just have not had the time to do so. Usually that sort of thing is for connecting disparate units of something and adjusting the overall process so as to be able to adjust the input side so as to get the output side to do what is desired. Because there is a delay involved in that sort of process, the PID controller is employed to attempt to better respond to variations in the overall loop, especially the input, so as to maintain a good, average output. They don't try for perfection, just a good, statistical average. Usually the process is so slow there is time to do that.
In your case the process is fast, but has repeatable variations in loading as the arm moves through it's course. The tuning process is trying to smooth out those variations for better motion. At least I think that's what is happening. As I said, I had hoped to get a better grasp on the problem before posting.
Having said all that, in my usual overly wordy way, were it my problem, I would backup and punt. I have no real idea why the first arm seems to have worked out so well compared to the second one. Perhaps it only seems to have worked out that way. Regardless, I would go back and see if there wasn't some way to use a linear actuator for the operation. I know you have space constraints, but I would be looking for a way to overcome that. For example, it is not currently possible to place servos in the fingers of a robot hand so the movement is done through a linkage such that the servos can be placed in the arm or the palm. Similarly, it may be possible to locate the actuator vertically someplace where there may be more room and link it to the slide mechanism in some creative way. Some of them have built in potentiometers which could eliminate the need for that thin variable resistor you are using now. Come to think of it, It's even possible that device is what is causing this tuning to be so much more difficult. Maybe this one is noisier or has flat spots on it. It is what provides the feedback for the loop, is it not?
Sorry if I'm way off here in suggesting a linear actuator, I know it's been suggested before, but it would be my device of choice here. Hopefully this lengthy missive I've written has been of some small benefit nonetheless. When I have time, I will look more closely at the problem, but that is no help to you NOW when you need it. So I have offered what I can off the top of my odd but reasonably functional head.
By the time I get around to being of better assistance, you will have already solved the problem anyway.
Cheers, and try to have fun, difficult though it may be sometimes.
Well, WB, as usual you've astounded me. Thanks for the thoughtful reply to my post comparing our two processes. I'm flattered and thankful you're willing to lend me your brainpower and expertise with my issue. However I don't want to hijack this thread and I know you have lot of other things on your plate.
I've been able to fine tune my arm PID to the point that I think it's acceptable. I really won;t know how close it is till I have it mounted on the B9 and start feeding it movement commands from ARC. That won't be for weeks or months down the road. At time I'll post the results in my project thread. If needed and you have the time then I'd welcome your experienced and wise input. Thanks again!
Hey guys...as I am sort of finished with my rig of the virtual JD, that will be used to drive the animation of the real world model by using a max script which @WBS00001 is currently developing, I thought I will post the progress to get more people interested in our project!
The software used is currently available on the Autodesk website for download, and it can be used for free if it is on a student licence...I will attach the scene, so hopefully anyone interested in animating motion for a JD can have fun fooling around with it!
The rig offers custom blending of forward and inverse kinematics for the legs, all the rest is straight Forward Kinematic!
It will be still some tweaking until me and @WBS00001 find the final working solution, but I could not resist posting it here...hope you guys gonna like it!
Looking very nice! Great job. I look forward to rigging and animating my own robots and characters with this plug in.