Stonehenge 3: A fast, precise robot arm

[rghansen]

When the program runs, it produces a logfile called logfile.dat on the NXT. If you can send me a copy of it, I can give you a better idea of what went wrong.

Even better, I've attached the logfile.dat decoder, the nxt.h file, and the simulator program. Be warned that the simulator's runtime estimates are about 30% too low.

But I'd still like to see the logfile.dat if possible. I don't like unleashing poorly behaved software on the world.

I hope to have time tomorrow to shoot some photos.

Did you build it with the standard Lego cables? Although they are perfect for your average 10+ robot builder, I've found that they are much too stiff to attach to anything that has to move quickly. I had trouble getting even the slow, first version of Stonehenge to work with the standard cables. Since the motor control software is fairly finely tuned, the wrong cables could easily cause the problem you mentioned.

I've already bought two sets of flexi-cables from mindsensors.com. They deliver to Europe.

Please let me know if you have any other questions.

[rbnnxt]

Thanks for the prompt reply. I have used standard cables, but they work OK with the original stonehenge, after careful jiggling. I'll look at finer cables as well though. Thanks for the source for these.
I attach the logfile for you (as a zip file) to look at. Unfortunately I will not be able to do much further for a while as I shall be away, but I will look at the decoder when I return.
I like the mods to the grabber jaws. It makes it much smoother and more reliable when grabbing than the original version. I modified the original nxt-g code to allow for slightly different rotation angles in the grabber motor, but it works with the original version OK.
Although I can't access the hardware, I will try to look at the thread whilst away.

[rghansen]

You're right, it wasn't the cables, it was a piece of debug code.

The decoded logfile:

0.000: LoopCnt 1

sortState: 100
0.001: NumBallsFound 0
0.002: iStation: 1
0.003: Turn value 0
0.307: Turn value -64
Rotate error -1
0.458: Open: -38
1.259: Fall: -135
1.730: Close: 6
1.881: Open: -38
2.032: Close: -37
Error 20

Each entry has a time stamp which is not printed if it's identical to the time stamp of the previous entry.

On its first pass through the state machine, the arm rotated from its initial position (Turn value 0) to the rail pickup point (Turn value -64) with an error of only 1 degree.

It then opened the gripper all the way (Open -38), dropped the arm towards the rail (Fall -135) and tried to grab a ball.

So far, so good, but then things started to go wrong.
I forget to mention that the values for MIN_BALL_THRESHOLD and MAX_BALL_THRESHOLD are very critical and need to be adjusted to match your hardware setup.

When the grabber closed, the angle it returned (Close 6) was just 1 degree larger than the MAX_BALL_THRESHOLD of 5.
So the program thought it came up empty, but just to make sure it tried again and opened the grabber (Open -38) and closed it again.
This time it came up with a value of -37 (Close -37) which probably means that it tried to bite into the alignment pin with its rear finger.
This is something the program shouldn't be doing so it stops with a "biting into structure" abort (Error 20). I put in this abort so that I could see just where I was having alignment problems.

The clearance between the rear finger and the alignment pins is an area for improvement in this design.

The best long term solution for this problem requires a major redesign to provide more space between the rear finger and the alignment pins.
However, if this really was your problem, then just pulling the rubber part of the ring finger a millimeter or two away from the plastic part of the finger should provide enough clearance.

If this doesn't help, let me know.

This design does require a fair bit of fine tuning to get the most out of it. This may be asking too much of your standard 10+ robot builder, but from what I've seen of your work, you should have no problem.

[rbnnxt]

I don't think it is hitting the guidance beam. However I suspect it is fouling the connector rod against the gear on the grab assembly. I'll check against the photos when you post them. I won't be able to do more on the model for a few days.

[rghansen]

I don't think it is hitting the guidance beam. However I suspect it is fouling the connector rod against the gear on the grab assembly. I'll check against the photos when you post them. I won't be able to do more on the model for a few days.

That was my second guess, but I'd thought you had already made that change.

At least in my implementation of the original design, the connecting rod between the motor and the front finger would rub on the back finger causing problems. I'll be uploading some detailed pictures soon which will give you a better look at the areas I've tweaked.

Thanks to Philo's help, I've managed to install a copy of LDD, but it will be a while before I can do much with it.

[rbnnxt]

I think I've found the problem. I had the grab and lift arm motors the wrong way round. I think your program is different to the nxt-g allocation. Also I notice that the port for the light sensor is also altered. Now I've corrected the wiring it is beginning to work. Some adjustments necessary, as is usual for a complex model, but there is light at the end of the tunnel!

[rghansen]

I think I've found the problem. I had the grab and lift arm motors the wrong way round. I think your program is different to the nxt-g allocation. Also I notice that the port for the light sensor is also altered. Now I've corrected the wiring it is beginning to work. Some adjustments necessary, as is usual for a complex model, but there is light at the end of the tunnel!

Thanks for the good news.

After much trial and even more error, I've finally come up with a set of almost useable photos:

This one shows the 3-beam added near the top of the arm alignment fork to stiffen it

3-beam added to top of arm alignment fork

stonehenge_arm_fork.jpg (90.16 KiB) Viewed 11341 times

The front side of the arm with the connector rod connected to a 3-beam instead of directly to the motor to allow for more clearance between the connecting rod and the rear finger. I also changed the back stop for the 3-beam from a small 2-beam to a 7-beam (I had run out of 5-beams). This gives better linearity when the fingers close on a ball.

stonehenge_armFront.jpg (91.98 KiB) Viewed 11341 times

[rghansen]

I'm including just one more photo to show that if given enough time, I can actually get one of these fully automatic digital cameras to focus on what I want.

It is a closeup of the light shield. The 3 black beams sit on top of beams that are suspended from the two stands on either side of the color sensor.

stonehenge_lightShield.jpg (107.96 KiB) Viewed 11341 times

[rbnnxt]

Thanks for the photos. I think you may also have altered the bottom end of the ball chute where it meets the first stand. Can you give any detail of alterations here? For example, it looks like you've used two 13 beams instead of the 13 plus 11 one specified in Philo's original design. I can't quite see the detail at the bottom end on the video.

[rghansen]

Thanks for the photos. I think you may also have altered the bottom end of the ball chute where it meets the first stand. Can you give any detail of alterations here? For example, it looks like you've used two 13 beams instead of the 13 plus 11 one specified in Philo's original design. I can't quite see the detail at the bottom end on the video.

You have a good eye.

stonehenge_railBottom.jpg (88.76 KiB) Viewed 11324 times

I used a 13 for the simple reason that I had run out of 11s. But this also let me easily connect it to the nearby stand to stiffen both of them. I'm not really sure whether this was necessary or even beneficial. This is a critical area of the design and I spent a lot of time adjusting the spacing between the bottom ball holder and the alignment pin.

stonehenge_rail_top.jpg (88.36 KiB) Viewed 11324 times

I connected the rails together with the following construction which allowed me to easily adjust the rail spacing. If the spacing is too narrow, the balls tend to fall off, if it's too large, they get stuck.

stonehenge_rail_top_foot.jpg (87.47 KiB) Viewed 11324 times

I also moved the top of the rail in 1 hole. At higher speeds, the balls tended to bounce off the inner rail and jump over the outer rail.