Support for different robot models

[osrf-migration]

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

It would be nice to support both a model based on the real NAO robot and a simplified NAO robot like the one on Simspark.

Real NAO

We currently have a NAO H25 v4 based on these specs. I think it would be nice to keep it as close to the specs as possible, even if something differs from Simspark's robot. This means not altering joint directions or anything else.

Existing agent code will not work with this out-of-the-box, but it will exist as an alternative for the adventurous.

Simspark NAO

If we want existing agent code to work out-of-the-box, we will need to model create an SDF based on the specs given by Simspark.

Directory structure

Maybe organize the models somewhat like this:

Real nao

    /models/nao/model.config
    /models/nao/model.sdf
    /models/nao/materials/textures - pngs go here
    /models/nao/materials/meshes - daes and stls go here

Simspark NAO

We can avoid copying meshes and textures by referencing the nao meshes in the SDF.

    /models/nao_box_model/model.config
    /models/nao_box_model/model.sdf

Choosing model

It would be nice if we could choose the type of robot from the world SDF file like this:

    <plugin name="game_controller" filename="librobocup3dsPlugin.so">
      <ball>soccer_ball</ball>
      <robot_type>nao_box_model</robot_type>
    </plugin>

Internally, we need a way to keep parameters for both robots separate. Perhaps we can have an abstract base class called robocup3ds::Robot and two derived classes: robocup3ds::Nao and robocup3ds::NaoBoxModel.

[osrf-migration]

Original comment by jasonzliang NA (Bitbucket: jasonzliang).

---

According to the simspark server, the agents should be able to choose what kind of robot type they want. Therefore, before they send the init message, they should send a "(scene )" message that tells us which robot to use. I remember that is another rule that no more than 3 robots of the same type can be loaded. We should also enforce this through the server.

[osrf-migration]

Original comment by jasonzliang NA (Bitbucket: jasonzliang).

---

I have created an abstract class called NaoBT that specifies the interface for all derived body type classes. Nima, once you are done creating the simspark body type, you should add your own derived class in Nao.hh (in the jliang_agents branch)

[osrf-migration]

Original comment by nima shafii (Bitbucket: nima_sh).

---

Yes , I will do that now I am testing the simspark model with its new link characteristic. The only part that has been changed in the NAO.hh is the following line

#!c++

const std::string kDefaultModelName = "naoH25V40";

by merging to the jliang_agents branch, I can create a better interface.

[osrf-migration]

Original comment by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

---

• changed state from "new" to "resolved"

Fixed in pull request #31