Re: A robot simulator

A Divendres 27 Juny 2003 15:06, Herman Bruyninckx va escriure:
>
> This class corresponds with what part of that diagram?
Rchain is the main class of the modelization

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

No. The tipical organization of a Graphical application oriented to the 
documents: 
a class for the application --> App
a class for the document --> Doc
a class for the view of the document --> View

The class App has the menus, etc. The structure.
The class Doc is the document, in Qilex is the cell
The class View, is how the document is showed to the user, in Qilex it 
represent a viewer of the scene. An Inventor viewer.


> 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.

I know some soft that can do that. Is one of the question that in the future 
will be.
> >
> > 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.

I thouhgt to divide the application in two. One a designer (the program that 
you said) and another the simulator, but this is just an idea.


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

Ok, it's true. Do you recomend some nomeclature? 
>
> [...]
>
> > 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 :-)

Inverse kinetmatic, no? a great question.

> > > - 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...

Ok, new thread on monday.

>
> > - 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 :-)

Another thread? 

>
> Thanks for your quick feedback!

Well, I was very impatient for your comments. I have to addmit that if someone 
looks your work and ask interesting things of it, is a nice thing.

Regards,

Leo