At the job that pays for my Hexapod, we are in a refueling outage again so not too much time available to work on the robot. Today was my day off and I spent a few hours in front of the computer. Mainly I was testing the IK routines (they seem to be working correctly now!) and figuring out how to input a floating point value like 22.5 from the terminal using the 4 port serial object. No terribly successful, finally gave it up as I wanted to be moving forward. For now I am just manually hard coding the float values in the code and then recompiling the program each time. The output values are then validated against a spreadsheet on the iPad. For testing purposes I think I'll add FullDuplexSerial object just for debugging the next time I get on the computer, there are plenty of examples on the forums that use this object the way I want.
No progress on the LIDAR unit, that will be on the back burner until I get the IK working with the leg.
Another day off spent in front of the computer! Finally got the ability to manually input floating point values from the terminal by using the Parallax Serial Terminal as the debugging object. The good thing about all the research is I read about using FullDuplexSerial4port object as a drop in replacement for pcFullDuplexSerial4FC. Tested out this combination and it works fine for my needs.
Started to copy in code for XBee input from the transmitter and code for sending data from the master to the leg computer now. I need to study it again since its been a while since I ran that part of the code. Once that is all up and running I will be able to enter specific x, y and z coordinates and see how well the test leg responds and also check for repeatability.
I'm finally back to a normal work schedule and found some time to look at the robot again. I started by running the IK Floating Point routine first. I made up a grid and fed some values into it when I noticed that although I was getting angle outputs, the values were not changing as expected. After troubleshooting I found I had previously commented out the wrong sections of the code during testing. Restoring the code helped but I wasn't getting valid angle values either. After a bunch of hair pulling, I tried some different test values and suddenly it started working, at least the output wasn't garbage. Thinking it through I believe my test values were impossible to reach using the equations. I need to check out the range of acceptable values so they can be entered as limits in the software.
Coming back to the software after a long absence is difficult, I had to try to remember all my thought processes from the last time I was in the software, not easy! I don't have a lot of time to work on the robot this week, getting ready for a dive trip in Ohio. I'll attempt to get some work in at least catching back up to where I stopped the last time.
I removed the bad prop activity board and replaced it with another one. After wiring it up the same as the previous board I tried to run some of the older test programs without success. It's late so I'll give another try tomorrow, may move further back in history of the .spin files and just get something moving again. It's been a while since I'd spent any significant time on the leg controller, all my time lately has been the IK equations. Got to make sure I didn't introduce some wiring errors first. No other plans for tomorrow other than get back up to speed on my old, forgotten programing.
Hi DiverBob
This is a pretty challenging part of your project.
Thanks for keeping up with your postings.
I look forward for them.
Your project is way beyond my skill level, but I read every one of your updates.
Thanks for your endurance.
Gary
That was probably the longest gap in updates I've had since I started this thread. Unfortunately my job has been keeping me busier than expected and thus severely reducing my time working on the robot. There have been no mechanical changes to the hex but I have been working the programing of the Inverse Kinematics engine. Due to the configuration of the legs, I'm finding that the standard calculations aren't coming out with angle values that are correct. So I created a full sized wooden mockup that I can use to validate some of the data I'm getting. Time is the biggest obstacle to this portion of the programming, I need some fairly long periods of time to devote to the project but the rest of life gets in the way! I will continue to work on this problem, it's just going to take longer than I originally anticipated. Today is a very rainy day so hopefully I'll get through the honey-do list and get some quality time on the keyboard tonight.
After much thought and number crunching, I believe I finally have good IK formulas for my leg setup. Next stage is to program these into Spin. The mockup I made was useful in visualizing the leg tibia and femur angles and then using a protractor to valid the numbers. Next week is shaping up to be pretty busy so I don't expect to have a lot of time available to program but I'll see what I can get done. I should just have to make some slight variations to what I've already coded and then validate the prop's output against the spreadsheet. Then I can see about getting the test leg to start moving and see how accurate these calculations are. Hopefully I'll have some useful video to post out of that test.
I was able to successfully update the IK routines in Spin and now the test values on the monitor match the Excel spreadsheets. Next I'm going to use the values from the spreadsheet as input angles and see where the leg moves. I will use a piece of paper under the leg to mark each position and see if the movement is as expected.
I did a test of the values from the spreadsheet by manually entering the angle values for each motor and then plotting the position of the leg tip. Well, I learned something that had been nagging me but I hadn't dove into the problem. Since my leg uses a parallelogram with one corner in a fixed position to control movement and the motors manipulate the sides of the parallelogram, the standard hexapod IK formulas will not work correctly. The formulas are off by just enough to mess things up, especially the further the leg gets from a 90 degree position relative to the ground.
Essentially the femur and tibia angles have to be measured from the same primary pivot point. Now I have to figure out how to break the side view of the leg into the appropriate triangles so I can come up with the angles needed. I started by running this by hand on paper but my drawing skills leave a bit to be desired. Going out to get some large graph paper and will draw a scale paper model to help accurately visualize the movements.
It's been a busy couple of weeks trying to come up with the calculations that will work for my Hexapod leg design. I think I've finally got it, it took a lot of reviewing of geometry and trig to come up with the formulas. Tomorrow I'll be testing the formulas on the test leg and see how close my thinking comes to reality!
Unfortunately my new main computer decided to die on me so instead of using Excel, I'll have to run the tests using Apple Numbers on my iPad. It's a bit harder to set up formulas in Numbers in my opinion but it will have the advantage of portability.
Not sure I like the new forum setup, it's not as intuitive and although it looks OK on the iPad, it leaves a bit to be desired. Hopefully some of the more annoying features will be fixed soon!
Success last night! Finally got evidence that the math is good, was able to manually input angle values from an Excel spreadsheet and the test leg moved in a straight line. Now the accuracy isn't where I want it to be, especially for the coxa but I was half expecting that. I want to try using some 'fudge' factors and see if I can program out some of the slop but I suspect I need to come up with a better feedback mechanism for the coxa. The multi-turn precision potentiometer just isn't moving enough to get a good feedback signal to the software. I think a better sensor would be a magnetic angle sensor where a rotating magnet on the coxa shaft is used to with a magnetic angular sensor to output degrees of rotation. Now to do some searching for something like that in an affordable price range.
I ran out of time last night but will run some more tests tonight, should get some photos/video together showing the testing process also.
Look into the as4050 from austriamicrosystems for magnetic angle encoders. Duane Deign became quite the expert on those as chips.
Jim
Thanks for the heads up, I'll take a look at it. I was hoping to find some type of enclosed unit with a shaft I can connect to and then just wire the unit into my circuitry but the few I've found are very expensive. This is surprising as the plain chips usually aren't that pricy.
No time to play tonight, had to replace a broken built in microwave and find a leak. Microwave is done, waiting for parts to fix the shower valve. All this other stuff is taking time away from playing!
Look into the as4050 from austriamicrosystems for magnetic angle encoders. Duane Deign became quite the expert on those as chips.
Jim
Lol
Thanks for the heads up, I'll take a look at it. I was hoping to find some type of enclosed unit with a shaft I can connect to and then just wire the unit into my circuitry but the few I've found are very expensive. This is surprising as the plain chips usually aren't that pricy.
No time to play tonight, had to replace a broken built in microwave and find a leak. Microwave is done, waiting for parts to fix the shower valve. All this other stuff is taking time away from playing!
There are some nice magnetic encoders there. I especially like the AS5311
High Resolution Magnetic Linear Encoder, it can take a round multiple magnet and provide multiple output options. Has anyone played with one of these yet?
I'm thinking that I could epoxy a ring magnet to the swing arm and take readings from that. Since it only swings 120°, I may even be able to get away without having to add limit switches for end of travel. If I leave the existing potentiometer in place, I can use the low or high value from the pot to provide a calibration signal to the software.... Will need to think this one through for a bit. They also have a breakout board available, may need to place an order to give it a try.
Looks good but I would have to do some mods to the gear reduction unit for it to fit. It could be fitted to the shaft of the idler gear but I would have to build all new shafts and press fit the gears again. The more I think about it, the more I like the linear magnetic encoder. They also sell various sized round magnets that I can epoxy to a gear or even put it on the upper mounting bracket (new thought!). I need to check the OPEX and see if anyone has done some code for this. The demo board they for it have appears to be able to fit into the area available. I would have to make a mounting bracket but that shouldn't be too hard to design.
Spent some time working on improving the accuracy of the Tibia movement. I got the movement accuracy improved by a bit and was able to eliminate a chunk of code that was supposed to handle that. Next stop, Coxa accuracy. I want to try one more time to get the Coxa to respond more accurately, I played a bit with the ADC routine and improved it somewhat. Want to spend an evening doing just Coxa testing.
I bought one of those encoders, it was a nice sturdy ball bearing unit. I made a lengthy post about it here with all sorts of juicy details that you would find incredibly valuable but I'll be gosh-darned if I can find it because this new FORUM HAS NO ADVANCED SEARCH FEATURE!
While doing some coding and testing on the Coxa movement routine I was seeing a increasing error as the leg would swing from 30° through 150°. After thinking about it I realized that as the slope of the ADC output is calculated, it goes from the minimum angle to the max angle. For the Coxa the slope value is about 5.3. However, since I only use floating point math routines during initialization due to needing the cog for other purposes, I was dealing with the slope as a integer, 5. This explained the gradually increasing error rate as the leg approached 150°.
I could use a floating point routine that doesn't need a cog, but tried a math trick instead. I took the floating point value to the right of the decimal point (5.3 -> .3), multiplied that by 10 (3) and saved it as an integer. Now when the target ADC value is calculated by multiplying 5 by the requested angle change and then adding that value to the minimum ADC value, the next step also adds on the value of the angle change divided by 3. The result comes out very close to the true value if everything had been done in floating point math.
This improved the overall accuracy of the desired position but getting small 1° movements is hit or miss. Got a couple of ideas for coding that I want to try out first. One concept would be a 'creeper' routine that simply turns the motor at a speed slowly until the actual ADC value is reached. For this to be effective the movement has to always be less than the desired value by some small value and then it 'creeps' to the actual position. In some ways this is like part of a PID controller.
During testing the Coxa by moving it in 1° increments the leg would move the right direction but on the next 1° movement the leg moves the opposite direction. This continues for each 1° change. Checking the ADC output shows the value near the expected value with the motor off but when the next motor move command is sent, the ADC value is 20-30 points different. This was the cause for the motor to reverse direction, but why was the final ADC for the motor not the starting ADC value for the next move? I put in some code to read the ADC value for several loops of the code and saw the ADC value rising over 2-3 cycles after the motor had stopped.
Thinking it through I believe it might be the filter used for reading the ADC is the source of this problem. The filter takes 10 readings, sorts the order from low to highest, drops the 3 low and 3 high values and then averages the remaining 4 values. However, during a motor move the input to the ADC is changing rapidly so the values I drop at the low or high end are closer to the true value. So it takes a couple of read cycles for the filtered output to show the actual ADC value. I can write some tests to prove or disprove this theory but if this is the case then I need to come up with a better filtering mechanism that still rejects the wildly high or low valves I've seen in the past. I could use a routine that compares each ADC output to the previous value and if the difference between them is more than a specified amount, reject the value and grab the next value. But, what if there are 2 bad readings in a row? Suggestions?
I'll have to work on this later, the robot has been disassembled and is traveling to be displayed at a metal working open house. Not even taking the batteries, just showing the machining and design for this event.
Back to research and I'm pretty sure that I need to implement a PID control for motor positioning. There are tons of examples out on the web, now its just time to figure out a starting point and play with it. I'll start with just a simple Proportional control and add on to it. The goal is minimal overshoot, response time doesn't have to be overly fast because of that.
First I have to reassemble the robot from traveling after the show. It sustained some damage on the trip, the body rolled in the back of the car and cracked one of the plastic cover panels for the motor controllers badly. The worst thing is that I don't have any more of that particular plastic left over, it was picked up surplus many years ago and has been used for quite a few projects. I will have to find another source for plastic panels and since it likely will not have the same finished look, I'll need to make new covers for all the other sides also. It will be so much easier when it can walk out of the basement and into the back of the SUV without being disassembled!
Implemented the 'P' (proportional) part of a PID controller in code. It works fairly well one of bug to fix so far, (motor continues to run once it hits the target even with a motor stop command) and needing some code to reduce the amount of 'jerk' that occurs when the motor is started from 0 to full speed. Got some ideas on how to reduce the jerk, ready to try them out and see how effective it is. A side benefit is that the code is much simpler so far than what I coded before. I still have to have error coding to look for a stalled motor (check if the ADC value is changing) but I am able to re-use my previous code with minimal changes.
Once I get the proportional section of the code running well, then I'll implement the 'I', Integral, section. Some of my reading indicates that it is possible that I won't need the 'D', Derivative, and others insist that it is always needed. I suppose that testing will show if adding it to the PI code is a good idea or not.
Got the Proportional portion of the PID controller working on the coxa motor. So far all the bugs have been worked out, been testing the setup with various input values and analyzing the output along with watching the leg movement. It all looks very good with minimal overshoot even with large position changes and it responds to a change in 1 degree commands now. With the ability to perform 1 degree changes I don't need to change my feedback mechanism from a potentiometer to something different, that could have meant some significant mechanical re-work. At this point I'm not sure I need to add in the Integral and Derivative portions of the PID controller. Since this application is more like a servo and not a continuously running process, the I and D coding might be unnecessary. Continued testing should identify if I'm wrong on this account.
I did change the ADC routine and removed the filter on the ADC output completely. What I've seen from testing output values is that the occasional bad ADC output is compensated for by the PID controller. For example, if a abnormally high value comes through that creates a larger error value, the motor speed is told to increase. But the majority of ADC readings will be correct, changing the error back to the correct level and returning the motor speed to the correct. Also, the motor can't react as quickly as the electronics so the effects are effectively removed.
The resulting code is much simpler which should make for easier troubleshooting. That means that I started thinking of enhancements! Right now the PID routine is only called if there is a position change event. This means that once the coxa has completed the move there is no monitoring to maintain it in that position. I'm thinking of making the PID routine a continuous loop and it monitors for error changes. This way any external forces on the coxa will be continuously reacted to and the motor energized as needed to counteract the force. I'll give that a try today and see how it works out.
Another item I noticed is that I want to add some code to get the actual leg position during initialization. Currently initialization wants to put all motors at a specific position, this could be a very bad thing if not controlled properly. So the right answer should be to read the actual ADC value on startup and convert that to an angle value. This way the actual leg position is known and the master controller can position it were it needs to.
I successfully implemented the coxa PID controller to run in a continuous loop on its own cog. Actually its more a PI controller, no Derivative is being used and even the Integral is not a standard setup, but it works for this setup! It monitors for changes to the input angle which are sent to the routine as a specific ADC value to move towards. I put in a simple speed ramp where the larger the error signal the faster the motor runs to get there but it uses the S curve values from the previous motor ramp code to minimize the amount of jerk experienced. As the motor approaches the desired ADC value, it then uses the same S curve values to slow down. Once the motor is within a dead band zone, the motor is de-energized. An earlier version of the code continually energized the motor to stay at the position but I was worried about prematurely wearing the motor commutators so using the dead band zone should be a good compromise. The mechanical design of the leg makes it very difficult for the motors to move via an external force.
Another feature incorporated is a overall speed control. A % of full speed can be entered (10% through 100%) and the overall motor speed is reduced by the desired amount. This is done by taking the speed value calculated and just before it is sent to the HB-25s, the speed value is multiplied by the input as a percentage of full speed. This way the S curve values are still providing an input to the new speed.
Due to testing the leg was being left in various unknown positions at all times. Code now calculates the initial leg angle based on the initial ADC values and the calculated slope of the ADC vs Angle graph. This will be helpful later when all 6 legs are attached and it is supporting its own weight.
The same PID concept was incorporated into the Femur. Initial test results are just as good as the coxa results with 1 degree position changes working nicely. The amount of spread between each degree on the femur on the ADC is about 66 counts vs 5.8 counts on the coxa. This means I could use the same basic code base and be able to enter femur degrees in 0.1 degree increments. I don't think that will be needed for the femur but that capability might be nice for the tibia motor movement.
Running some of my calculated IK data from a spreadsheet manually into the leg motor positions initially shows a very good accuracy and repeat-ability. I will test that part out in more detail once I get the tibia PID control working.
I'm really happy where the code base is going right now. Even though I'm throwing out a lot of code that was painfully debugged, the new code is much faster, more accurate, and easier to troubleshoot. Even then I have been able to salvage some of the more interesting parts of my old code such as the S curve ramps, error checking, and data input. Right now I'm connecting directly to the leg controller for control inputs, soon I'll be sending commands via the master computer and then via the digital radio transmitter again.
Glad to see you are able to move forward again.
Jim
It's always better when you aren't banging your head on the table trying to figure out what direction to go next to get the program to do what you want! I'm looking forward to programming right now instead of avoiding it.
Comments
No progress on the LIDAR unit, that will be on the back burner until I get the IK working with the leg.
Started to copy in code for XBee input from the transmitter and code for sending data from the master to the leg computer now. I need to study it again since its been a while since I ran that part of the code. Once that is all up and running I will be able to enter specific x, y and z coordinates and see how well the test leg responds and also check for repeatability.
That's all until my next day off, next Friday.
Don't forget about this FDS Object :
http://forums.parallax.com/showthread.php/129776-Anybody-aware-of-high-accuracy-(0.7-or-less)-serial-full-duplex-driver
Jim
Coming back to the software after a long absence is difficult, I had to try to remember all my thought processes from the last time I was in the software, not easy! I don't have a lot of time to work on the robot this week, getting ready for a dive trip in Ohio. I'll attempt to get some work in at least catching back up to where I stopped the last time.
This is a pretty challenging part of your project.
Thanks for keeping up with your postings.
I look forward for them.
Your project is way beyond my skill level, but I read every one of your updates.
Thanks for your endurance.
Gary
Bob
Essentially the femur and tibia angles have to be measured from the same primary pivot point. Now I have to figure out how to break the side view of the leg into the appropriate triangles so I can come up with the angles needed. I started by running this by hand on paper but my drawing skills leave a bit to be desired. Going out to get some large graph paper and will draw a scale paper model to help accurately visualize the movements.
I'm still watching, and glad you are hanging in with the Forum upgrades.
Unfortunately my new main computer decided to die on me so instead of using Excel, I'll have to run the tests using Apple Numbers on my iPad. It's a bit harder to set up formulas in Numbers in my opinion but it will have the advantage of portability.
Not sure I like the new forum setup, it's not as intuitive and although it looks OK on the iPad, it leaves a bit to be desired. Hopefully some of the more annoying features will be fixed soon!
I ran out of time last night but will run some more tests tonight, should get some photos/video together showing the testing process also.
Jim
Jim
Thanks for the heads up, I'll take a look at it. I was hoping to find some type of enclosed unit with a shaft I can connect to and then just wire the unit into my circuitry but the few I've found are very expensive. This is surprising as the plain chips usually aren't that pricy.
No time to play tonight, had to replace a broken built in microwave and find a leak. Microwave is done, waiting for parts to fix the shower valve. All this other stuff is taking time away from playing!
Jim
Lol
Thanks for the heads up, I'll take a look at it. I was hoping to find some type of enclosed unit with a shaft I can connect to and then just wire the unit into my circuitry but the few I've found are very expensive. This is surprising as the plain chips usually aren't that pricy.
No time to play tonight, had to replace a broken built in microwave and find a leak. Microwave is done, waiting for parts to fix the shower valve. All this other stuff is taking time away from playing!
High Resolution Magnetic Linear Encoder, it can take a round multiple magnet and provide multiple output options. Has anyone played with one of these yet?
I'm thinking that I could epoxy a ring magnet to the swing arm and take readings from that. Since it only swings 120°, I may even be able to get away without having to add limit switches for end of travel. If I leave the existing potentiometer in place, I can use the low or high value from the pot to provide a calibration signal to the software.... Will need to think this one through for a bit. They also have a breakout board available, may need to place an order to give it a try.
http://www.ebay.com/itm/400P-R-incremental-rotary-encoder-400-pulses-CNC-Servo-Stepper-Motor-A-B-Phase-/231622140685
I could use a floating point routine that doesn't need a cog, but tried a math trick instead. I took the floating point value to the right of the decimal point (5.3 -> .3), multiplied that by 10 (3) and saved it as an integer. Now when the target ADC value is calculated by multiplying 5 by the requested angle change and then adding that value to the minimum ADC value, the next step also adds on the value of the angle change divided by 3. The result comes out very close to the true value if everything had been done in floating point math.
This improved the overall accuracy of the desired position but getting small 1° movements is hit or miss. Got a couple of ideas for coding that I want to try out first. One concept would be a 'creeper' routine that simply turns the motor at a speed slowly until the actual ADC value is reached. For this to be effective the movement has to always be less than the desired value by some small value and then it 'creeps' to the actual position. In some ways this is like part of a PID controller.
Thinking it through I believe it might be the filter used for reading the ADC is the source of this problem. The filter takes 10 readings, sorts the order from low to highest, drops the 3 low and 3 high values and then averages the remaining 4 values. However, during a motor move the input to the ADC is changing rapidly so the values I drop at the low or high end are closer to the true value. So it takes a couple of read cycles for the filtered output to show the actual ADC value. I can write some tests to prove or disprove this theory but if this is the case then I need to come up with a better filtering mechanism that still rejects the wildly high or low valves I've seen in the past. I could use a routine that compares each ADC output to the previous value and if the difference between them is more than a specified amount, reject the value and grab the next value. But, what if there are 2 bad readings in a row? Suggestions?
I'll have to work on this later, the robot has been disassembled and is traveling to be displayed at a metal working open house. Not even taking the batteries, just showing the machining and design for this event.
First I have to reassemble the robot from traveling after the show. It sustained some damage on the trip, the body rolled in the back of the car and cracked one of the plastic cover panels for the motor controllers badly. The worst thing is that I don't have any more of that particular plastic left over, it was picked up surplus many years ago and has been used for quite a few projects. I will have to find another source for plastic panels and since it likely will not have the same finished look, I'll need to make new covers for all the other sides also. It will be so much easier when it can walk out of the basement and into the back of the SUV without being disassembled!
Once I get the proportional section of the code running well, then I'll implement the 'I', Integral, section. Some of my reading indicates that it is possible that I won't need the 'D', Derivative, and others insist that it is always needed. I suppose that testing will show if adding it to the PI code is a good idea or not.
Bob
I did change the ADC routine and removed the filter on the ADC output completely. What I've seen from testing output values is that the occasional bad ADC output is compensated for by the PID controller. For example, if a abnormally high value comes through that creates a larger error value, the motor speed is told to increase. But the majority of ADC readings will be correct, changing the error back to the correct level and returning the motor speed to the correct. Also, the motor can't react as quickly as the electronics so the effects are effectively removed.
The resulting code is much simpler which should make for easier troubleshooting. That means that I started thinking of enhancements! Right now the PID routine is only called if there is a position change event. This means that once the coxa has completed the move there is no monitoring to maintain it in that position. I'm thinking of making the PID routine a continuous loop and it monitors for error changes. This way any external forces on the coxa will be continuously reacted to and the motor energized as needed to counteract the force. I'll give that a try today and see how it works out.
Another item I noticed is that I want to add some code to get the actual leg position during initialization. Currently initialization wants to put all motors at a specific position, this could be a very bad thing if not controlled properly. So the right answer should be to read the actual ADC value on startup and convert that to an angle value. This way the actual leg position is known and the master controller can position it were it needs to.
Bob
Another feature incorporated is a overall speed control. A % of full speed can be entered (10% through 100%) and the overall motor speed is reduced by the desired amount. This is done by taking the speed value calculated and just before it is sent to the HB-25s, the speed value is multiplied by the input as a percentage of full speed. This way the S curve values are still providing an input to the new speed.
Due to testing the leg was being left in various unknown positions at all times. Code now calculates the initial leg angle based on the initial ADC values and the calculated slope of the ADC vs Angle graph. This will be helpful later when all 6 legs are attached and it is supporting its own weight.
The same PID concept was incorporated into the Femur. Initial test results are just as good as the coxa results with 1 degree position changes working nicely. The amount of spread between each degree on the femur on the ADC is about 66 counts vs 5.8 counts on the coxa. This means I could use the same basic code base and be able to enter femur degrees in 0.1 degree increments. I don't think that will be needed for the femur but that capability might be nice for the tibia motor movement.
Running some of my calculated IK data from a spreadsheet manually into the leg motor positions initially shows a very good accuracy and repeat-ability. I will test that part out in more detail once I get the tibia PID control working.
I'm really happy where the code base is going right now. Even though I'm throwing out a lot of code that was painfully debugged, the new code is much faster, more accurate, and easier to troubleshoot. Even then I have been able to salvage some of the more interesting parts of my old code such as the S curve ramps, error checking, and data input. Right now I'm connecting directly to the leg controller for control inputs, soon I'll be sending commands via the master computer and then via the digital radio transmitter again.
Bob
Jim