After a few days of research I decided to use a AS5045 rotary magnetic encoder. This is a 12-bit (0-4096 over 360 degrees or ~0.08 degrees per count) encoder that uses a small magnet rotating over the chip to output either PWM or SSI. This should give the resolution needed to more precisely control the PID loop.
Once I figured out what chip I wanted, next I looked for any commercial solutions that incorporated the chip, circuit board and magnet into a single, easy to use package. There are several available however at a cost that was beyond my budget. I was starting to figure out how to do my own circuit boards and housing when I ran across the HH-12. This solution is being used to control motorized telescopes and a gentleman in Germany is creating these. He houses everything in a potentiometer case making for a small and neat package. I ordered 6 to try out on the coxa to replace the potentiometer I am currently using. If this works out, then I will have to see if it is possible to replace the potentiometers in the linear motors with them also.
Once they arrive I will be diving into the data sheets for the chip and see if the SSI communications protocol it uses is compatible with anything in the Propellor library otherwise I'll have to write something up myself.
Bob,
I assume the HH-12 is based upon the AS5045. Duane Deign developed som code to run on the prop for that device I will see if I can find it and link to it for you.
Jim
Edit attaching link: http://forums.parallax.com/discussion/138736/magnetic-encoder-project-as5055/p3
Hope this gives you a jump start.
Edit 2: I just found the HH-12 and yes it is based upon AS-5045. I used Duane's code as a basis for what he calls the HH-05 and it worked well. My problem with the the sensor was the same as yours, the housing. Look into the code as he was able to get them to function in yhe cascade mode which could get you 6in 1 cog.
Jim
Thanks for the link.I had seen the thread with the project back in 2012 and his work at making circuit boards during my recent research. That's what helped me look into this chip and subsquently finding the HH-12. I hope that these will have enough resolution to solve my problems! When they arrive I will do some testing and figure out how to mount them.
The coxa mount should be relatively simple since I'm already using a 20 turn precision pot, should just have to replace the parts. The only problem might be if the shaft is too short, then I will need to come up with some type of extender on the lathe.
Replacing the pots in the linear drives might be trickier, its been a while since I've opened one of these up so I'm not sure how much space is available inside the housing. It might be possible to drill a hole through the housing and mount it outside with an extension inside the housing to the gear train. This would require changing the mounting bracket to allow more space for an external pot.
Another way would be to mount the femur and tibia encoders to the main vertical support bars and tie the encoder shaft to the parts that are moved by the motors. This would take more work to figure out since it wasn't initially designed with this in mind and I don't want to have something that isn't visually neat or could be damaged easily.
I got my HH-12 magnetic rotary encoders in the mail, now I need to try them out!
It is a very compact unit, smooth rotation and looks very nice.
Since I'm also looking to potentially use this to replace the potentiometer in the linear drives, I opened one of them up to see its configuration.
The encoder will fit in the available area without having to modify the housing. The encoder uses 5 wires vs only 3 for the pot but that can be worked out. A bigger concern is that the shaft of the encoder is 6MM and the pot is 0.25", the encoder is 0.15" smaller so the gear doesn't fit. Also, the hole in the mounting plate is too large, making a very sloppy fit. The hole can be fixed by machining a custom washer to take up the slack. Increasing the shaft size will take a little more thought. The shaft is made of either brass or bronze so I need to do some research into possible methods for increasing its size without damaging the unit.
Tomorrow I will start some coding tests and see how well it works and the speed of the data coming into the prop.
Try a piece of brass tubing from a hobby shop to make up the difference in the shaft diameter. You may have to sand and slit the tubing it to make it fit.
Try a piece of brass tubing from a hobby shop to make up the difference in the shaft diameter. You may have to sand and slit the tubing it to make it fit.
+1. That's not a high speed power application on those gears, so you should be able to retrofit a spacer on there with tubing and epoxy. Accuracy is important to avoid binding & backlash. Clamp the rig down and check the gear for runout with a dial indicator as the epoxy sets up.
If you do this mod several times, your last one will the best one.
What's the angular resolution on those magnetic encoders? Is it a full 360 degrees? Pretty cool stuff. I'm surprised Duane hasn't chimed in here yet, he's quite the encoder fanboy.
After a few days of research I decided to use a AS5045 rotary magnetic encoder. This is a 12-bit (0-4096 over 360 degrees or ~0.08 degrees per count) encoder that uses a small magnet rotating over the chip to output either PWM or SSI. This should give the resolution needed to more precisely control the PID loop.
from his first post on the topic.
Yeah, I too am surpised that Duane has not dropped in of the topic. I believe I sent him a PM.
Jim
Try a piece of brass tubing from a hobby shop to make up the difference in the shaft diameter. You may have to sand and slit the tubing it to make it fit.
Using a brass tube was my initial thought. I found some .25 OD brass tube at the local hardware store, I will have to do some work to get it to fit over the 6MM shaft but that shouldn't be too hard to do, besides, that's what I have the machine shop in the basement for fixing things like this. Tonight I want to do some programming and see what kind of output I get from the unit. I'll be starting with Duane's code that he posted a few years back and modify it as needed. I like the fact that you can also daisy chain these together especially since I only have one spare cogs now!
K&S sells aluminum and brass tubing at our LHS in all nesting sizes. Use whichever material is easier to slit, even using a cutoff wheel in a Dremel.
K&S brass tube is what I found. I used the lathe to drill the tube out to just under 6MM, now I will use sandpaper to get the final diameter. I'm thinking of getting a tight press fit with a touch of superglue as a means to prevent the tube from slipping.
I've been testing the program from Duane and got an output pretty quickly. Unfortunately the output is wildly variable and constantly says it has an error in between readings. Sometimes I will get a whole series of outputs but again the numbers aren't even close to one another. Duane has an averaging routine built into the program but I thought that when the shaft isn't moving that the values would stay relatively consistant, I'm getting value swings of several hundred (the equivalent of around 30 degees of shaft motion).
I will post on Duanes original thread if he has any insight for me.
Something isn't right with your software, wiring or circuitry if your values are changing that much. It's a precision pot, right?Are you RCtiming it, sigma Delta, or ADC?
Bob,
I was unsuccessful i finding my old files, I finally remembered that the computer that I was using at the time died a horrible and violent death and I may not have had the latest and greatest backed up. I lifted this link from the middle of Duane's thread that gave what I thought was stable code at the time. [url="AS5055Demo120526a - Archive [Date 2012.05.26 Time 15.21].ziphttp://"]AS5055Demo120526a - Archive [Date 2012.05.26 Time 15.21].zip[/url]. futher down in the thread is a video of it working.
Jim
Something isn't right with your software, wiring or circuitry if your values are changing that much. It's a precision pot, right?Are you RCtiming it, sigma Delta, or ADC?
Duane sent me a copy of his old 3 wire file when I asked on his other thread, I'll be trying this out tonight.
The test setup I'm using is outside of the robot, just an experimenter board connected directly to the encoder. I don't have anything else running that would cause this type of problem. The encoder uses SSI to communicate the results serially, the initial setup does output values but they are very erratic, not what I was expecting. Now the software was designed for connecting directly to the encoder chip and with the HH-12 I don't have that option, only the CLK, CS, and Data out line. I don't know how the internal circuitry is put together, it doesn't appear to easily disassembled so I can check out the circuitry inside the housing. (I'm going to send the vendor a request for the schematic, that may help also).
Slowly working on the encoder code. More testing shows that the output is not consistent but for a given shaft position the output values fluctuate between around 4-6 specific numbers. Move the shaft some more and I get a different set of numbers. Not sure what that means yet but more coding and testing will be needed. Unfortunately I will be working the night shift pretty much for the rest of the year and that leaves little time to play. I'm looking forward to retirement even more now!
Success! I started from scratch and bit-banged out some SSI code based on the vendor's data sheet and now I'm getting very consistent and repeatable output from the HH-12 encoder. I am not seeing any jitter when the shaft is moving and the output is constant when stationary. The output changes from 0-4096 for a full 360 degree rotation. That comes out to around 0.087 degrees for each value change (360/4096). I can dedicate one cog to running this process and use it to input to the PID code.
The first place I am going to use the encoder is the coxa, the side to side movement of the leg. The easiest mechanical installation is to replace the existing potentiometer with the encoder. I need to make an adapter for the HH-12 shaft as it is too short to engage the main gear. If I make the mechanical connection here then I have to take into consideration that the gearing results in about 2.5 turns of the pot shaft as the leg moves from one side to the other. Since this would result in 3 separate 0-4096 transitions, the code needs a counter since I couldn't get an absolute position from the leg for any given reading. This could cause some initialization issues where each leg would have to figure out its current position when power is applied.
A better move may be to connect the encoder shaft directly to the leg so that it is only measuring the +/- 60 degree leg movement. That would be using only 120 degrees of a single rotation so the output would be the absolute location. The encoder output would be limited to a value change of 1365 on the output since it isn't using the full range of the encoder. Mechanically doing this will be harder since the leg was not designed this way and the pins that the leg rotate around are stationary and don't normally rotate with the leg. Time to put on the thinking cap again!
Once I get through this problem then I'll get back to figuring out putting the encoders in the linear actuators.
I am looking at all options right now. I prefer to not have to make major changes to the leg design as it works pretty well. I am leaning toward a modification to the upper support bracket. There are threaded holes in both the stationary and mobile sections that were originally intended as support locations for sensors that I haven't installed. I can re-purpose those locations and add on a encoder support mechanism. There are about 2-3 ideas I am considering on the design change.
After spending a lot of time staring at the leg support struture and devising several potential methods for translating the side to side motion of the leg to rotate the encoder, I think I've come up with the potentially least intrusive and simplified mechanical connection. The upper leg swing connection has 2 pre-drilled and tapped holes on either side of the pivot point. I plan on attaching model airplane push rod connectors to both of connection points and attach the pushrods to a two sided arm that attaches to the encoder shaft (like a servo in a model airplane used to move the elevator). This means only drilling one hole in the upper bottom stationary connector to mount the encoder and then fabricating the arm for the encoder shaft. This way as the leg moves, the linkages will push and pull the encoder arm causing it to turn. Since I only need the shaft to rotate 120 degrees, the limited rotation is acceptable. I will order some aircraft connectors and install them on my next day off and test to make sure it will work without interference.
There are a couple of other ideas I have for making this work if this idea doesn't pan out, they are mechanically more complex and potentially prone to issues in the future. I like ideas that are simple, easy to maintain and still look elegant.
I built an arm for the encoder and have tried 2 methods of connecting the arm to the coxa of the leg. I tried 2 springs, one on each side but I don't get consistant results for a given position. I think if I use shorter springs so they are always extended I might see better results. The other method was using some stiff wire instead of springs but there is some 'slop' now. Possibly a wire with a couple of coils in it to absorb any mechanical looseness might be the best of both worlds. I will try it out tomorrow and see how well that works. I didn't use the model airplane clevis or tie rods as I can't seem to find any that are the right size, they are either way too small or huge.
I started integrating the magnetic encoder into the main leg program and determined that I didn't have an extra cog to play with. I ended up using what I thought was my spare cog on the 4 way serial port since I needed 2 of them. I could use the ADC cog in the future if I totally move away from the ADC (I don't want to do that as the ADC can be used for various sensors I want to add in the future). I could remove one of the 4 port serial objects for now until I figure out how to go on (maybe someone will write a 6 port serial object someday!).
I should be able to post some photos soon on this new layout once I'm happy I've got a workable solution for connecting the encoder and the leg.
How many serial links are you using simultaneously? (ie why do you need two four-port cogs?)
Out of interest, can you list your cog usage?
I was wrong, I'm only using a single 4 port serial port on the leg controllers (the master computer uses 2, 4 port serial ports for communicating to 6 leg controllers). My cog list for the leg controller is as follows:
- Main program
- Microchip 3208 8 channel ADC uses 2 cogs (ADC_Input_Driver and I run the whole thing in its own cog continuously)
- 4 port serial port (pcFullDuplexSerial4FC)
- Coxa motor PID
- Femur motor PID
- Tibia motor PID
- HB-25 controller (jm_servo8)
I could see if there is a way to run the ADC code differently, right now I run it in its own cog and use it to continually update the feedback variables.
In the meantime I disabled the tibia PID cog so I could troubleshoot code. I got the encoder to run with good output data in the coxa PID loop. I just had a thought that the encoders are unique for each motor, so there are only a few specific places that it is called within a PID loop. I could just not run it in its own cog and call the routine when needed while inside the CoxaPID cog. The only time the encoder is checked outside the CoxaPID cog is during initialization when the slope is calculated. I just can't initialize the CoxaPID cog until this step is complete. This might be a way to circumvent the need for another cog.
Today's tests included using the current control method to move the leg back and forth and observing the raw data output from the magnetic encoder as I moved from one extreme to the other. The output tended to be consistent +/- 2 counts. Of course this was after I removed the springs (the output was very inconsistent using springs) and put in a stiff wire to connect the moving part to the encoder.
I've been playing for a while so time for a break until tomorrow, I'll try out the idea above and see if that works. Then I can code in the encoder in place of the potentiometer.
Bob,
Thanks for the update. Since you have switched to the HH-12 encoder, do you still Need ADC?
Jim
I still have the potentiometer feedback from the linear actuators that I haven't converted over yet and there are some future mods that will require an ADC input.
I took out the encoder code from running in its own cog and am incorporating it into the cog for the coxa PID loop. Came up with some errors that were causing problems but after thinking about it I believe I know what I did wrong. I'll try again tonight and see if I can get it running right.
The coding changes worked and I am running the PID loop using the magnetic encoder as the feedback device. Just with what I have seen so far I was able to greatly reduce the deadband around stopping at the final position so I should get better accuracy when moving. I have a couple of bugs to work out, the calibration routine isn't moving the coxa motor any longer (the other motors still work fine) and the math for calculating the initial coxa position keeps coming up with the wrong value. Manually calculating the position using a calculator and the supplied input values does give the right answer so that is a problem to ponder, but it isn't critical to operation. The leg is about 15 degrees off of where I want it to be for any given command but that could be just a calibration issue, and updating the minimum and maximum values should clear that up.
I'm going to play with this a bit longer and tweak the PID code and see if I can get 0.1 degree movement out of the motor. It should be possible to get that degree of accuracy. Repeatability looks pretty good also but I need to add a second connecting rod to the encoder arm to take up any additional slop
I think you could reduce the number of required cogs...
1) as you already noted, you should be able to use a single cog for ADC, just change the driver to update an eight element array constantly with the readings
2) I suspect you could use just one PID cog, time-multiplexed between the three motors, as I don't think one PID loop would take a large fraction of a cog's time
Thanks for the suggestions Bill. I did have one experiment where I tried to combine the PID loop into a single cog for all three motors but it got so complex with all the variables for each motor that I got lost just trying to troubleshoot it! The ADC cog is the one I will be shooting for next, I would just modify the driver to run continuously and output any ADC input on command.
In the meantime the encoder is working pretty good. I figured out that I had a math error that was giving me the 15 degree offset, that's fixed now. I found and corrected the calibration routine so it seems good now. Still have to add another 'arm' to the encoder from the leg to help take up any slack in the movement of the encoder.
Next event will be to start running the gait sequence from the master computer and see if the overall leg movement has improved.
Re/PID cog, there is a way to really simplify running multiple PID loops.
Keep the cog mostly as is, with the following changes:
hub byte variable UPDATE, value 0...3, 0=idle, 1/2/3 calculate PID for loop 1/2/3
hub variables CV/SP/PV etc for each of the loops, in three consecutive blocks
PID cog monitors UPDATE. When zero, keeps monitoring until non-zero
When finally non-zero:
- load variables for the loop (1..3 or higher) into the variables in the cog
- process via PID
- save variables
- set UPDATE to zero (you can also set UPDATE1/UPDATE2/UPDATE3 if needed to tell other cog that PID is done for that loop)
This way the PID cog only has to deal with a single set of variables, yet you can run three (or more) PID loops in one cog.
I built a wire bending jig for the linkage wires to the coxa encoder since I couldn't find anything else I liked. I made the first set of springs just a bit too short so they keep pulling out of the encoder arm. The next set will be about 1/2 inch longer and I will use a screw at both ends to anchor them. My initial runs using them went well, the readings are consistent and reliable. The PID loop runs much smoother now for the coxa movements.
In other mechanical news, I have been thinking about how to use these encoders on the femur and coxa movements. After a lot of deliberation I decided not to replace the linear actuator potentiometer with an encoder. The main reason is that the encoder measures 0-4096 in 360 degrees of motion. Since the potentiometers rotate about 3600 degrees this would require some means of counting the rotations and maintaining that reading between leg controller power cycles. Although I have used the upper portion of the EEPROM to store data like this, it requires another cog for I2C communications. If the current leg position data is not stored then some type of calibration routine would be required during each startup. Although there are ways around each of these issues, I think I have a better idea. I will use the encoders to directly measure the angle of the two sides of the parallelogram that are controlled by the 2 linear actuators. I would mount the encoders on each side of the leg beside the main pivot. An arm attached to the encoder would then be attached to the 2 sides. This allows direct reading of the angle within the 360 degree rotational capabilities. I envision machining a delrin housing for the encoder that will attached to the lower section of the leg supports. I'm still thinking out the problem and have to put some of these ideas into the CAD/CAM program and see how it turns out.
Comments
Once I figured out what chip I wanted, next I looked for any commercial solutions that incorporated the chip, circuit board and magnet into a single, easy to use package. There are several available however at a cost that was beyond my budget. I was starting to figure out how to do my own circuit boards and housing when I ran across the HH-12. This solution is being used to control motorized telescopes and a gentleman in Germany is creating these. He houses everything in a potentiometer case making for a small and neat package. I ordered 6 to try out on the coxa to replace the potentiometer I am currently using. If this works out, then I will have to see if it is possible to replace the potentiometers in the linear motors with them also.
Once they arrive I will be diving into the data sheets for the chip and see if the SSI communications protocol it uses is compatible with anything in the Propellor library otherwise I'll have to write something up myself.
Bob
I assume the HH-12 is based upon the AS5045. Duane Deign developed som code to run on the prop for that device I will see if I can find it and link to it for you.
Jim
Edit attaching link: http://forums.parallax.com/discussion/138736/magnetic-encoder-project-as5055/p3
Hope this gives you a jump start.
Edit 2: I just found the HH-12 and yes it is based upon AS-5045. I used Duane's code as a basis for what he calls the HH-05 and it worked well. My problem with the the sensor was the same as yours, the housing. Look into the code as he was able to get them to function in yhe cascade mode which could get you 6in 1 cog.
Jim
The coxa mount should be relatively simple since I'm already using a 20 turn precision pot, should just have to replace the parts. The only problem might be if the shaft is too short, then I will need to come up with some type of extender on the lathe.
Replacing the pots in the linear drives might be trickier, its been a while since I've opened one of these up so I'm not sure how much space is available inside the housing. It might be possible to drill a hole through the housing and mount it outside with an extension inside the housing to the gear train. This would require changing the mounting bracket to allow more space for an external pot.
Another way would be to mount the femur and tibia encoders to the main vertical support bars and tie the encoder shaft to the parts that are moved by the motors. This would take more work to figure out since it wasn't initially designed with this in mind and I don't want to have something that isn't visually neat or could be damaged easily.
Bob
It is a very compact unit, smooth rotation and looks very nice.
Since I'm also looking to potentially use this to replace the potentiometer in the linear drives, I opened one of them up to see its configuration.
The encoder will fit in the available area without having to modify the housing. The encoder uses 5 wires vs only 3 for the pot but that can be worked out. A bigger concern is that the shaft of the encoder is 6MM and the pot is 0.25", the encoder is 0.15" smaller so the gear doesn't fit. Also, the hole in the mounting plate is too large, making a very sloppy fit. The hole can be fixed by machining a custom washer to take up the slack. Increasing the shaft size will take a little more thought. The shaft is made of either brass or bronze so I need to do some research into possible methods for increasing its size without damaging the unit.
Tomorrow I will start some coding tests and see how well it works and the speed of the data coming into the prop.
Here are some 6mm gears. http://robotshop.com/en/actobotics-16t-gearmotor-pinion-gear-6mm.html
Would this work?
Jim
+1. That's not a high speed power application on those gears, so you should be able to retrofit a spacer on there with tubing and epoxy. Accuracy is important to avoid binding & backlash. Clamp the rig down and check the gear for runout with a dial indicator as the epoxy sets up.
If you do this mod several times, your last one will the best one.
What's the angular resolution on those magnetic encoders? Is it a full 360 degrees? Pretty cool stuff. I'm surprised Duane hasn't chimed in here yet, he's quite the encoder fanboy.
from his first post on the topic.
Yeah, I too am surpised that Duane has not dropped in of the topic. I believe I sent him a PM.
Jim
Using a brass tube was my initial thought. I found some .25 OD brass tube at the local hardware store, I will have to do some work to get it to fit over the 6MM shaft but that shouldn't be too hard to do, besides, that's what I have the machine shop in the basement for fixing things like this. Tonight I want to do some programming and see what kind of output I get from the unit. I'll be starting with Duane's code that he posted a few years back and modify it as needed. I like the fact that you can also daisy chain these together especially since I only have one spare cogs now!
Bob
I've been testing the program from Duane and got an output pretty quickly. Unfortunately the output is wildly variable and constantly says it has an error in between readings. Sometimes I will get a whole series of outputs but again the numbers aren't even close to one another. Duane has an averaging routine built into the program but I thought that when the shaft isn't moving that the values would stay relatively consistant, I'm getting value swings of several hundred (the equivalent of around 30 degees of shaft motion).
I will post on Duanes original thread if he has any insight for me.
Bob
I was unsuccessful i finding my old files, I finally remembered that the computer that I was using at the time died a horrible and violent death and I may not have had the latest and greatest backed up. I lifted this link from the middle of Duane's thread that gave what I thought was stable code at the time. [url="AS5055Demo120526a - Archive [Date 2012.05.26 Time 15.21].ziphttp://"]AS5055Demo120526a - Archive [Date 2012.05.26 Time 15.21].zip[/url]. futher down in the thread is a video of it working.
Jim
The test setup I'm using is outside of the robot, just an experimenter board connected directly to the encoder. I don't have anything else running that would cause this type of problem. The encoder uses SSI to communicate the results serially, the initial setup does output values but they are very erratic, not what I was expecting. Now the software was designed for connecting directly to the encoder chip and with the HH-12 I don't have that option, only the CLK, CS, and Data out line. I don't know how the internal circuitry is put together, it doesn't appear to easily disassembled so I can check out the circuitry inside the housing. (I'm going to send the vendor a request for the schematic, that may help also).
Bob
The first place I am going to use the encoder is the coxa, the side to side movement of the leg. The easiest mechanical installation is to replace the existing potentiometer with the encoder. I need to make an adapter for the HH-12 shaft as it is too short to engage the main gear. If I make the mechanical connection here then I have to take into consideration that the gearing results in about 2.5 turns of the pot shaft as the leg moves from one side to the other. Since this would result in 3 separate 0-4096 transitions, the code needs a counter since I couldn't get an absolute position from the leg for any given reading. This could cause some initialization issues where each leg would have to figure out its current position when power is applied.
A better move may be to connect the encoder shaft directly to the leg so that it is only measuring the +/- 60 degree leg movement. That would be using only 120 degrees of a single rotation so the output would be the absolute location. The encoder output would be limited to a value change of 1365 on the output since it isn't using the full range of the encoder. Mechanically doing this will be harder since the leg was not designed this way and the pins that the leg rotate around are stationary and don't normally rotate with the leg. Time to put on the thinking cap again!
Once I get through this problem then I'll get back to figuring out putting the encoders in the linear actuators.
Bob
Jim
There are a couple of other ideas I have for making this work if this idea doesn't pan out, they are mechanically more complex and potentially prone to issues in the future. I like ideas that are simple, easy to maintain and still look elegant.
Bob
I started integrating the magnetic encoder into the main leg program and determined that I didn't have an extra cog to play with. I ended up using what I thought was my spare cog on the 4 way serial port since I needed 2 of them. I could use the ADC cog in the future if I totally move away from the ADC (I don't want to do that as the ADC can be used for various sensors I want to add in the future). I could remove one of the 4 port serial objects for now until I figure out how to go on (maybe someone will write a 6 port serial object someday!).
I should be able to post some photos soon on this new layout once I'm happy I've got a workable solution for connecting the encoder and the leg.
Bob
I've been keeping a curious eye on your build
How many serial links are you using simultaneously? (ie why do you need two four-port cogs?)
Out of interest, can you list your cog usage?
I was wrong, I'm only using a single 4 port serial port on the leg controllers (the master computer uses 2, 4 port serial ports for communicating to 6 leg controllers). My cog list for the leg controller is as follows:
- Microchip 3208 8 channel ADC uses 2 cogs (ADC_Input_Driver and I run the whole thing in its own cog continuously)
- 4 port serial port (pcFullDuplexSerial4FC)
- Coxa motor PID
- Femur motor PID
- Tibia motor PID
- HB-25 controller (jm_servo8)
In the meantime I disabled the tibia PID cog so I could troubleshoot code. I got the encoder to run with good output data in the coxa PID loop. I just had a thought that the encoders are unique for each motor, so there are only a few specific places that it is called within a PID loop. I could just not run it in its own cog and call the routine when needed while inside the CoxaPID cog. The only time the encoder is checked outside the CoxaPID cog is during initialization when the slope is calculated. I just can't initialize the CoxaPID cog until this step is complete. This might be a way to circumvent the need for another cog.
Today's tests included using the current control method to move the leg back and forth and observing the raw data output from the magnetic encoder as I moved from one extreme to the other. The output tended to be consistent +/- 2 counts. Of course this was after I removed the springs (the output was very inconsistent using springs) and put in a stiff wire to connect the moving part to the encoder.
I've been playing for a while so time for a break until tomorrow, I'll try out the idea above and see if that works. Then I can code in the encoder in place of the potentiometer.
Bob
Thanks for the update. Since you have switched to the HH-12 encoder, do you still Need ADC?
Jim
I still have the potentiometer feedback from the linear actuators that I haven't converted over yet and there are some future mods that will require an ADC input.
I took out the encoder code from running in its own cog and am incorporating it into the cog for the coxa PID loop. Came up with some errors that were causing problems but after thinking about it I believe I know what I did wrong. I'll try again tonight and see if I can get it running right.
Bob
I'm going to play with this a bit longer and tweak the PID code and see if I can get 0.1 degree movement out of the motor. It should be possible to get that degree of accuracy. Repeatability looks pretty good also but I need to add a second connecting rod to the encoder arm to take up any additional slop
I think you could reduce the number of required cogs...
1) as you already noted, you should be able to use a single cog for ADC, just change the driver to update an eight element array constantly with the readings
2) I suspect you could use just one PID cog, time-multiplexed between the three motors, as I don't think one PID loop would take a large fraction of a cog's time
In the meantime the encoder is working pretty good. I figured out that I had a math error that was giving me the 15 degree offset, that's fixed now. I found and corrected the calibration routine so it seems good now. Still have to add another 'arm' to the encoder from the leg to help take up any slack in the movement of the encoder.
Next event will be to start running the gait sequence from the master computer and see if the overall leg movement has improved.
Re/PID cog, there is a way to really simplify running multiple PID loops.
Keep the cog mostly as is, with the following changes:
hub byte variable UPDATE, value 0...3, 0=idle, 1/2/3 calculate PID for loop 1/2/3
hub variables CV/SP/PV etc for each of the loops, in three consecutive blocks
PID cog monitors UPDATE. When zero, keeps monitoring until non-zero
When finally non-zero:
- load variables for the loop (1..3 or higher) into the variables in the cog
- process via PID
- save variables
- set UPDATE to zero (you can also set UPDATE1/UPDATE2/UPDATE3 if needed to tell other cog that PID is done for that loop)
This way the PID cog only has to deal with a single set of variables, yet you can run three (or more) PID loops in one cog.
In other mechanical news, I have been thinking about how to use these encoders on the femur and coxa movements. After a lot of deliberation I decided not to replace the linear actuator potentiometer with an encoder. The main reason is that the encoder measures 0-4096 in 360 degrees of motion. Since the potentiometers rotate about 3600 degrees this would require some means of counting the rotations and maintaining that reading between leg controller power cycles. Although I have used the upper portion of the EEPROM to store data like this, it requires another cog for I2C communications. If the current leg position data is not stored then some type of calibration routine would be required during each startup. Although there are ways around each of these issues, I think I have a better idea. I will use the encoders to directly measure the angle of the two sides of the parallelogram that are controlled by the 2 linear actuators. I would mount the encoders on each side of the leg beside the main pivot. An arm attached to the encoder would then be attached to the 2 sides. This allows direct reading of the angle within the 360 degree rotational capabilities. I envision machining a delrin housing for the encoder that will attached to the lower section of the leg supports. I'm still thinking out the problem and have to put some of these ideas into the CAD/CAM program and see how it turns out.
Bob