What are the sprocket disks on the robot drive wheels for

[pageauc]

Just a general question.

The Dawn Robot has a blue sprocket like disk on each motor (opposite side of tires). I installed these but cannot determine precisely what they are used for. Is there an encoder that can be installed to use these notched sprocket disks? I am looking at wheel encoders to be able to calculate exact distance/speed/acceleration Etc. for each wheel. This would allow robot to travel in a straight line or a specified radius turn and keep track of distance traveled (average between both wheels). I would like to use a sliding contact or light sensor encoder. Magnetic encoder might possibly interfere with some robot chips or electronics (just guessing).
If you know what these are for and if there is an encoder available, please post reply
Thanks
Claude..

[pageauc]

http://www.robotshop.com/en/dfrobot-wheel-encoders-dfrobot-3pa-4wd-rovers-2pk.html
also
http://www.robotshop.com/en/encoder-for-pololu-wheel-42-19-mm.html
Found these at Dagu and the sprocket on the first one looks very much like the one on the Dawn Robot. I think I will look at ordering one of these to see what it will do. I anyone knows about this encoder or a better choice for the Dawn Robot please post a reply.
Thanks Claude

[Alan]

Hi Claude,

Sorry for the delayed reply. We've been doing a fair bit of work behind the scenes to get the Raspberry Pi Camera robot working with encoders, so I wanted to wait until I had some time available to give a complete reply.

There's two aspects of getting encoders to work, the hardware and the software. With regards to the sprocket disks, you're right, they are indeed for encoders. Sparkfun use the same chassis for their redbot, and I believe that they got Dagu to add more teeth to the wheels for use with this encoder board. At first glance, this board looks really neat with IR sensors looking down at the encoder disks, but in reality they don't work very well. Firstly, the hardware seems to be a bit tempermental and misses ticks, and secondly they're only single output encoders (as are the encoders in the first link you posted). Single output encoders are probably ok if you just want to control the speed of the motors to drive in a straight line, but I believe that in order to make accurate turns (say 90 degrees etc) then it's much easier to do this with quadrature encoders (the Pololu ones).

Probably the best quadrature encoders I've used so far with the camera robot, have been the wheel watcher encoders by Nubotics (although two of the holes need to be redrilled slightly to fit on the Dagu motors). These are a bit pricey though, and can be a bit tricky to get working, and so we're planning to produce some lower cost quadrature encoders that use hall effect sensors and a magnetic disk attached to the back of the motors. As these are before the gearbox, they'll benefit from the 48:1 gear ratio and be able to give over 700 counts per revolution. It's probably going to take us at least another month to get them out unfotunately and combined with the postage cost to Canada, you might be better going with the Nubotics encoder if you'd like something quickly.

Once the encoders are attached to the robot, the next thing to consider is the software. The encoders could be connected to the Pi, but writing responsive interrupt code in Python to catch the encoder ticks looks a bit tricky to me so I've decided to connect them to the Mini Driver for now. Using the mini driver solved a number of problems when constructing the robot, but connecting sensors to the mini driver can be a bit tricky, as the mini driver firmware has to be modified to read the sensors, and send the values back to the Raspberry Pi, where Python code needs to be written to receive the sensor values. To ease this process for sensors in general, I've been working on an updated version of the software for the camera robot that should make attaching sensors to the mini driver much more straight forward. This code is currently in the experimental branch of raspberry_pi_camera_bot, and if you're interested you can get the code by logging onto the Pi and running

Code: Select all

cd /home/pi/raspberry_pi_camera_bot
git pull
git checkout experimental    # type 'git checkout master' to return to the old code

to see the sensor reading in action, first stop the robot_web_server

Code: Select all

sudo service robot_web_server stop

then run the sensor test script

Code: Select all

sudo ./robot_sensor_test.py

The experimental mini driver firmware sends sensor readings back to the Pi at a rate of 100Hz. Pins can be configured as either digital, or analog inputs, and one of the digital pins can be configured to read from an ultrasonic sensor (alhough only at a rate of 2Hz at the moment).

Things are going fairly slowly here unfortunately. But the current plan is to release an upgrade to the software along with a blog post showing people how they can add sensors to their robot, and then to follow that up in about a months time with our encoders, and another software update that uses the encoders to improve the control of the robot. It looks at the moment, as if there is not enough space in the memory of the mini driver to implement a motor control loop on the mini driver itself, but we've conducted some tests that make me confident we can get good results by implementing the control loop in Python code on the Pi.

Anyway, apologies for the long and rather rambling nature of this post, hopefully it gives you some useful information to go on when adding encoders to your robot.

Regards

Alan

[pageauc]

Thanks Alan

I am patient and willing to wait to see what your encoder can do. It is too bad that small robot motors are so dumb and cannot provide information about themselves as part of an integrated design, but I guess it is a cost thing. Hanging a sprocket disk or similar off the end of a shaft or wheel seems so crude.

Thanks for your explanation. I believe personal robotics still has a long way to go. Standards, hardware abstraction, standardized connectors (power and sensors), more integration, friendly operating systems, autonomous capability by design Etc. Also the cost can be high for anything with advanced capability. Reminds me of early personal computer days with Apple ][, Commodore, TRS80, Acorn, Etc.
Claude ...

[Alan]

Yeah, it is a cost thing with those motors as they are one of the cheapest ways of building a robot. Looking back, I could have avoided the need for using encoders by building the robot with stepper motors, but then the control electronics would have been more expensive. Lots of different ways to solve things in robotics, with lots of different trade-offs.

I agree that lack of standardisation is a big problem in robotics, although one problem is the huge variety of possible robot types you could have, i.e. humanoid robots, wheeled robots, flying robots, robots inspired by animals, swarm robot's etc which means that we might end up with a different set of standards for each different type of robot. Standardisation of interfaces to higher level functionality like navigation, or motion planing libraries is probably doable however, and I don't know if you've seen it, but the ROS platform has been gaining traction in research robotics to help integrate everything.

ROS is a bit too heavy to run well on the Raspberry Pi (although some people have tried) so the plan is at some point to use our py_websockets_bot to add ROS support for our robot to control it from a more powerful PC.

Regards

Alan

[pageauc]

Yes I looked at ROS and some things look interesting but still a little too much for less techie persons. I would like to see Personal Robotics advance to where they are more autonomous and less like toys but not try to be android like. More like a pet with some behaviours learned and others built in.
1. Self discover and map out its local physical area so it knows navigable areas but can still do adhoc object avoidance for moved or temporary items in its path.
2. Find way points so it can do visual course corrections. Eg use a wall corner or triangulate with known objects to correct its position on the local map. This could be done visually and/or by sonar.
3. Be somewhat self sufficient in that it can recharge itself via solar and/or wireless recharge locations.
4. Be able to play basic interactive games like hide and seek, fetch, I spy, tag, hop scotch and simple ball type games. Similar to games that young children would learn but modified to suit the robots ability.
5. Perform some basic remote tele-presence activities and environmental monitoring Eg visual, temperature, humidity, sound, light, smell. Check on pets, equipment or condition of home for example.
6. Have pet like behaviours like greeting, follow/heel, learn tricks, follow/learn actions like hand motions to stop, move left, right, back, turn Etc. like learning to do a dance.
7. Be able to interact with a few home electronic devices like a simple robotic floor cleaner.
I believe all of these can be done today by a small pet sized robot with no robotic arms. A simple electro magnetic object retrieval point would be sufficient to play retrieval type games. I think a self balancing robot would be a nice platform.

It might take someone with a vision and money (like wozniak and Jobs) to commercialize personal robotics for the masses but it will only happen if they advance to be more that just toys but not try to be android like or do house work chores like cleaning floors/dusting/cutting grass etc. More like an interactive pet.

[pageauc]

Found this excellent article on encoders if anyone is interested http://www.anaheimautomation.com/manuals/forms/encoder-guide.php#sthash.kPt7sDOg.dpbs

Also doing some more searching I found motors with built in encoders http://www.pololu.com/product/2284

For my project I might consider these motors but will wait and work with what I have already until I gain more knowledge and experience. There are a lot of things to consider when trying to build a robot that is more than a remote control toy.
Thanks for your help. I am quite pleased with the Dawn Robot so far even with it's limitations but it has the potential to go farther with the right programming.
This is just a hobby for me and I am having fun.

[Alan]

Cheers for the link, it was very timely as I was working on the blog post describing how to add sensors to the robot. Therefore I've added it to the post in the section on encoders.

Also, it's a very delayed reply, but I agree that an autonmous robotic pet is a good stepping stone for getting robotic technology to the point where it's useful in the home. Getting the price point right though (i.e. low enough) whilst making the robot capable enough though. I think that Sony had a good crack at the market with the Aibo a while ago, and it could do quite a few of the things you describe. Ultimately though, it looks like it wasn't comercially viable for Sony to continue.