by PaulL » Tue Jan 19, 2010 2:22 am
by PaulL
Tue Jan 19, 2010 2:22 am
I didn't do an update for this past weekend. So, here goes:
Found a problem with my Servo move code using the Sine function. It's quite obvious in retrospect. In summary, it works, as long as you are doing an "end to end" move with Accel and Decel. Anything else (accel to x, decel to other x) will result in a problematic motion curve, which can be seen as a "point" on the motion pulses when graphed in Excel.
I started researching to find what I should do regarding acceleration of motion, ended up in calculus, with the motion / velocity / acceleration formula. In the end, this code works, but it's processor heavy, and there are some "characteristics" regarding velocity that make this method less than appealing. For example, two consecutive moves produce a nice Accel / Decel curve, as long as the periods of each are equal. Once you start to alter the periods, you end up with overshoot and undershoot curves to end at the final desired position. I ended up generating some nice oscillatory graphs of motion, but I don't think my RN-1 would be happy waving his limbs around madly searching for his target position.
This code works, but it has drawbacks. The curve can be made to behave, but it's not as intuitive as I would like.
So, a sine function-based algorithm works for a defined start and end, and the calculus-based Accel / Velocity / Position method works for a defined start and end and more if you're patient in setting up moves. The AVP method (reference to the movie unintentional) shows promise, but I'm not ready to move servos with it without enhancing a UI for it (though, I did go so far as to graph the motions in the Roboard app).
Getting impatient, I decided to build a "move at this speed, start here, end here" method that I call "Linear Motion". No accel / decel, this function mimics the stock behavior of the RN-1 (easy code, really light CPU loading). Realizing that Start here, End there, go at this speed, is the stock means of motion on the RN-1, I figured I should re-acquaint myself with the MRC-3024 to see if I could actually pull out the position data and reuse it with the Roboard (lots of good, useful position data there!). Since I last programmed him, I have a new PC. It has NO serial ports, and I don't have any USB to Serial adapters. To add to that, I have misplaced my programming cable. I built a new one, and installed the Robonova software on the Roboard. There's a sight, seeing the Roboard tethered to the MRC-3024, and moving a single servo using the RoboBasic application over Remote Desktop via ethernet into the Roboard.
I went through the exercise of dumping the source code for the RN-1 into a spreadsheet, and built a few VBA parsing functions to put the G6A, G6D, etc moves into a consistent 1 -> 24 servo format, giving each "set" of positions a name corresponding to the source code function. In the end, I pulled some ~180 positions out of the default RoboNova program code and dropped them into a .csv file. I figured that these motions are already figured out, and I will scale the values and alter the servo directions such that I can use the Roboard to synthesize his stock moves, using the 10 to 190 values scaled to actual PWM durations. That should get him walking a bit more soon than anticipated, and fulfills one of my goals of having him be able to perform all of his stock moves with the Roboard. Yes, I did think about integrating the MRC-3024 WITH the Roboard for use in my RN-1, for about .32 seconds.
I went even farther than that, and have built a servo manager class that invokes servo objects to perform the moves, using the MM Timer calls I found (better than other available timers, in .Net, or in C++, etc, under XP). His moves themselves, however, will be based on RDTSC, CPU Clock Ticks. I will be using the MM Timer to invoke servo position updates, but use CPU Clock Ticks to calculate the actual intended position. I believe this is the most smooth method I can utilize to get smooth motion under XP. And, I can back off the MM Timer as needed (as I can stand, until his motions become jerky) to free up some CPU for other activities. Part of the reason for this is that MM Timer Elapsed events are relentless. If interrupted, they will queue, and execute one after another once enough CPU cycles are available again. I may build a method to prevent that from happening, but all the same, the timer CAN be interrupted, meaning it should not be used as "the" time base for calculating positions, but I will use it for updates to positions, as it is the best timer that can be found under XP.
Right now, I have to debug some code, and chart some graphs in Excel to prove out the motion conversions before I rack some servos with it. I have his legs and stock board pulled, so he can't exactly get up and walk around just yet. Add to that, I bought a blue bracket set for him, along with an I2C Compass, an Accelerometer (bought when I picked up the Roboard), and a set of Grippers. Ultimately, I'd like to build some "Melissa" hands for him, but they have to be able to be used for cartwheels. One thing that frustrates me with Hitec- they release the bracket kits, then only sell the "gold / orange" grippers. I researched removing anodizing and home-brewed anodizing processes today.
The best thing about the gripper kit is the cost of the HSR-8498's in the kit- more to buy them separately than buy them in this kit w/ gripper brackets. Go figure!
I doubt I'll change the color of the grippers, as with the vision of "Melissa" hands stuck in my head, they won't be around for long, not long enough to test color-matching to the Blue bracket set.
I have to say though, I am tempted to put his legs back on and fashion some makeshift mounting for the Roboard to test out this code. If I can have him do stock moves of 16 servos with the Roboard smoothly under XP, I'll be quite a happy camper.
A note about Roboard on the RN-1: It doesn't quite fit. You have to mount it high to correspond to the angles on the aluminum below the arms on the backplate, which puts the board up to the height of the slotted tabs on the top plate of his torso. He will need some protection and mounting holes, so I will take his stock back plate and cut it about .250 inches down his back, and use that angle bracket for Roboard mounting and protection when flipped upward on the new bracket set. That piece will either be re-anodized, or spray painted. I have also been thinking about a Roboard "Roll Cage". I will definitely be ditching the stock chest and back plate, they just don't fit. I was thinking of thermoforming a shell for front and back, but he needs some reinforcement for falls and tumbles (roll cage). I intend to integrate the new body with the antenna for a VT6655 WiFi card I purchased such that the antenna doesn't interfere with his acrobatics. That should be interesting...
As this code matures, I will be integrating what I've learned, providing the Sine and AVP type motions along with the Linear Motion functions. Right now, I have to say, I am curious about what the AVP accel / sustain / decel motions would look like with the stock moves.
In case anyone was wondering, once I have enough code to be of use, yes, I do intend to post it for any / all to use.
Once I have him moving again, my focus for coding will be on I2C, SPI, and the ADC. I also intend to create a "raw" document for how to talk directly with the hardware as I have been doing.
The joke around the house I have right now is, if I can get him to walk and talk at the same time, I'll be happy... (enter XP Speech which I have incorporated already) I hope the 1ghz CPU can do that under XP.... I hope.
Take Care,
Paul
I didn't do an update for this past weekend. So, here goes:
Found a problem with my Servo move code using the Sine function. It's quite obvious in retrospect. In summary, it works, as long as you are doing an "end to end" move with Accel and Decel. Anything else (accel to x, decel to other x) will result in a problematic motion curve, which can be seen as a "point" on the motion pulses when graphed in Excel.
I started researching to find what I should do regarding acceleration of motion, ended up in calculus, with the motion / velocity / acceleration formula. In the end, this code works, but it's processor heavy, and there are some "characteristics" regarding velocity that make this method less than appealing. For example, two consecutive moves produce a nice Accel / Decel curve, as long as the periods of each are equal. Once you start to alter the periods, you end up with overshoot and undershoot curves to end at the final desired position. I ended up generating some nice oscillatory graphs of motion, but I don't think my RN-1 would be happy waving his limbs around madly searching for his target position.
This code works, but it has drawbacks. The curve can be made to behave, but it's not as intuitive as I would like.
So, a sine function-based algorithm works for a defined start and end, and the calculus-based Accel / Velocity / Position method works for a defined start and end and more if you're patient in setting up moves. The AVP method (reference to the movie unintentional) shows promise, but I'm not ready to move servos with it without enhancing a UI for it (though, I did go so far as to graph the motions in the Roboard app).
Getting impatient, I decided to build a "move at this speed, start here, end here" method that I call "Linear Motion". No accel / decel, this function mimics the stock behavior of the RN-1 (easy code, really light CPU loading). Realizing that Start here, End there, go at this speed, is the stock means of motion on the RN-1, I figured I should re-acquaint myself with the MRC-3024 to see if I could actually pull out the position data and reuse it with the Roboard (lots of good, useful position data there!). Since I last programmed him, I have a new PC. It has NO serial ports, and I don't have any USB to Serial adapters. To add to that, I have misplaced my programming cable. I built a new one, and installed the Robonova software on the Roboard. There's a sight, seeing the Roboard tethered to the MRC-3024, and moving a single servo using the RoboBasic application over Remote Desktop via ethernet into the Roboard.
I went through the exercise of dumping the source code for the RN-1 into a spreadsheet, and built a few VBA parsing functions to put the G6A, G6D, etc moves into a consistent 1 -> 24 servo format, giving each "set" of positions a name corresponding to the source code function. In the end, I pulled some ~180 positions out of the default RoboNova program code and dropped them into a .csv file. I figured that these motions are already figured out, and I will scale the values and alter the servo directions such that I can use the Roboard to synthesize his stock moves, using the 10 to 190 values scaled to actual PWM durations. That should get him walking a bit more soon than anticipated, and fulfills one of my goals of having him be able to perform all of his stock moves with the Roboard. Yes, I did think about integrating the MRC-3024 WITH the Roboard for use in my RN-1, for about .32 seconds.
I went even farther than that, and have built a servo manager class that invokes servo objects to perform the moves, using the MM Timer calls I found (better than other available timers, in .Net, or in C++, etc, under XP). His moves themselves, however, will be based on RDTSC, CPU Clock Ticks. I will be using the MM Timer to invoke servo position updates, but use CPU Clock Ticks to calculate the actual intended position. I believe this is the most smooth method I can utilize to get smooth motion under XP. And, I can back off the MM Timer as needed (as I can stand, until his motions become jerky) to free up some CPU for other activities. Part of the reason for this is that MM Timer Elapsed events are relentless. If interrupted, they will queue, and execute one after another once enough CPU cycles are available again. I may build a method to prevent that from happening, but all the same, the timer CAN be interrupted, meaning it should not be used as "the" time base for calculating positions, but I will use it for updates to positions, as it is the best timer that can be found under XP.
Right now, I have to debug some code, and chart some graphs in Excel to prove out the motion conversions before I rack some servos with it. I have his legs and stock board pulled, so he can't exactly get up and walk around just yet. Add to that, I bought a blue bracket set for him, along with an I2C Compass, an Accelerometer (bought when I picked up the Roboard), and a set of Grippers. Ultimately, I'd like to build some "Melissa" hands for him, but they have to be able to be used for cartwheels. One thing that frustrates me with Hitec- they release the bracket kits, then only sell the "gold / orange" grippers. I researched removing anodizing and home-brewed anodizing processes today.
The best thing about the gripper kit is the cost of the HSR-8498's in the kit- more to buy them separately than buy them in this kit w/ gripper brackets. Go figure!
I doubt I'll change the color of the grippers, as with the vision of "Melissa" hands stuck in my head, they won't be around for long, not long enough to test color-matching to the Blue bracket set.
I have to say though, I am tempted to put his legs back on and fashion some makeshift mounting for the Roboard to test out this code. If I can have him do stock moves of 16 servos with the Roboard smoothly under XP, I'll be quite a happy camper.
A note about Roboard on the RN-1: It doesn't quite fit. You have to mount it high to correspond to the angles on the aluminum below the arms on the backplate, which puts the board up to the height of the slotted tabs on the top plate of his torso. He will need some protection and mounting holes, so I will take his stock back plate and cut it about .250 inches down his back, and use that angle bracket for Roboard mounting and protection when flipped upward on the new bracket set. That piece will either be re-anodized, or spray painted. I have also been thinking about a Roboard "Roll Cage". I will definitely be ditching the stock chest and back plate, they just don't fit. I was thinking of thermoforming a shell for front and back, but he needs some reinforcement for falls and tumbles (roll cage). I intend to integrate the new body with the antenna for a VT6655 WiFi card I purchased such that the antenna doesn't interfere with his acrobatics. That should be interesting...
As this code matures, I will be integrating what I've learned, providing the Sine and AVP type motions along with the Linear Motion functions. Right now, I have to say, I am curious about what the AVP accel / sustain / decel motions would look like with the stock moves.
In case anyone was wondering, once I have enough code to be of use, yes, I do intend to post it for any / all to use.
Once I have him moving again, my focus for coding will be on I2C, SPI, and the ADC. I also intend to create a "raw" document for how to talk directly with the hardware as I have been doing.
The joke around the house I have right now is, if I can get him to walk and talk at the same time, I'll be happy... (enter XP Speech which I have incorporated already) I hope the 1ghz CPU can do that under XP.... I hope.
Take Care,
Paul