Unless you need to laser something bigger than 12" x 9", you can buy a 40W laser on ebay for $365, free shipping.
A 100W laser can't cut any more materials that a 40W laser can. To laser all the plywood for my R/C airplane only takes an hour. I imagine then that a 100W laser would do it in 24 minutes. I did have to align the mirrors etc, but everything went smoothly.
I hope for whatever you're spending, that at least it doesn't have stepper motors.
Unless you need to laser something bigger than 12" x 9", you can buy a 40W laser on ebay for $365, free shipping.
A 100W laser can't cut any more materials that a 40W laser can. To laser all the plywood for my R/C airplane only takes an hour. I imagine then that a 100W laser would do it in 24 minutes. I did have to align the mirrors etc, but everything went smoothly.
I hope for whatever you're spending, that at least it doesn't have stepper motors.
This is a commercial laser and 100 watts may not cut/etch any more materials than a 40watt but it gives enough power to easily and quickly cut through fairly thick wood and plastics. I have several hobbies besides robotics that I plan on using the laser for making parts along with a few other side ventures I am exploring. It is probably over kill for what I will be using it for and expensive for hobby use but since you can't take it with you, might as well have fun along the way! Besides, think of all the new design robot bodies that can come out of this!
I have been able to spend several hours working on coding the hexapod. I decided to experiment with the PID loop for the coxa by re-writing a new PID routine and making it even simpler. I got rid of the existing speed control code and only used the inherent ramping on the PID. Actually its a PI loop right now, I haven't added a derivative process yet. The proportional code was easy to integrate as it is simply the constant (kp) times the error (kp*error). I determined the kp value by simply incrementing it by 1 and then commanding a move. The larger the value the faster the leg moved until I got a value where the leg had significant overshoot. Then I backed the value back down to the previous value.
The Integral portion is trickier but it improves the response rate as its output is added to the output of the Proportional code. The Integral value is based on the change in error over time, since the code time interval was essentially constant, I did not use any code to determine time. This simplifies the code to accumulating the error (errorsum = error + error sum) and then multiplying it by a constant (ki) (ki * errorsum). This value can grow pretty quickly so I put limits on its growth to prevent it going too far. Initial tuning of the Integral portion didn't go well as I was using integers for ki which cause the motor speed to accelerate much too rapidly and caused wide overshoots. That's when I figured out the ki value should be less than 1. Since I can't use floating point math (no cogs available to run the code), I set ki = 5 and then divided the integral result by 10. This produced a controllable leg movement that did not have any overshoot.
A byproduct of this testing was that the encoder value at the end of one motor command now closely matched the last encoder value for the previous command. As I stated a few days ago I ran into issues where although the stop motor command was sent at the right time, the motor inertia caused enough additional movement that the leg would end up further away from the desired position.
At this time I don't think I need to add the derivative portion of the control, I still have more testing to perform and I want to try a variety of integral constants to see what value gives the best response.
The re-write of the Coxa PID loop was successful so the Tibia and Femur loops were also updated using the new routine. This greatly simplified the movement routines, the troubleshooting text output is a significant part of the code now. With this last change I eliminated the 'S-curve' speed control as the PID now controls the motor speed. The ADC control was also removed, however I will need the ADC eventually for the leg impact sensors. Here is an example of the code used for the Coxa PID routine:
pub CoxaPID | error, speed, actualADC, oldADC, endspeed, dir, currentAngle, kp, ki, errsum, output
'PID motor controller routine for Coxa
' repeat until inside of deadband
'monitors CoxaTarget value continuously
repeat
kp := 3 'tested to value 4 causes oscillations
ki := 1
CoxaColor := Green
CoxaMagEncoder := CoxaEncoder
error := CoxaMagEncoder - CoxaTarget 'error based on mag encoder, CoxaTarget is desired position
'allow for calibration and keep motor stopped inside deadzone
if ||error < 2 AND coxaCal == 0
speed := 1500
dc.set(2, speed, 0) 'stop motor
endspeed := 0
' if CoxaAngle = 0 then running calibration check
repeat while (CoxaDone == 1)
CoxaMagEncoder := CoxaEncoder
error := CoxaTarget - CoxaMagEncoder 'error based on mag encoder
errsum := error + errSum 'get Integral value, limit it to 500 (motor pwm stop =1500, so
1500-500 = 1000 and 1500+500 - 2000; the limit of HB-25 controller output
if errsum > 500
errsum := 500
if errsum < -500
errsum := -500
output := (kp * error) + (ki * errSum)/10 'main PID output value - divide by 10 to use integral math
if error > 0
dir := 1
speed := 1500 - (output) 'use output to determine motor speed - limit speed to max value
if speed < 1100
speed := 1100
CoxaColor := Blue
else
dir := 0
speed := 1500 + ||(output)
if speed > 1900
speed := 1900
CoxaColor := Orange
if (||error < 1) 'stop if in deadzone
speed := 1500
dc.set(2, speed, 0) 'stop motor
coxaColor := Green
coxaDone := 0
errSum := 0
CoxaMagEncoder := CoxaEncoder
if CoxaTest == 1 'output text if in testing mode
currentAngle := CoxaMaxAngle-(((CoxaMagEncoder - CoxaMaxMag) * 1000)/ cSlope) 'calc current angle for troubleshooting
io.str(0,String(13, "Coxa Done - Stop, motor inside deadband: "))
io.str(0,String(" Encoder: "))
io.dec(0,CoxaMagEncoder)
io.str(0,String(" -CoxaAngle: "))
io.dec(0,currentAngle)
io.tx(0, CR)
quit
'set variable speed code here using the speedcmd value (10-100)
endspeed := SetCoxaSpeed(speed)
dc.set(2, endspeed, 0) 'start motor at speed
CoxaMagEncoder := CoxaEncoder
if CoxaTest == 1
currentAngle := CoxaMaxAngle-(((CoxaMagEncoder - CoxaMaxMag) * 1000)/ cSlope) 'calc current angle for troubleshooting
io.str(0,String(13, "Coxa Angle: "))
io.dec(0,currentAngle)
io.str(0,String(" -Encoder: "))
io.dec(0,CoxaMagEncoder)
io.str(0,String( " -CoxaTarget: "))
io.dec(0,CoxaTarget)
io.str(0,String( " -Error: "))
io.dec(0,Error)
io.str(0,String( " -Speed: "))
io.dec(0,endspeed)
io.str(0,String(" -dir: "))
io.dec(0,dir)
io.str(0,String(" -errsum: "))
io.dec(0,errsum)
io.str(0,String(" -ki: "))
io.dec(0,ki)
else
pauseMSec(20) 'required pause when not outputing debug info
ActualADC := CoxaMagEncoder 'based on encoder input
if CoxaCounter == 1 'check if encoder not changing
oldADC := CoxaMagEncoder 'reset check encoder value
if CoxaStopError(oldADC, CoxaMagEncoder) 'error if encoder not changing
speed := 1500
dc.set(2, speed, 0)
coxaColor := Red
coxaDone := 0
errSum := 0
if CoxaTest == 1
io.str(0,String(13, "Coxa Done 4 - Encoder value not changing: "))
io.str(0,String(" Encoder: "))
io.dec(0,CoxaMagEncoder)
io.tx(0, CR)
quit
coxaColor := Green
pub SetCoxaSpeed(speed)
' modify speed based on input value speedcmd (5-100%)
if speed > 1500 'formula differs for each motor direction
result := 1500 + (((speed - 1500) * cSpeed) / 100)
result := result #> 1552 'set minimum speed
elseif speed < 1500
result := 1500 - (((1500 - speed) * cSpeed) / 100)
result := result <# 1448
pub CoxaStopError(iADC, aADC)
CoxaCounter := CoxaCounter + 1 'count to 10
result := false
if CoxaCounter == 1 'at start get encoder value
iADC := aADC
if CoxaCounter == 10 'max count 10
CoxaCounter := 0
if iADC == aADC 'error, encoder not changing
Result := true
I left in the code to set overall motor speed and determine if the motor is not moving.
I am putting together a short video of the PID tuning process that I should be able to post shortly.
The next step is to re-introduce the master computer into the mix and run the leg computer via commands from the master. Then I can visit the gait control algorithms again and start getting those working.
Its slow but progress is still being made, thanks for joining me on this long, long journey!
I finally got Adobe Premier Elements to cooperate and was able to patch together a short video of the PID tuning process for the coxa motor. Hopefully there is enough information in there for you to see the process I used. Setting the PID variables is time consuming but the end result is worth it.
Got the laser cutter installed in the basement and took the first cuts today. It works great and I even was able to transfer CAD files to the laser software and cut out a cover for the Magnetic Encoder housing. It even fits! I see a lot of uses for this machine in the future.
Summer is winding down, the boat is getting ready for its winter rest, Michigan is getting colder (wetter, windy) so bike riding is slowing down and only diving every couple of weeks, so I have more time to get back on the robot! Unfortunately I've only spent a handful of days playing with the code so I end up spending a lot of time re-familiarizing myself with where I left off the previous time.
I spent a day working on just tuning the 3 PID loops, so far the leg motor output looks good when I manually input commands even with 0.1 degree movements. The Coxa encoder mechanical setup is still not the best, I see some 'sticking' of the encoder while the motor is moving which throws the position off. I want to return to the mechanical attachments and see how those can be improved.
I put the individual leg controller in its 'Automatic' mode but was unable to get any movement when running the master computer. Since it was already late I quit before I messed any code up. Later I realized that I had changed the leg ID from 6 to 1 (don't remember why) so most likely that was the problem. I also spent a day reviewing the Inverse Kinematics math for leg movement. I had to watch my own video on Inverse Kinematics to help me refresh my mind on how I programmed that into the master controller. I think I've got that all straight again so the next stage is to code some simple movements and see if I can get this leg to move in a straight line! Then I can think about how the leg formulas need to change for the leg moving in a straight line but at different angles.
Now I'm completely Blown away. What a project to undertake.
What a fun project! I have been watching since this thread started back in 2015. Am anxiously awaiting its first steps. I guess that Bob will early on have to teach it to climb stairs!
Jim
The problem with communications between the master computer and leg controller was due to the changed leg number. Once I changed the master program to output to leg 1, they started talking to each other.
I started testing with a simple move, take the leg to a default position. Then I told it to move to a specific location using the Inverse Kinematics (IK) equations. This was successful but the movement of the coxa puts the leg tip (the tip is where the leg would normally be touching the ground) describing an arc movement since each axis motor's speed impacts the leg tip movement differently. This means that the femur and tibia motors may finish their movements while the coxa is still moving into position. This is bad because that represents a sliding movement for the leg tip on the ground and this robot isn't designed to slide (smaller hexapod leg tips can slide some but I'm dealing with quite a bit more weight!). To reduce the amount of the arc the motion is broken down into a series of segments.
The output of the IK is the new angle for the 3 axis of the leg that describes the final position of the leg tip. The change in angle to get to this point is calculated for each axis (start angle minus the IK angle). This value is then divided into segments (still testing to determine the best value but the value of 30 was giving good results). The master outputs a request to leg axis for the current axis angle plus the value of the change angle/30. This is a relatively small movement where the differences in axis movement speeds is minimized so tendencies for the leg tip to slide are absorbed due to inherent mechanical 'slop' (there may be a better word to describe this but I can't think of one) in the leg.
That describes the coding for leg movement but in practice what I observed today is that the femur and tibia movements are smooth but the coxa has a tendency to jerk the leg and overshoot the position. I did not observe this jerk when working with the leg controller and tuning the coxa axis. There are a couple of possible explanations that I came up with. First, the coxa tuning is too aggressive and needs to be backed off. The speed that the master inputs the movement commands is much faster/frequent than I can manually input from the keyboard, this might put the PID loop into a condition where it overshoots the target. The other possibility is that the mechanical setup for moving the coxa encoder shaft sticks with very small coxa movements and when it does move a large PID error is introduced. It may even be a combination of both items.
I've done enough for today but tomorrow I will 'detune' the coxa PID loop so that it responds slower and see how that affects leg movement. Re designing the encoder mounting is something I hope I don't have to do!
Yesterday was a bust for working on the robot, my wife tasked me with helping her figure out how to use the software for her computerized quilting machine. It took a lot longer than I expected but she is happy again. I have figured out that retirement means I just have one less boss!
Before I got into the programming again today I put together a cheat sheet for myself for the IK equations and assumptions that went into the design. I thought I'd post it here also for anyone wanting to create their own hexapod using this leg design.
I've been tweaking the PID tuning values for the Coxa for a while and I believe I'm getting some good output travel from the coxa. It is not jerking anymore and responds smoothly. I put a ruler on the floor and input a destination value for the leg and use the ruler to see how close to a straight line the leg tip travels. With the coxa moving smoothly I found the tibia is making a large move at the beginning of the leg swing and comes to the correct location by the time the leg completes the swing. Checking the requested position data from the master to the leg controller shows the expected output but the tibia reacts too quickly initially but is in the correct location by the end. At first I thought the tibia motor speed was too high as compared to the coxa but experiments with the tibia speed gave similar results. Working with the tibia PID directly allowed me to manually input a sequence of tibia angle changes that matched the input from the master. I was seeing correct responses to the input and the corresponding leg moves. So this is a puzzle to figure out.
As I wrote up the description of the issue out above I suddenly thought of a possible cause. Each motor PID loop is designed to respond to an input angle. Even if the PID is still moving to a requested angle a new angle command can be input and update the error response before the leg completes the previous move. This response is desired otherwise if I waited for each motor to complete their movement it would result in a jerky leg movement as each motor starts and stops (since a leg movement from the start to the end position is broken up into 30 segments this is a lot of starting and stopping). If the master is outputting the position commands too rapidly to the leg controller, the tibia could be reacting more quickly than the coxa causing the leg to swing outward. Then the last position command from the master would be the only thing both motors are responding to at the end which would explain why the leg still ended up in the correct end position. I will add some long pauses in the loop from the master and see if that straightens the response out. Then I can slowly reduce the pause time until I get to the point where the command input and motor response timing are the same.
Some days it seems for every problem I solve two new ones crop up..... I need to video some of this testing but the video editing software I use (Adobe Premier Elements Version 14) has been way too slow ever since I upgraded to v14. I'm ready to move over to a new video editor but don't know which one to use. Any suggestions for a decent video editor that does HD and won't break the bank?
The issue I discussed in yesterdays post was not specifically caused by the item I wrote up by itself. There is another factor that I didn't take account of that became clearer when I increased the interval between moves to 750 milliseconds. I saw the tibia move outward a much greater distance than expected during the first portion of the leg move. The primary cause ends up being an assumption that I made that if I know the initial and final leg motor angle positions I could evenly divide the amount of movement by a value; (final position angle - initial position angle)/20. This results in each motor axis moving equal amounts needed to reach the final position. What I didn't take into account was that for the leg tip to move along a straight line path the angular change is different along the path. For example if you draw a straight line and then draw a point a couple of inches off to the side of the line and around midpoint of the line. Now using the point as a pivot point, take a pencil or pen and hold one end on the pivot point. Rotate the pencil so that it is 90 degrees to the line. Observe the point where the pencil touches the line and rotate the pencil one inch. Observe the distance that the line moved relative to the pencil shaft. Now do the same 1 inch movement but further down the line. You should be able to see that the distance that line moves relative to the shaft is much greater than it was initially. What this boils down to is that I can not use the same angular movement as initially the angle change is small and slowly rises as the leg tip moves further away.
To solve this problem I still divide the movement into discrete distances for each motor but now I run those X, Y, and Z through the Inverse Kinematics routine to get the correct angle for each location. I wrote the coding for that and got a much straighter movement. I also implemented a short delay into the routine as that gave the motors more time to react before the next command showed up. The speed of spin may become an issue later as I add more legs into the master controller, but I should be able to reduce/remove the delay as more legs are added.
So far the majority of leg movements have been just changing the Z axis and leaving the X and Y values alone. I want to start implementing X values which mean the leg will move at an angle relative to the pivot point. I have done a little testing with that but haven't used a wide variety of values. That capability is essential as the plan is that the robot doesn't have a front or back so I need it capable of moving any direction without turning.
I took some video on my iphone of some of the tests but I want to combine it into a single file before I post it. I'm looking at video editors and Pinnacle Studio Plus seems interesting from what I've read so far. Anyone familiar with it?
It turns out that I didn’t have to write any special code for leg movements where the Z axis isn’t zero. With the new updates, the code already takes into account those differences. So on to the next task, turning the movement into a step.
I ran into some issues testing the coding where the leg would just take off in unexpected directions. As I tested and wrote code to fix a problem another problem would crop up requiring more coding workarounds. Finally I got to a point where the leg stopped working reliably and was not responding as expected.The code was a mess and almost unreadable at this point.
After a nights sleep I tried again but first put down pseudo spin code on paper to better visualize the movement and what information would be needed. I wrote a new leg movement routine using that as a guide that surprisingly worked correctly the first time. However after that success the calibration of the tibia went out of whack. I found that the connecting rod from the encoder to the leg got bent which changed the calibration. Even with re-calibration it would not hold accurately since the bent connecting rod could rotate, changing the encoder angle. The rod got bent in the first place since the slot that the rod came out of the housing was not long enough for all possible motions. This is an older design for the encoder housing that I hadn’t replaced yet as it had been working well in the past.
So I decided to machine a new encoder housing using the new design. It took a lot longer than expected as I kept making basic machining mistakes. Apparently I haven’t been using the CNC mill enough lately and was trying to rely on my memory for all the steps needed to prep the stock material for cutting and other steps in the process that weren’t in the CNC programming. Luckily none of these mistakes were catastrophic so eventually I got the housing created. I did document the process for making the housing so hopefully the next time will be quicker and I don’t have to try to rely on memory for all the necessary machining operations.
I still need to unsolder the encoder from the old housing and swap in the new housing. Then reassemble the unit with a new connecting rod, calibrate, and hopefully continue with the gait coding.
Bob
(Still looking for a video editor. Also, how do I post a video on this thread without having to reference a YouTube video? Can I just reference a video on my C: drive? I have several short iPhone videos of the testing to show)
Is there a way to post videos without going through YouTube? I have several very short videos taken with my iPhone that I would like to post but I don’t want to compile them together and put on YouTube.
I installed the new encoder housing and used the laser to create covers for the housing. The slot for the connecting rod from the encoder to the tibia is much longer so I shouldn’t have any issues with the rod bending due to over-travel like the previous housing design.
Calibration of the tibia went smoothly and the initial manual testing had it moving in 0.30 degree inputs.
I put the master computer back in the loop and started moving the leg along a straight line path of 5 inches. The leg followed the expected path very nicely. The next step added code to raise the leg, return it to the origin and then lower the leg. After a few bumps in the road, I got the code to perform more or less as expected. An issue now is that when the leg lifts, the code for returning the leg to the starting point starts moving the leg before the leg has finished moving up. I added a short delay after the leg lift but what is happening is that the motor done flag from the leg controller is not being updated to the master computer.
The code for the motor done flag update is embedded in the main leg controller loop and doesn’t execute until there is some type of input from the master computer and even then it just executes that one time. I tried a dedicated line from the the leg controller to the master computer with mixed results. Now that I have a spare cog in the leg controller I want to try out creating a continually running routine that outputs the motor status information to the master either via another serial link or by toggling a couple of I/O pins. That will be the objective for todays coding.
Bob
I checked out the website for Camtasia Studio. It looks promising, I may have to download the free trial and see how easy it is to use. I’m still leaning toward Pinnicle Studio, mainly due to the price. Most of the video that I make is relatively simple and I don’t need 90% of the bells and whistles most video editors have.
I still haven’t figured out how to directly embed a video from my computer into this forum if I don’t want to use YouTube.
I had a good Programming day until the end of the day. I got the gait programmed to start in the default position (coxa at 90 degrees), move the leg one direction, lift the leg, move the leg back past the starting position, lower the leg and then repeat. When the travel command is removed, the leg completes the cycle and returns to the default starting position. Still having problems with the master computer not responding to the motor done flags so that when the leg lifts or lowers, the coxa starts moving the leg before the movement completes. I tried a direct line between the leg controller and master prop pins but the master doesn’t seem to respond to the pin from the leg controller. Unfortunately in the midst of trying different schemes, I somehow got the leg controller code so messed up that it stopped working entirely. After a while of frustration trying to figure out why and backing out of the code changes with no change in leg response I finally gave up and installed my latest backup file for the leg controller. Now I have to go back and figure out what changes I made (mostly small and simple code changes) and get them put back in place. That was a good time to stop for the night!
I ended up getting Corel VideoStudio Ultimate while it was on their Black Friday sale. Now I just have to figure out how to use it!
I have almost recovered from my coding snafu, still having some oscillations in the coxa motor but some more tweaking of the PID parameters should correct that problem soon. I am finally getting the leg controller to output the Femur motor done flag and the master to read it. I don't know what I changed to fix that but it appears to be working properly now.
Started watching the VideoStudio tutorials, should be able to put together a short video of the leg movements and gait after I get the video off the iPhone. I sold my old video camera and need to get a better camera down in the shop for filming video.
I still don't know how to get a video on this site without going through YouTube, I don't want to post some of the short clips I have but they would be appropriate for here. Otherwise I'm waiting until I get enough video compiled to upload to YouTube.
I think I corrected the coxa oscillation issue but now the tibia is having significant overshoot issues. When I tune the tibia and manually run just the tibia from the leg controller software it is correctly responding to 0.2 degree inputs without overshooting the mark. But when I start sending a stream of tibia commands via the master computer it is overshooting the mark, reversing back and overshooting the other direction. This is new behavior without a change to the gait program so my suspicion is an introduced bug in the leg controller. But the fact that under manual control I am not getting the overshoot is puzzling. Just thought of a test on the master where I increase the timing interval for the gait engine to 1-2 seconds between movement commands and see if it still overshoots...
After a lot of testing I think I determined that the cause for the tibia oscillations occurred when the leg had not finished a movement before the next movement command was recieved. At this point the PID integral variable was at a high value which caused the motor to over-react. I added code to reset the Integral value if the target value changes. This should correct this issue and initial tests are encouraging.
This testing has been fairly tedious but I’m close to getting the desired results.
Another coding item I’m working on is the feedback from the leg controller to the master. Right now each motor reports movement direction and whether or not the motor is active. I am only using that information for controlling the display RGB LEDs and determining when the femur motor has completed movement. The main code loop on the leg controller repeats on a loop that looks for an input over the serial link from the master. However, the code looking for the input serial string from the master is stuck waiting for the input string. Since the feedback to the master is in this same loop, it doesn’t get to send the updates back to the master except after a valid input string is recieved.
So I’m trying to figure out how to either have the GetString procedure not just sit there or create another serial loop that is dedicated just to the feedback. So far trying to code the routine to bypass the GetString procedure hasn’t worked as expected. I’m probably making some invalid assumption. I will give a couple more days and if I still can’t work my way through it I’ll post a question in the Prop1 forum.
Once I get through these 2 problems (and if nothing else new crops up) I’ll get back to putting the radio controller prop back into the loop. Then I can better test the ability to adjust stride length and direction on the fly vs coding in set values. The more prop boards in the loop make for harder testing, even just the master and controller means a lot of changing programming plugs and resetting the serial terminal.
Merry Christmas to everyone! After a week of more coding and testing, I still have’nt been able to get rid of all the tibia oscillations during gait movement. I’ve got the oscillations down quite a bit but ran into a problem where the tibia wouldn’t respond fast enough during movement. So its been a balancing act to try to find Proportional and Integral values that work right, still working on it. The feedback loop is still not fixed either.
Since I wanted to have something positive to show for the last week, I did pull out the old digital radio code and reinstalled it. It works OK after some tweaking so I can start controlling the gait stride using the radio remote controller now. Of course this also makes troubleshooting harder since now I have 3 Prop chips to program and troubleshoot issues.
Back from vacation and now suffering through a cold. Finally felt like going to the shop and seeing where I left off as I had a couple of new ideas to try out on reducing the Tibia oscillations. Unfortunately the leg would not respond as expected, finally determined that the gel cell powering the motor circuit was reading less than 9 volts. After getting the charger on it the voltage is up but it doesn't look like it is holding the charge very well. I've been using this battery for the last 5 years of motor testing so I have gotten a lot of use out of it. I picked up a new battery from Batteries Plus, its got a different terminal style so I have to get some lugs to match.
In order to keep from forgetting to charge the battery occasionally I poked around in my supply stash and found a Lascar Electronics PanelPilot graphics display that I had purchased for another project (a project that didn't get very far off the ground). The display went into the stash and I forgot all about it. It's now got a new job of monitoring the battery voltage now. You can program the display and operation using free software from Lascar that is pretty intuitive. This display is a model SGD 24-M that has 2 analog inputs and 2 alarm outputs. For now I picked a display that had a nice digital and analog readout, selected the text, colors, input range values, and alarm setpoints. It was a simple job to wire into the power circuit. The laser cutter was used to cut the plastic for the display opening and everything went together nicely. Here are some photos of the display.
Hopefully this will help me to remember to keep things charged up. I've already changed the display setup since I took these pictures, Instead of 0-100% its now 9-15volts and the red bars start at 10.50 volts (manufactures recommended minimum voltage without charging) and low alarm setpoint also set at 10.5 volts. Lascar also has a 4.3 inch touchscreen version with 4 analog inputs, digital inputs, several outputs and even more customization options that might come in handy down the road. Its a little pricey but it could be fun to play with!
Was playing around with the robot today and added a better charging circuit that will work with my battery charger. Also started to start powering the leg controllers and master computer off of the robots 12v-5v inverter power supply instead of an external wall wart.
Since we are into a new year I thought I'd do an overview video of the project to bring everybody up to date on the design and current status of the robot. It doesn't cover everything but it goes over the basics.
Now back to the boring testing routines and slowly tweaking the motor PID software. I still need to get the Tibia oscillations figured out as that is the last obstacle to getting the tripod gait routine finished up.
It’s been a busy few days of work and I finally fixed the Tibia oscillation during gait movement! The fix ended up being adding a 50msec delay in the leg controller PID main loop whenever the master controller is providing the input signal. I was never able to reproduce the oscillations when I manually controlled the leg movement so looking at the difference between the code during manual vs external commands was the PST debugging output is active during manual operation and bypassed during external operations. I added a short delay so that when the debugging is disabled the loop timing would be similar as when in manual mode. And it worked!
Now the gait step is very linear and I can change the X and Z axis values manually to get the leg to move in different directions. With the smoother movement I was also able to determine that the Femur movement to lift and lower the leg at the beginning and end of the gait step has a minor overshoot that needs correcting but this isn’t a critical issue at this time.
Next step is adding the transmitter back into the loop so I can dynamically control the X and Z movements via the joystick. I started coding this but it isn’t working quite as expected yet. I think I have some incorrect assumptions that I need to review before I change any more code.
Once the transmitter is working I will add another leg controller to the testing and work on getting two legs to synchronize their movements. Of course this means enabling another serial port on the master so I can start getting used to using the 4 port serial transmission code from the OBEX.
Before adding the next leg, some mechanical work is needed on the leg since there have been a few mechanical changes to the test leg. I milled out 3 more magnetic encoder housings today, had a 4th almost done and made a mistake on the mill that crashed a $60 endmill into the vise and destroyed the piece along with the endmill. Luckily I have another endmill of the correct size and length, I have 7 more enclosures to make yet.
Finished milling the 10 magnetic encoder enclosures for the remaining legs. There are several other parts that I am using the lathe to create plus I have to partially disassemble each leg to drill and tap the mounting holes for the enclosure. At this point I also decided to keep the same design for the coxa encoder, it isn’t elegant but it does work. Finishing this up should keep me busy for a couple of weeks!
These are the 10 encoder housings. The slot on the side of the housing is for a connecting rod that goes from the encoder shaft (I use the round delrin piece that have a hole in the middle that is a few thousands smaller than the encoder shaft diameter to give a good friction fit.) The delrin piece is drilled and tapped on the side so the connecting rod (4-40 all-thread) extends outside of the housing and attaches to the side of the leg. Leg movements then rotate the encoder shaft which gives the leg position.
This shows how the housing attaches to the leg support. 2 8-32 screws are used to attach the housing. This side is where the encoder body is attached.
This is the back side of the leg support. The housing attachment holes have not been drilled and tapped yet. The center of the encoder shaft is centered on the pivot point for the leg femur and tibia.
This is the Femur encoder housing and connecting rod to the encoder shaft. This is on the leg #6, the current test leg. This shows how it is all put together.
This is the tibia encoder housing and connecting rod.
I couldn’t get any good pictures of the coxa setup but there are some good photos of that earlier in this thread from a few months ago.
Machining more parts, lots of soldering, and starting to re-assemble the legs with the upgrades installed. It’s going to be several more days to finish this up but then I should be able to start testing 2 legs together and see if the gait engine works right, ie both legs move the right direction. Of course each leg has to be calibrated first which is a tedious project. Here are some photos of progress.
These are the arms that are used by the coxa encoder to move the shaft as the coxa motor moves. It’s a slightly different design from the test version but it should be more reliable. The test version had issues with the spring wires popping out of the arm, this solves that issue.
These are the encoder housings with the wiring harness installed.
These are the coxa encoders mounted. Mods to this part included drilling the hole for the encoder and cutting 1 inch off the back of the mount to allow more room for the sensor plugs and wires that are mounted directly behind the piece. Some wires were getting pinched and the extra length wasn’t needed on this mount.
Here is a fully wired encoder in its housing. The other encoders still need their shafts cut down to 1/4” and soldering the wiring harness to the encoder. Initial calibration is connecting to a program to determine the output value to make sure the output doesn’t cross zero in the expected rotation range.
Testing the encoders with a simple calibration program now that the electrical connections have been made. Out of 15 encoders, 5 did not work at all. On a whim I swapped the CS and CLK lines and the ‘failures’ started to work correctly. Not sure how I could have made that serious a soldering mistake on 30% of the encoders, I started cutting the CS and CLK wires and swapping them. I got down to the coxa encoders and just by chance noticed that some of the pre-wired connectors that I have been using have the 2 outside wires on the connector swapped! So when I was soldering and using the wire color to match up to my schematics, the wires were not correct at the connector end. That explains some of the other issues I have had using these connectors in other locations, I never thought to look at the order of the wires in the connector itself.
Now that’s sorted out I can continue with the initial calibration and start installing the encoders.
Comments
A 100W laser can't cut any more materials that a 40W laser can. To laser all the plywood for my R/C airplane only takes an hour. I imagine then that a 100W laser would do it in 24 minutes. I did have to align the mirrors etc, but everything went smoothly.
I hope for whatever you're spending, that at least it doesn't have stepper motors.
I have been able to spend several hours working on coding the hexapod. I decided to experiment with the PID loop for the coxa by re-writing a new PID routine and making it even simpler. I got rid of the existing speed control code and only used the inherent ramping on the PID. Actually its a PI loop right now, I haven't added a derivative process yet. The proportional code was easy to integrate as it is simply the constant (kp) times the error (kp*error). I determined the kp value by simply incrementing it by 1 and then commanding a move. The larger the value the faster the leg moved until I got a value where the leg had significant overshoot. Then I backed the value back down to the previous value.
The Integral portion is trickier but it improves the response rate as its output is added to the output of the Proportional code. The Integral value is based on the change in error over time, since the code time interval was essentially constant, I did not use any code to determine time. This simplifies the code to accumulating the error (errorsum = error + error sum) and then multiplying it by a constant (ki) (ki * errorsum). This value can grow pretty quickly so I put limits on its growth to prevent it going too far. Initial tuning of the Integral portion didn't go well as I was using integers for ki which cause the motor speed to accelerate much too rapidly and caused wide overshoots. That's when I figured out the ki value should be less than 1. Since I can't use floating point math (no cogs available to run the code), I set ki = 5 and then divided the integral result by 10. This produced a controllable leg movement that did not have any overshoot.
A byproduct of this testing was that the encoder value at the end of one motor command now closely matched the last encoder value for the previous command. As I stated a few days ago I ran into issues where although the stop motor command was sent at the right time, the motor inertia caused enough additional movement that the leg would end up further away from the desired position.
At this time I don't think I need to add the derivative portion of the control, I still have more testing to perform and I want to try a variety of integral constants to see what value gives the best response.
pub CoxaPID | error, speed, actualADC, oldADC, endspeed, dir, currentAngle, kp, ki, errsum, output 'PID motor controller routine for Coxa ' repeat until inside of deadband 'monitors CoxaTarget value continuously repeat kp := 3 'tested to value 4 causes oscillations ki := 1 CoxaColor := Green CoxaMagEncoder := CoxaEncoder error := CoxaMagEncoder - CoxaTarget 'error based on mag encoder, CoxaTarget is desired position 'allow for calibration and keep motor stopped inside deadzone if ||error < 2 AND coxaCal == 0 speed := 1500 dc.set(2, speed, 0) 'stop motor endspeed := 0 ' if CoxaAngle = 0 then running calibration check repeat while (CoxaDone == 1) CoxaMagEncoder := CoxaEncoder error := CoxaTarget - CoxaMagEncoder 'error based on mag encoder errsum := error + errSum 'get Integral value, limit it to 500 (motor pwm stop =1500, so 1500-500 = 1000 and 1500+500 - 2000; the limit of HB-25 controller output if errsum > 500 errsum := 500 if errsum < -500 errsum := -500 output := (kp * error) + (ki * errSum)/10 'main PID output value - divide by 10 to use integral math if error > 0 dir := 1 speed := 1500 - (output) 'use output to determine motor speed - limit speed to max value if speed < 1100 speed := 1100 CoxaColor := Blue else dir := 0 speed := 1500 + ||(output) if speed > 1900 speed := 1900 CoxaColor := Orange if (||error < 1) 'stop if in deadzone speed := 1500 dc.set(2, speed, 0) 'stop motor coxaColor := Green coxaDone := 0 errSum := 0 CoxaMagEncoder := CoxaEncoder if CoxaTest == 1 'output text if in testing mode currentAngle := CoxaMaxAngle-(((CoxaMagEncoder - CoxaMaxMag) * 1000)/ cSlope) 'calc current angle for troubleshooting io.str(0,String(13, "Coxa Done - Stop, motor inside deadband: ")) io.str(0,String(" Encoder: ")) io.dec(0,CoxaMagEncoder) io.str(0,String(" -CoxaAngle: ")) io.dec(0,currentAngle) io.tx(0, CR) quit 'set variable speed code here using the speedcmd value (10-100) endspeed := SetCoxaSpeed(speed) dc.set(2, endspeed, 0) 'start motor at speed CoxaMagEncoder := CoxaEncoder if CoxaTest == 1 currentAngle := CoxaMaxAngle-(((CoxaMagEncoder - CoxaMaxMag) * 1000)/ cSlope) 'calc current angle for troubleshooting io.str(0,String(13, "Coxa Angle: ")) io.dec(0,currentAngle) io.str(0,String(" -Encoder: ")) io.dec(0,CoxaMagEncoder) io.str(0,String( " -CoxaTarget: ")) io.dec(0,CoxaTarget) io.str(0,String( " -Error: ")) io.dec(0,Error) io.str(0,String( " -Speed: ")) io.dec(0,endspeed) io.str(0,String(" -dir: ")) io.dec(0,dir) io.str(0,String(" -errsum: ")) io.dec(0,errsum) io.str(0,String(" -ki: ")) io.dec(0,ki) else pauseMSec(20) 'required pause when not outputing debug info ActualADC := CoxaMagEncoder 'based on encoder input if CoxaCounter == 1 'check if encoder not changing oldADC := CoxaMagEncoder 'reset check encoder value if CoxaStopError(oldADC, CoxaMagEncoder) 'error if encoder not changing speed := 1500 dc.set(2, speed, 0) coxaColor := Red coxaDone := 0 errSum := 0 if CoxaTest == 1 io.str(0,String(13, "Coxa Done 4 - Encoder value not changing: ")) io.str(0,String(" Encoder: ")) io.dec(0,CoxaMagEncoder) io.tx(0, CR) quit coxaColor := Green pub SetCoxaSpeed(speed) ' modify speed based on input value speedcmd (5-100%) if speed > 1500 'formula differs for each motor direction result := 1500 + (((speed - 1500) * cSpeed) / 100) result := result #> 1552 'set minimum speed elseif speed < 1500 result := 1500 - (((1500 - speed) * cSpeed) / 100) result := result <# 1448 pub CoxaStopError(iADC, aADC) CoxaCounter := CoxaCounter + 1 'count to 10 result := false if CoxaCounter == 1 'at start get encoder value iADC := aADC if CoxaCounter == 10 'max count 10 CoxaCounter := 0 if iADC == aADC 'error, encoder not changing Result := trueI left in the code to set overall motor speed and determine if the motor is not moving.I am putting together a short video of the PID tuning process that I should be able to post shortly.
The next step is to re-introduce the master computer into the mix and run the leg computer via commands from the master. Then I can visit the gait control algorithms again and start getting those working.
Its slow but progress is still being made, thanks for joining me on this long, long journey!
Jim
I spent a day working on just tuning the 3 PID loops, so far the leg motor output looks good when I manually input commands even with 0.1 degree movements. The Coxa encoder mechanical setup is still not the best, I see some 'sticking' of the encoder while the motor is moving which throws the position off. I want to return to the mechanical attachments and see how those can be improved.
I put the individual leg controller in its 'Automatic' mode but was unable to get any movement when running the master computer. Since it was already late I quit before I messed any code up. Later I realized that I had changed the leg ID from 6 to 1 (don't remember why) so most likely that was the problem. I also spent a day reviewing the Inverse Kinematics math for leg movement. I had to watch my own video on Inverse Kinematics to help me refresh my mind on how I programmed that into the master controller. I think I've got that all straight again so the next stage is to code some simple movements and see if I can get this leg to move in a straight line! Then I can think about how the leg formulas need to change for the leg moving in a straight line but at different angles.
What a fun project! I have been watching since this thread started back in 2015. Am anxiously awaiting its first steps. I guess that Bob will early on have to teach it to climb stairs!
Jim
I started testing with a simple move, take the leg to a default position. Then I told it to move to a specific location using the Inverse Kinematics (IK) equations. This was successful but the movement of the coxa puts the leg tip (the tip is where the leg would normally be touching the ground) describing an arc movement since each axis motor's speed impacts the leg tip movement differently. This means that the femur and tibia motors may finish their movements while the coxa is still moving into position. This is bad because that represents a sliding movement for the leg tip on the ground and this robot isn't designed to slide (smaller hexapod leg tips can slide some but I'm dealing with quite a bit more weight!). To reduce the amount of the arc the motion is broken down into a series of segments.
The output of the IK is the new angle for the 3 axis of the leg that describes the final position of the leg tip. The change in angle to get to this point is calculated for each axis (start angle minus the IK angle). This value is then divided into segments (still testing to determine the best value but the value of 30 was giving good results). The master outputs a request to leg axis for the current axis angle plus the value of the change angle/30. This is a relatively small movement where the differences in axis movement speeds is minimized so tendencies for the leg tip to slide are absorbed due to inherent mechanical 'slop' (there may be a better word to describe this but I can't think of one) in the leg.
That describes the coding for leg movement but in practice what I observed today is that the femur and tibia movements are smooth but the coxa has a tendency to jerk the leg and overshoot the position. I did not observe this jerk when working with the leg controller and tuning the coxa axis. There are a couple of possible explanations that I came up with. First, the coxa tuning is too aggressive and needs to be backed off. The speed that the master inputs the movement commands is much faster/frequent than I can manually input from the keyboard, this might put the PID loop into a condition where it overshoots the target. The other possibility is that the mechanical setup for moving the coxa encoder shaft sticks with very small coxa movements and when it does move a large PID error is introduced. It may even be a combination of both items.
I've done enough for today but tomorrow I will 'detune' the coxa PID loop so that it responds slower and see how that affects leg movement. Re designing the encoder mounting is something I hope I don't have to do!
Bob
Before I got into the programming again today I put together a cheat sheet for myself for the IK equations and assumptions that went into the design. I thought I'd post it here also for anyone wanting to create their own hexapod using this leg design.
As I wrote up the description of the issue out above I suddenly thought of a possible cause. Each motor PID loop is designed to respond to an input angle. Even if the PID is still moving to a requested angle a new angle command can be input and update the error response before the leg completes the previous move. This response is desired otherwise if I waited for each motor to complete their movement it would result in a jerky leg movement as each motor starts and stops (since a leg movement from the start to the end position is broken up into 30 segments this is a lot of starting and stopping). If the master is outputting the position commands too rapidly to the leg controller, the tibia could be reacting more quickly than the coxa causing the leg to swing outward. Then the last position command from the master would be the only thing both motors are responding to at the end which would explain why the leg still ended up in the correct end position. I will add some long pauses in the loop from the master and see if that straightens the response out. Then I can slowly reduce the pause time until I get to the point where the command input and motor response timing are the same.
Some days it seems for every problem I solve two new ones crop up..... I need to video some of this testing but the video editing software I use (Adobe Premier Elements Version 14) has been way too slow ever since I upgraded to v14. I'm ready to move over to a new video editor but don't know which one to use. Any suggestions for a decent video editor that does HD and won't break the bank?
Bob Sweeney
To solve this problem I still divide the movement into discrete distances for each motor but now I run those X, Y, and Z through the Inverse Kinematics routine to get the correct angle for each location. I wrote the coding for that and got a much straighter movement. I also implemented a short delay into the routine as that gave the motors more time to react before the next command showed up. The speed of spin may become an issue later as I add more legs into the master controller, but I should be able to reduce/remove the delay as more legs are added.
So far the majority of leg movements have been just changing the Z axis and leaving the X and Y values alone. I want to start implementing X values which mean the leg will move at an angle relative to the pivot point. I have done a little testing with that but haven't used a wide variety of values. That capability is essential as the plan is that the robot doesn't have a front or back so I need it capable of moving any direction without turning.
I took some video on my iphone of some of the tests but I want to combine it into a single file before I post it. I'm looking at video editors and Pinnacle Studio Plus seems interesting from what I've read so far. Anyone familiar with it?
I ran into some issues testing the coding where the leg would just take off in unexpected directions. As I tested and wrote code to fix a problem another problem would crop up requiring more coding workarounds. Finally I got to a point where the leg stopped working reliably and was not responding as expected.The code was a mess and almost unreadable at this point.
After a nights sleep I tried again but first put down pseudo spin code on paper to better visualize the movement and what information would be needed. I wrote a new leg movement routine using that as a guide that surprisingly worked correctly the first time. However after that success the calibration of the tibia went out of whack. I found that the connecting rod from the encoder to the leg got bent which changed the calibration. Even with re-calibration it would not hold accurately since the bent connecting rod could rotate, changing the encoder angle. The rod got bent in the first place since the slot that the rod came out of the housing was not long enough for all possible motions. This is an older design for the encoder housing that I hadn’t replaced yet as it had been working well in the past.
So I decided to machine a new encoder housing using the new design. It took a lot longer than expected as I kept making basic machining mistakes. Apparently I haven’t been using the CNC mill enough lately and was trying to rely on my memory for all the steps needed to prep the stock material for cutting and other steps in the process that weren’t in the CNC programming. Luckily none of these mistakes were catastrophic so eventually I got the housing created. I did document the process for making the housing so hopefully the next time will be quicker and I don’t have to try to rely on memory for all the necessary machining operations.
I still need to unsolder the encoder from the old housing and swap in the new housing. Then reassemble the unit with a new connecting rod, calibrate, and hopefully continue with the gait coding.
Bob
(Still looking for a video editor. Also, how do I post a video on this thread without having to reference a YouTube video? Can I just reference a video on my C: drive? I have several short iPhone videos of the testing to show)
Calibration of the tibia went smoothly and the initial manual testing had it moving in 0.30 degree inputs.
I put the master computer back in the loop and started moving the leg along a straight line path of 5 inches. The leg followed the expected path very nicely. The next step added code to raise the leg, return it to the origin and then lower the leg. After a few bumps in the road, I got the code to perform more or less as expected. An issue now is that when the leg lifts, the code for returning the leg to the starting point starts moving the leg before the leg has finished moving up. I added a short delay after the leg lift but what is happening is that the motor done flag from the leg controller is not being updated to the master computer.
The code for the motor done flag update is embedded in the main leg controller loop and doesn’t execute until there is some type of input from the master computer and even then it just executes that one time. I tried a dedicated line from the the leg controller to the master computer with mixed results. Now that I have a spare cog in the leg controller I want to try out creating a continually running routine that outputs the motor status information to the master either via another serial link or by toggling a couple of I/O pins. That will be the objective for todays coding.
Bob
I checked out the website for Camtasia Studio. It looks promising, I may have to download the free trial and see how easy it is to use. I’m still leaning toward Pinnicle Studio, mainly due to the price. Most of the video that I make is relatively simple and I don’t need 90% of the bells and whistles most video editors have.
I still haven’t figured out how to directly embed a video from my computer into this forum if I don’t want to use YouTube.
I ended up getting Corel VideoStudio Ultimate while it was on their Black Friday sale. Now I just have to figure out how to use it!
Bob
Started watching the VideoStudio tutorials, should be able to put together a short video of the leg movements and gait after I get the video off the iPhone. I sold my old video camera and need to get a better camera down in the shop for filming video.
I still don't know how to get a video on this site without going through YouTube, I don't want to post some of the short clips I have but they would be appropriate for here. Otherwise I'm waiting until I get enough video compiled to upload to YouTube.
Bob
This testing has been fairly tedious but I’m close to getting the desired results.
Another coding item I’m working on is the feedback from the leg controller to the master. Right now each motor reports movement direction and whether or not the motor is active. I am only using that information for controlling the display RGB LEDs and determining when the femur motor has completed movement. The main code loop on the leg controller repeats on a loop that looks for an input over the serial link from the master. However, the code looking for the input serial string from the master is stuck waiting for the input string. Since the feedback to the master is in this same loop, it doesn’t get to send the updates back to the master except after a valid input string is recieved.
So I’m trying to figure out how to either have the GetString procedure not just sit there or create another serial loop that is dedicated just to the feedback. So far trying to code the routine to bypass the GetString procedure hasn’t worked as expected. I’m probably making some invalid assumption. I will give a couple more days and if I still can’t work my way through it I’ll post a question in the Prop1 forum.
Once I get through these 2 problems (and if nothing else new crops up) I’ll get back to putting the radio controller prop back into the loop. Then I can better test the ability to adjust stride length and direction on the fly vs coding in set values. The more prop boards in the loop make for harder testing, even just the master and controller means a lot of changing programming plugs and resetting the serial terminal.
Bob
Since I wanted to have something positive to show for the last week, I did pull out the old digital radio code and reinstalled it. It works OK after some tweaking so I can start controlling the gait stride using the radio remote controller now. Of course this also makes troubleshooting harder since now I have 3 Prop chips to program and troubleshoot issues.
Bob
In order to keep from forgetting to charge the battery occasionally I poked around in my supply stash and found a Lascar Electronics PanelPilot graphics display that I had purchased for another project (a project that didn't get very far off the ground). The display went into the stash and I forgot all about it. It's now got a new job of monitoring the battery voltage now. You can program the display and operation using free software from Lascar that is pretty intuitive. This display is a model SGD 24-M that has 2 analog inputs and 2 alarm outputs. For now I picked a display that had a nice digital and analog readout, selected the text, colors, input range values, and alarm setpoints. It was a simple job to wire into the power circuit. The laser cutter was used to cut the plastic for the display opening and everything went together nicely. Here are some photos of the display.
Hopefully this will help me to remember to keep things charged up. I've already changed the display setup since I took these pictures, Instead of 0-100% its now 9-15volts and the red bars start at 10.50 volts (manufactures recommended minimum voltage without charging) and low alarm setpoint also set at 10.5 volts. Lascar also has a 4.3 inch touchscreen version with 4 analog inputs, digital inputs, several outputs and even more customization options that might come in handy down the road. Its a little pricey but it could be fun to play with!
Bob
Since we are into a new year I thought I'd do an overview video of the project to bring everybody up to date on the design and current status of the robot. It doesn't cover everything but it goes over the basics.
Now back to the boring testing routines and slowly tweaking the motor PID software. I still need to get the Tibia oscillations figured out as that is the last obstacle to getting the tripod gait routine finished up.
Bob
Now the gait step is very linear and I can change the X and Z axis values manually to get the leg to move in different directions. With the smoother movement I was also able to determine that the Femur movement to lift and lower the leg at the beginning and end of the gait step has a minor overshoot that needs correcting but this isn’t a critical issue at this time.
Next step is adding the transmitter back into the loop so I can dynamically control the X and Z movements via the joystick. I started coding this but it isn’t working quite as expected yet. I think I have some incorrect assumptions that I need to review before I change any more code.
Once the transmitter is working I will add another leg controller to the testing and work on getting two legs to synchronize their movements. Of course this means enabling another serial port on the master so I can start getting used to using the 4 port serial transmission code from the OBEX.
Before adding the next leg, some mechanical work is needed on the leg since there have been a few mechanical changes to the test leg. I milled out 3 more magnetic encoder housings today, had a 4th almost done and made a mistake on the mill that crashed a $60 endmill into the vise and destroyed the piece along with the endmill. Luckily I have another endmill of the correct size and length, I have 7 more enclosures to make yet.
Bob Sweeney
These are the 10 encoder housings. The slot on the side of the housing is for a connecting rod that goes from the encoder shaft (I use the round delrin piece that have a hole in the middle that is a few thousands smaller than the encoder shaft diameter to give a good friction fit.) The delrin piece is drilled and tapped on the side so the connecting rod (4-40 all-thread) extends outside of the housing and attaches to the side of the leg. Leg movements then rotate the encoder shaft which gives the leg position.
This shows how the housing attaches to the leg support. 2 8-32 screws are used to attach the housing. This side is where the encoder body is attached.
This is the back side of the leg support. The housing attachment holes have not been drilled and tapped yet. The center of the encoder shaft is centered on the pivot point for the leg femur and tibia.
This is the Femur encoder housing and connecting rod to the encoder shaft. This is on the leg #6, the current test leg. This shows how it is all put together.
This is the tibia encoder housing and connecting rod.
I couldn’t get any good pictures of the coxa setup but there are some good photos of that earlier in this thread from a few months ago.
Bob Sweeney
These are the arms that are used by the coxa encoder to move the shaft as the coxa motor moves. It’s a slightly different design from the test version but it should be more reliable. The test version had issues with the spring wires popping out of the arm, this solves that issue.
These are the encoder housings with the wiring harness installed.
These are the coxa encoders mounted. Mods to this part included drilling the hole for the encoder and cutting 1 inch off the back of the mount to allow more room for the sensor plugs and wires that are mounted directly behind the piece. Some wires were getting pinched and the extra length wasn’t needed on this mount.
Here is a fully wired encoder in its housing. The other encoders still need their shafts cut down to 1/4” and soldering the wiring harness to the encoder. Initial calibration is connecting to a program to determine the output value to make sure the output doesn’t cross zero in the expected rotation range.
Now that’s sorted out I can continue with the initial calibration and start installing the encoders.
Bob Sweeney