Andry wrote:
Hallo Doug,
I agree with you that the idea will take a lot of effort and it might
not be consistent with the basic idea of Pyro. I can see that
programming in lower level might not give much advantage to students,
which Pyro has successfully prevented. But somehow, I can see the need
to run the program on the robot itself.
I was also considering to remotely control the robot through Bluetooth
or Serial Cable, but I am aware of the delay problem with this approach.
I don't know how bad the effect of this delay to the overall system
performance. I wonder whether anyone has any reference stating about
this issue (I have searched for some time but couldn't find any relevant
paper).
I did a small test with a Khepera yesterday to see the relationship
between message length and the transfer time through serial cable with
38400 bps. Well, for very long messages, such as the one from the linear
camera, it will take in average more than 200 ms. It's quite a big
delay, in my opinion, especially for application where fast response is
compulsory.
Andry,
We have been using serial over Bluetooth for a few different kinds of
robots lately, and run at 38,400 bps too. It doesn't surprise me that
one would get a lag of 100 or 200 ms (10 or 5 updates a second). We run
the Aibo over Wifi in this manner, and get about the same results, even
with full vision processing with our Python/C++ layer!
So I need opinion from everyone here whether the robot remote control is
good enough. I am thinking that robot remote control should come after
simulation and before programming real robots. And for Khepera, I only
see one software that can do it seamlessly, Webots. But it's not free
for getting this feature. And Pyro looks to be a good candidate, if we
can manage to get the 'translator' working, as you mentioned.
We have made the decision that we are willing to run at 5 or 10 updates
a second in exchange for the full programming and visualization tools
provided by Python & Pyro, and the other tools that run on a full
operating system (including fast matrix multiplication, C-based
self-organizing maps, C++ vision, graphs and plotting, debugging, etc).
But not everyone is willing to make that same sacrifice. I think that if
you want the speed, then there really is no substitute for writing in
the native tools for that particular robot. For example, using PBASIC
for the Stamp-based robots. This Khepera page discusses the issue some:
http://diwww.epfl.ch/lami/robots/K-family/K-family.html#environment
We could work on some low-level byte-code interpreter that could run on
a variety of robots. However, I think by the time we got that ready,
Moore's law would have PCs the size of the Khepera, and we could just
run Pyro on that.
However, this is an important issue today, and one that I suspect will
be discussed at length at the upcoming 2007 AAAI Spring Symposium
"Robots and Robot Venues: Resources for AI Education":
http://www.cs.hmc.edu/roboteducation/
Such data and ideas on how to solve this problem would be greatly
appreciated. Maybe you can make it?
-Doug
I am insisted in working with Khepera, especially Khepera II, because
the working group where I am working to has developed several extension
modules for it. Moreover, I think this robot will last still for more
years, and for education it will last longer.
wbr,
Andry
Douglas S. Blank wrote:
I think that this sounds like a project that may be beyond what you
can easily do. And it would be very specific, so that it would only
work on one type of robot.
It would be more of a translator, than compiler, probably. Say,
reading in Python code, and outputing a subset of C code that could
then be compiled and downloaded to the robot.
And, when you were done, you wouldn't be able to take advantage of any
of Python's libraries.
I think I'd pick a different way to solve your problem.
-Doug
_______________________________________________
Pyro-users mailing list
[email protected]
http://emergent.brynmawr.edu/mailman/listinfo/pyro-users
