linuxpcrobot.org

I like everything behind the alum. box :-) Just kidding.

I assume you mean contribute Linux code?

I will be interested to see what obstacle detection you use and how you deal with rotating without the drive wheels being in the center.

As I mentioned in another post I obtained some similar toy motor/gear/wheels. They are *very* noisy compared with windscreen wiper motor/gears.

Perhaps some kind of sound absorbing material could be used. I would be able to enclose the gears and motors within a sound proof box.

Noise I think is a real issue for a domesticated robot. It is one reason why these cheap motor/gears are perhaps not really suitable? I don't know how they would compare in terms of power/noise to some power window motor/gears. The windscreen wiper motor/gears are certainly much less noisy.

- John

Yes and no.

Yes they are, and you can reduce the noise a bit by taking them apart and using some good plastic friendly grease.

There is very little you can do to reduce the noise. IMHO, that really isn't an issue. As long as the system is able to work with different motors, then everything is fine. My may be targeting sub-$500, but people should be able to spend more to make something better.

Since you have hinted here at commercializing the robot for your financial gain, you need to be specific about how contributions will be handled, whether code or otherwise.

-- Gordon

All code on the website will *always* be GPL.

I'm working on a contribution policy, I was thinking that all original source modules retain ownership of original author.

The troubling part is patches to source modules by 3rd party modules. If the standard open source phylosophy is followed, then 3rd party patches dilute the ownership of the whole. This works well in protecting that the source remains free, but many developers may have an issue with it.

I was thinking that patches submitted by 3rd parties get signed over to the original author of the module. Hopefully, this sounds worse than it is. It protects and benefits the original author, and provides incentive to minimize whole scale re-writes of existing modules in preference to original work.

Most people don't like to contribute to a GPL project if the organizer plans (or is thinking of planning) to then just take it and sell it. The GPL license doesn't forbid it, but it's a matter of principle for many people.

-- Gordon

I would never sell someone else's work. If I sell a robot as hardware, or components, I would supply the software for it, and any mods I would make to it would be GPL and available to everyone.

I have been in the software biz for a while and it is hard to make money with it. You make the money with services.

I opened them up and they are full of grease.

The noise drives me crazy. One thing I like about my heavy duty base is that it is not very noisy. It does however leave tracks all over the carpet due to its weight and narrow solid wheels much to the consternation of my wife. Unfortunately it is not very safe. If anything went wrong it could squash a cat or child against a wall or exit via one of the sliding glass doors!

========================

You might add some scaled plans of the dimensions of your robot base to your site as some things are not clear from images.

All I was able to find was two 6 volt motorized toys, wheels 4 inches wide, 8 inches diameter with a clearance of 2 inches. The width of the base has to be 16 inches so the motors don't touch.

The motor shafts are just a dot of metal and thus are not suitable for your mouse PID hack. I expect a wheel encoder will be sufficient to keep the base on the straight and narrow.

The only DOS service I use is to access the hard drive to load/save data. I would really like a system that didn't require the hard drive. I don't know how much bloat Linux has but I guess a hard drive is still cheaper than using a RAM drive. I liked the idea of using a memory stick as a Linux hard drive.

I use direct access to the parallel port and some home brewed hardware to access sensors and control motors.

Your io software I assume requires using the same io card that you use?

Next time I visit the city I will see if I can find some decent books on Linux programming. I don't like buying books over the net or by mail as I like to first see if the book is going to be useful to me.

Hopefully by next Xmas I should be up to speed if my enthusiasm doesn't vaporize in the meantime... so if you are still around...

-- John

Yes, it is an awful grease.

Yikes, do it in the basement.

A wheel encoder may not have enough resolution, but then again, who knows. I'm thinking about swapping wheels on mine, they are too big.

Have it network boot.

Cool, I can show you how to do that easily.

Actually, it is written in an object oriented fasion, and the next redesigned release abstracts the IO board completely, so all you need is to write a couple functions to write out to yours.

Don't by a linux book unless you like buying books that are obsolete by the time they hit the shelves.

Try this first:

I'm not sure if I can stand this much longer :-)

[...]

Big wheels have the advantage in that they tend to roll over obstacles easier. This is why I always try to keep the free running swivel wheel large.

If the drive wheels are in the center the wheels could be as wide as the robot base. With your wheel placement the smaller the wheels the better the stability I guess.

I am hoping the 4" wide wheels on this light weight base I am building now will not leave track marks on the carpet that my heavy duty base was guilty of doing.

Have you ever considered encoders on the swivel wheel, one for rotation and one for direction.

I assume you mean wireless network? When I know how I will certainly make that an option.

If I had your expertise I would use one of those off the shelf wireless video cameras on the robot base and a PC tuner/grabber card in my computer to do the visual processing. You can use your wireless network to communicate the results (or commands) back to the EPIA mini-ATX motherboard robot base. I would have the base as minimalist as possible.

Anyone building (buying) a robot base most likely has a desk top computer so why not use it? The robot base becomes a computer accessory. You can still use a miniITX to do other on board sensor reading and motor control etc.

It would be cool if you are offering to help me get things up and running ??

Ok. Not sure how that works. I have done some OOP but tend to think the old way.

Added it to my favorite book marks and will get to it as soon as I have time.

Of course you can, mlw, I am one of your biggest fans :)

- John

I have. Much easier to get encoders to stick on the caster. I haven't done it yet, and it will take some modifications of code...

I think this will be more of a burden on CPU. Match PWM speed to both wheels so that caster stays in forward direction.

Any comments on this system compared to encoders on drive wheels.

Rich

Yup, that's why I kept the big wheels up front, but they are too big compared to the gear ratio. Reducing the diameter of the wheels from 13 inches to about 10 inches will give me about 25% better gear ratio and not affect its operation all that much, but improve low speed control.

The "center" of a two wheeled robot it always between the two drive wheels, whether you like it or not. :-)

The ones I have are hard plastic and tend not to leave tracks.

No, and if you've looked at what it does when the robot rotates, you'd know why.

It is SO EASY. Web based configuration. It's just like wire.

Seriously, it is not hard AT ALL. The wireless cameras look like webcams.

Interesting way to think about it, but don't forget that 802.11G is not as fast as a wire.

Sure. I can help you with the: "I do it this way on DOS[Windows], how would I do that on Linux?" questions easily.

Example:

class IOBoard { public: virtual BYTE ReadInput(int port)=0; };

class K8000Board : public IOBoard { public: BYTE ReadInput(int port); };

class ParallelPort : public IOBoard { public: BYTE ReadInput(int port); };

In the above example, the class "IOBoard" is what the software deals with. You can pass a function a K8000Board or a ParallelPort object, and all it needs to do is this:

myfunction(IOBoard *io) { BYTE mybyte = io->Readinput(MyPort);

// do something }

The "myfunction" doesn't know or care if it is using a ParallelPort or a K8000Board.

Thanks, I am just building a robot like you.

Not related to diameter, but broader wheels create larger encoder inaccuracies. Borenstein found this out, and documented it well. Slick, hard wheels are also to be avoided, for obvious reasons.

-- Gordon

My robot does not rely on encoders for navigation so accuracy isn't an issue. Broad wheels are good for sandy situations. If the are big enough with nice tread the robot could even cross a river :)

The reason for solid wheels is to avoid the problem I had with the wheels going flat!

-- John

[...]

No, I am not sure why? The only issue I had was when the robot stopped and changed the direction of its motors. The free wheel had to do a 180 rotate. Or it would simply roll in reverse and then rotate at some critical point. On some surfaces it would jam at 90 degrees to the direction of travel. One solution was to do an S wobble whenever the swivel wheel had to make a dramatic change in direction. Although it doesn't appear to be an issue with my heavy duty robot base I imagine that a swivel wheel could get up the shakes like the shopping trolley wheels can.

[...]

Everything is easy once you know how :)

Everything is easy once you know how :)

Once I start C programming with Linux and get some decent demo code I guess I shall be able to figure it all out.

As long as it is fast enough. If you are getting 30 frames a second the only bottle neck is the speed of extracting the relevant data from the image.

Ok. When you start grabbing images from that webcam on your robot I would be interested in the source code and a step by step explanation of how it works. By "grabbing an image" I mean into a byte array.

At the moment I use a *slow* VC++ template for my LogiTech cams [Windows] and a direct parallel port access to my old b/w QuickCams [DOS].

-- John

You're right, but MLW is using encoders, and his wheels are hard, slick, and broad. I can understand his desire to change them out. This is one of the problems with those kid rider toys. The wheels are often a smooth styrene or ABS plastic, and not a rubber that has some grip.

Airless tires (for wheelchairs and such) are nice for this, if you can afford them.

-- Gordon

I am using the same toy motor/gearbox/wheels except they have a strip of sticky rubber with tyre tread marks like this |||||

Maybe mlw could find a rubber belt that might fit around the slippery plastic wheels?

-- John

Yes, that might work. I've gotten some rubber anti-slip tape at the home improvement store that has a waterproof adhesive. It's for lining spas, tubs, and such. Goey sticky. It's worked well in adding "gription" to some slippery tank tread segments I regularly work with.

-- Gordon

Exactly

Yup.

True

Just do it and you'll wonder why you put it off.

What size frame? What bit depth?

384*240*30=2,764,800 bytes a second. 2.7M byte a second is pretty fast. You'll want to compress it prior to sending it.

TRIVIALLY EASY!!! From the qc-usb project:

len = read(device_fd, buffer, vidcap.maxwidth * vidcap.maxheight * 3);

OK, I cheated a bit, there is some setup:

void get_camera_info(void) { ioctl(device_fd, VIDIOCGCAP, &vidcap); ioctl(device_fd, VIDIOCGWIN, &vidwin); ioctl(device_fd, VIDIOCGPICT, &vidpic);

vidwin.clips = vidclips; vidwin.clipcount = 0; }

In UNIX, everything is a file.