So yes, it’s damn hard and thanks for recommendation, maybe I will have to buy another encoders after all (thought about hall effect sensors but my motors are missing extended shaft to put the magnetic disc on), but for now let’s fight with those I’ve got:)

It is tricky to get these robots to go straight, even with encoders it can be tricky.

I have tried to use the redbot wheel encoder, but I’ve found that it’s not very good. I’m not sure it gets great reflections off the encoder discs and so the one I had seemed to miss pulses fairly regularly… These encoders were also used in a recent robot building MOOC, and the forums suggest that other people had problems…

I would recommend using quadrature encoders which give both the speed and direction of the wheels. We are planning to release some encoders soon, but it’s on hold for a month or two as I’m snowed under trying to finish off my PhD thesis…

As an alternative I’d recommend these encoders. They’re a bit expensive, and you may need to redrill the holes to get them to fit on the Dagu motors, but they work well.

Regards

Alan

How do you manage to get it to go straight? My motors just need different PWM values otherwise one is stronger. I’m trying to use redbot wheel encoders (optical encoders) to help detect each wheel speed and react accordingly, but it’s not that simple (long story).

I wonder whether I should just find some fixed values, but that would mean it would just go with same speed everytime, as it’s not possible to just find some ratio and apply it (as my experiments have shown).

This sounds like it could be a battery problem. What type of batteries are you using to power the robot? If using 6xAA alkaline batteries then I would recommend changing to 6xAA rechargeable (NiMh) batteries.

Regards

Alan

Also,i’ve a little problem about my Robo, i think that the Hardware is ok. But when i open in Internet the IP-Adress from the RPI he open all and show the stream from the camera, but a few secconds after he doesent react on my commands (left, up, ect.)

I hope realy that you can help me

Peter

Reconnected everything, fired it up, and viola, working robot. So apparently something was corrupted in the controller sketch..or bootloader? Not sure how it happened, but will keep an eye on it to make sure it isn’t some chronic issue that would suggest i replace the controller. My gut says, we’re fine.

Thanks for the fast reply and expert assistance!

Bootloader corruption is possible on the mini driver, although it should hopefully be fairly rare.

It sounds like you’re familiar with Arduinos so could you please try uploading the blink sketch to the mini driver? You can use either the Pi or an external PC although if you use Windows you’ll need to install drivers (see product page). The Mini Driver is classed as an ‘Arduino NG or older w/Atmega8′, more details on programming the mini driver can be found in this blog post.

The Python web server on the Pi will try to connect to the Mini Driver on startup to check the firmware (Arduino sketch) version. If the correct version isn’t found then the firmware sketch will be compiled and uploaded.

Regards

Alan

1. initially, for power, I used 6 duracell AA alkaline batteries. The robot worked, but it appeared I had to swap motor leads, as movement direction was opposite from what it should be, so powered down to swap motor leads.
2. Powered it back up, nada. No neck servo action, no motors. Still have camera operability, connection to pi is fine. Didn’t seem like something that abrupt would be battery issues, but, to eliminate:

a. swapped to 2300 mAh nimh batteries (fuly charged), no change.
b. powering pi from 5V supply, motor controller from batteries, no change. (motor controller is definitely powered up).
c. disconnected motors and tried moving/controlling servos only, nothing.
d. changed serial cable, as a long shot.
e. multiple resets, reboots, etc., etc.

When powering up the controller, I do get that little “servo shiver”, so it doesn’t seem like the controller is dead.

Looking at logs, I see the confirmation that the motor controller is starting up (as mentioned in a previous post), and I see commands being sent to the pi. Not sure how to monitor to see if the pi is actually outputting those serial commands to the motor controller.

I have a usb power pack coming tomorrow, but would expect the rechargeables to give me enough power at least for a short term test. At this point, it just doesn’t seem like a battery issue.

Bad motor controller? Is the arduino sketch reloaded every time the controller and pi are powered up? I’m assuming not, so possibly something corrupt in the atmel? If so, how would I force that sketch to be reloaded?

Open to suggestions, thanks.