Re: A robot simulator

On Fri, 27 Jun 2003, Leopold Palomo Avellaneda wrote:

[... qilex robot simulator <http://qilex.berlios.de> ...]
> > - what is the basic design of the simulator? 
> 
> in the document of the master thesis (pag 107) there's a diagram of the 
> architecture of the program.  I have a main class that do the modelization of 
> the robot (kinematic direct and inverse) and mantain the state of the robot. 

This class corresponds with what part of that diagram?

> The state of the robot is update to the representation.
This is the QilexView, I guess?

[...]
> >   can you interact in two directions with the simulator (i.e., not just
> >   visualize things, but also indicate things on the GUI and have them
> >   sent to the robot); ...
> 
> Not yet. I don't have colision detection. 

I am not in the first place thinking about collision detection, but
about interaction with the user inputs. For example, indicating a
desired goal position for the robot, and than instructing the robot to
move there. This desired goal position should be linkable to geometric
primitive in the visualized scene, such as vertices or planes on
objects.

> > - from the manual, I seem to get the impression that Qilex allows to
> >   interactively build new kinematic chains?
> 
> Well, you need the D-H parameters (classical, not Craig) , some more 
> information (rank of joints of the robot, speed, etc) and a Inventor file of 
> the robot. After, you need to do some simple modification, ( in the Appendix 
> are explained) \footnote{I will translate it, ok} to the inventor file and 
> that's all.
Ok, that is "file based" interaction :-) I was thinking about the
opposite way: building a chaing graphically, and then saving to a
file.

(BTW, don't use DH parameters, this is old technology with too many
drawbacks...)

[...]
> if you put some model with more than 24 joints, but this can be solved with 2 
> lines of code, nothing more. I'm not very glad of the kinematic inverse. We 
> are working to have any better algorithm. I have looked a bit your libraries, 
> and your method, but I need more information.

Don't rely on our library too much for the time being: it needs an
update. I am very interested in starting a concrete discussion on this
topic :-)

[...]
> > - how does one attach an external program, such as a robot controller
> >   output, to the simulator? 
> 
> By now it's not possible. However, I think that I will modify the
> arquitecture to let this kind of things. I'm working on it.
Probably other people in this forum are interested in discussing this
topic and its design in more detail...

> > How does one do the opposite thing? (I.e.,
> >  using the simulator to indicate desired positions.)
> 
> I don't understand very much this question. You can indicate to the robot the 
> desired position with the sliders joint by joint, or with the interpret, with 
> a classical move trans(x,y,z,yaw,pitch,roll)
Ok, but I was thinking about giving (on the screen) a geometric
primitive as goal position.

> > - what is the roadmap of this project? I mean, where do you want it to
> >   be in one year's time?
[...]
> - Construct a better interpret. There's a question that we are
> thinking about languages of programing robots.
This is an very important question, that should be one of the core
topics to discuss in the orocos community :-)

Thanks for your quick feedback!

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480