Except you don't really know that because, as best I can gather,
you have not actually implemented and tested your code in a
real, physical robot.
That's all I was trying to determine.
best luck with your project,
Have you been to the site? I have implemented and tested the code in a "real
physical robot." The PID algorithm described is part of a larger control
system. You can even download the code.
Can you describe the behavior of your robot, other than to
say that it can drive in a straight line for hours while keeping chalk
lines on the wheels in sync?
Data is more helpful than unsupported assertion like "the response
of my system is similar."
In particular, do you have data on the system's response to:
1) Abrupt changes of control input, and
2) Abrupt changes of the environment (such as going from a low
friction to a high friction surface, or climbing over an obstacle.)
I don't understand why is this so difficult for you to answer.
Have you run the robot enough to collect such data?
Do you have plans to do so? Will you publish the results?
A video of the robot/algorithm in action would go a long way toward
answering these questions.
I can host that video on my website if that is a problem.
The two wheels will rotate at the same speed without loss of position. That
checks that the system isn't losing data.
"unsupported assertion?" Hmmm, what the hell are you trying to say? I wasn't
liking your tone before, now it sounds like an accusation.
That is a higher level robotic control and path planning issue.
Technically it does what it should but the wheels are too smooth and slip.
Because your tone is accusing. I have published the article and the source
code, if you don't believe it works, test it for yourself if you don't
Not so much "collect data" as hook a couple scopes on to the various signals
in the system and watch the behavior while manually altering load and
control settings. Then making simple programs to execute a series of moves
and verify that the data points were met when executed. Odometry is a
problem because of smooth wheels and hardwood floors.
I think the results are more or less meaningless. This is a hobby not a
product. If I were doing this code for a client, then I would probably do
something like that, but for now, this is just for fun.
Maybe if I ever get around to it, this is a hobby, that that just seems like
I have a good site infrastructure through my main business already.
Just wanted to let dpa know that there *are* people on the net (I, for one)
very much appreciate his effort in publishing this essay. Please let the
questions of mlw not keep you from enjoying your hobby and continuing
to publish and discuss any results you achieved.
And mlw: nobody is stopping you from doing some work yourself to find the
some of to the good questions that you raised. dpa has put all the
to get started in his essay, and even published the source code. If you
answers, I'm sure there will be helpful people in this ng that will be happy
& criticize them ;-)
It is funny, I am a computer consultant for a living. I design software and
systems for people for pretty good money.
What I find annoying about the whole dpa dialog is that he is asking for a
precision for which the system was not designed, and because it does not
have it, he thinks it is without merit and is down right rude about it.
Geez the wheels axle load varies as the wheel turns, how can you benchmark
something like that? In the field of mobile robotics, and hobbyist robotics
at that, the idea of precision is more or less a joke.
Slippery wheels, irregular floors, and obstacles make PID such a small part
of the overall motion system. PID is a lot like PLL in the radio world. PLL
is a very good mechanism to tune a receiver but it is not the system as a
whole. PID is a closed loop control system, nothing more. My essay covers
the theory of how that works for someone who may not be interested in
calculus. When you start talking about odometry and other issues, you get
beyond the subject and a much much more lengthy and complex discussion.
If I were doing this to make money beyond blogbits, it would have been a
different project with different priorities. Specifically, I would have
used precision parts and encoders. I probably still would have had a goal
of using a "non-realtime" system.
As it is, the "$500 robot" is a project in the works during my spare time,
and almost anyone can download the code and build something like it from
the crap they have laying around.
I still like it, and I still think the essay is a good start for someone
curious. dpa, not withstanding, of course.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.