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.

In which case GPL isn't the best fit license.  I believe there are
licenses which do exactly what you describe.

Without wanting to start a flame war here. I am a huge fan of the
protections of the GPL, however, I think that for it to be an effective
license for an entity that wishes to share, but not lose ownership, care
has to be taken to prevent the dilution of ownership.

There is a HUGE balancing act that has to take place. On my site, I want all
contributions to remain the exclusive property of the original authors.
This is important as many of the potential authors may use the code placed
on the site for their professional work. Ownership dilution threatens the
usability of the code.

What if someone GPL's code for the robot project, but someone donates a
feature or functionality that the original author may have been planning or
implementing? If the 3rd party addition is accepted, the code is tainted
and the original author is no longer allowed to use the code as he or she
sees fit without maintaining separate versions. Alternatively, if the
feature is not accepted, and the riginal author brings their version of the
feature online, I can see fights and law suits over ownership.

It is best that up front to state that patches to source modules become the
property of the original author. This is not too harsh for small bug fixes
and, hopefully, reduces wholesale reworking of modules by 3rd party
contributors.

Secondly, many developers really really dislike radical changes on their
code. I've been on a couple open source projects where someone's code gets
virtually re-written while the original author was focusing on something
else. Once the patch is applied, the original author no longer even
recognizes his code, and has virtually lost any use of it. He is back to
maintaining his own copy and will probably abandon the project. A radical
rewrite should take place as a new source module.

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:
http://www.tldp.org/

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.

[...]


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

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.

[...]



No, I don't think there is any compression involved?

I am talking about those wireless video cameras that
come with a wireless receiver that plugs into a TV.
I don't know what the resolution is but I could find
out. The images looked as good as a web cam.

http://www.doorchime.com/video-surveillance.htm

People like to put them on radio controlled cars
or use them as "spy" cameras. The idea is to plug
them into a pc tuner/grabber card and be able to
access the hardware from your own program.


[...]



Actually I would need a complete example program
not just a fragment.

It looks a bit more complicated when I googled for
such programs...

http://cvs.sourceforge.net/viewcvs.py/freevo/freevo/matrox_g400/Attic/v4l1_to_mga.c?rev=1.6

Like I say I have a long learning curve ahead and I
have to start with a Linux C version of "hello world"...

-- John

The wireless camera's that have a transmitter and reciever and plug into an
RCA jack will require a video capture card.

The wireless webcams typically implement a web or streaming video server,
and don't need an analog reciever.

I'd opt for the wireless webcam.


Dude, go here:
http://sourceforge.net/projects/qce-ga/

The above link is the Linux quickCam driver project, download qc-usb.
Download it to a file, and then open it with WinZIP. Look at the file,
"testquickcam.c"





http://cvs.sourceforge.net/viewcvs.py/freevo/freevo/matrox_g400/Attic/v4l1_to_mga.c?rev=1.6

Oh my god, you are talking about converting a video device to mpeg, 1000x
more complicated.

Thanks dude, that's the kind of information I
think I will need.

-- John