Let's Make Robots!

Gluing/Melting the Plastic on the Dagu Rover 5

Do any of you know what kind of plastic is used to make the Rover 5?

It doesn't have the "feel" of ABS. My guess is it's polystyrene.

In the process of repeatedly opening the gearboxes on my Rover 5 bots, I've stripped a few of the threads, cut by the self threading screws, used to hold the gearboxes together. I know different types of plastics need different approaches to gluing or melting the plastic back together.

One of the threads I stripped held the encoder board to the gearbox casing. I repaired this with some thick super glue (CA) and it seems to be holding up okay.

I'm about to once again open up the gearboxes. While it's apart, I'd like to strengthen some of the threads.

I don't think the problems I'm having with the threads is a defect of the Rover 5. The stripped threads are a result of my having taken about the gearboxes many times as I've experiemented with the Rover 5. IMO, the Rover 5 is a pretty amazing bot for the price.

I have wondered about melting a small amount of Polymorph into the thread holes hoping the Polymorph would bind with the plastic. I know Polymorph sticks to some plastics really well while other plastics don't create a bond at all with it.

I don't have any modeling glue for plastic models. I'm guessing it would work well. I do have some acetone that can be used with some plastics to kind of melt the plastics together.

I'd rather not continue to use the CA since it has such a different consistency than the Rover 5 plastic. I also don't want to glue the gearbox together, I just want to reinforces the threaded holes.

Any ideas?

BTW, I recently noticed Parallax is selling a grey 2WD version of the Rover 5.

Here's a picture of one of my Rover 5 experiments.

I attempted to increase the encoder resolution by using more black and white stripes on the encoder disk. The increased resolution worked on a couple of the wheels but some wheels didn't read the new encoders are full speed.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I'm not sure why you would want to increase the resolution, at 333.33 pulses per revolution the standard encoder already produces an accuracy of 1.08 degrees. which will measure distance with an accuracy of better than 1mm.

Adding more stripes will not work at higher speeds because the optical sensor cannot respond quickly enough. Your chassis has the older optical encoders. The newer encoders us an 8-pole magnet and hall-effect sensors.

Yes, the Rover 5 chassis is now available in grey as well as white and there is a new wheel shape to help prevent the treads coming off too easily.

My advice for the threads is to try the polymorph. It will need to be very hot to bond to the plastic. Hot water will not do the job, use a cigarette lighter and melt the polymorph until it begins to bubble.

Worst case, you might need to buy a new Rover 5.

 

P.S. Glad you like my design :D

1mm accuracy is fine for measuring how far I've gone but it's a borderline for determining how fast I travelled that 1mm.

It may be I don't have a good algorithm for measuring speed but I found it a challenge to measure the speed of the wheels at low speeds. I want to be able to creep around with the Mecanum wheels. I've found it's the slow speeds where the encoder feedback is the most important for controlling the motors since the PWM level can fluctuate a lot where static friction is transitioning to kinetic friction.

With a higher resolution encoder, I could really slow the Rover 5 down to just barely creeping. I'm actually satisfied with the speed control as it is now, I was just trying to see if I could tweak the bot a bit. I used the encoder picture to illustrate why I've stripped the threads.

I'll try the Polymorph (what would we do without Polymorph?).

Thanks for the help.

Is there anywhere I can see pictures of these new encoders and wheels? I've looked at a lot of Rover 5 projects and I haven't come across any of these new features yet.

 

as the distance travelled between pulses is a fixed value you only need to time the number of microseconds between pulses to work out the speed from millimeter to millimeter as speed is distance / time. Some simple PID code should take care of the rest.

Normally I would just use a progressive average of the speed values.
For example:

Store the last 10 readings in an array. Every time a value is stored in the array your index is incremented. When the index = 10, reset it back to 0. This means that the array will always hold the last 10 readings.

Now average those readings (add them together and divide by 10). Use this result to increment or decrement your PWM in order to maintain a constant speed.

Increasing the number of samples to be averaged (I used 10 as an example) will slow the response time but will improve the smoothness of the response.

Dang it, that's a good idea (to time the pulses).

I've keep typing arguments as to why it wouldn't work well but by the time I get the reason typed, I realize I could work around that problem.

I'll need to seriously revamp my four encoder code.

As my code is now, I'm counting transitions of each encoder in to a circular buffer (much like your example).

Instead of a ring buffer containing pulse counts, I'll use a ring buffer to contain the time between pulses. A little math could easily change the pulse times to speed.

Very interesting. The possibility of timing the pulse lengths had crossed my mind but it wasn't until I tried to write reasons I didn't think it would work did I really take time to think of it seriously.

Now as I write this I feel like slapping my forehead. Duh, of course this is a good idea.

I think this could dramatically improve the performance of my bots. Very exciting.

I think part of my reluctance of timing pulses in the past was seeing the oscilloscope traces (of the encoder output) weren't all equally spaced. On average the transisions occured about 2ms apart at high speed but the trace wasn't divided up precisely into four segments. I can see now this doesn't really matter. As long as I average the speed over at least four transistions, it should be reasonalbly accurate. I'll likely keep my ring buffer a multiple of four so any irregularities in the enocoder blips wont causes a problem.

Here come the slowly creeping bots. (Did I mention this is exciting?)

Thank you for the great idea.

I look forward to seeing some video  :D

I use these sometimes when there is no room to retap up a size, they go down to 1/64"you should be able to get them at auto parts stores.

http://www.helicoil.in/helicoil.htm#gen

 

ossipee

Those are an interesting alternative.

Are they used in plastic? I've considered embedding a nut down inside the plastic, those coils may be easier to embed and I shouldn't have the same problem of stipping them out in the future.

Thanks for the link.

Try re-doing your discs, but use a mulitple of 4 for the number of stripes. These are "quad encoders" which have a phase of 90 degrees.

In English:

When one sensor is catching a change, the other sensor should be right in the middle of a stripe --and vice-versa.

I think most of my attempts were multiples of four. I was surprised at how many different encoder patterns produced nice 90 degree out of phase patterns.

I thought I'd lose the ability to sense direction when increasing the number of stripes but the o'scope traces looked great with one trace out of phase with the other by 90 degrees (or close enough to still indicate direction).

While hand turning the gears the traces looked great, but once I put the gearbox back together the traces would flatten out at high speeds. The down blip amplitude would keep getting shallower as the motor speed increased.

It made me think that maybe the folks at Dagu had already tried this experiment and used the disks with four black stripes for a reason.

There are little trim pots on the back side of the encoder PCB I considered playing with but I got really tired of assembling and disassembling the gearboxes and decide 333.3 ticks per revolution was good enough after all.

Actually it's kind of tough to use the 333.3 ticks per rev for speed feedback when the bot is moving slow.

If Dagu does start using magnetic encoders on these, I hope they increase the resolution.

There was a huge improvement in the way my Mecanum wheeled robot behaved once I added encoder feedback. With greater encoder resolution, I think the low speed control would be even better than it is now.

I would use a machine screw a little larger than the one that was in it.

This is how I have fixed problems like this before.