Descriptors

[jbmouret]

It is nice to have a concept of a user-defined 'state'. As I understand it for now, we have

  simu.add_descriptor(std::make_shared<StateDesc>(simu));

and the descriptor is a functor like this:

struct StateDesc : public robot_dart::descriptor::BaseDescriptor {
    StateDesc(robot_dart::RobotDARTSimu& simu, size_t desc_dump = 1) : robot_dart::descriptor::BaseDescriptor(simu, desc_dump) {}

    void operator()()
    {
        if (_simu.robots().size() > 0) {
            states.push_back(_simu.robots()[0]->skeleton()->getPositions());
        }
    }

    std::vector<Eigen::VectorXd> states;
};

Questions:

• For control, I think this should be per-robot and not for the simulator.
• This state descriptors is for logging? (since it stores all the states since the beginning). If so, we could use the same principle but I think we should separate the API
• I think we should have a lighter API.

We can use c++11 lambda's (I know this should already be possible right now):

state_fun = [&](){ return make_state({my_robot->get_positions(), my_robot->get_velocities()};};

We could hide this behind a macro to make it more "user-friendly":

state_fun = ROBOT_DART_STATE_FUN(my_robot, {my_robot->get_positions(), my_robot->get_velocities()});

What do you think? We could do the same for logging. ROBOT_DART_LOG().

[costashatz]

As I understand it for now, we have

This is just an example of how to use the descriptors. Not necessarily the best way of logging states.

• For control, I think this should be per-robot and not for the simulator.

I agree.

• This state descriptors is for logging?

The state descriptor as I said above, it is just an example of how to use the descriptor API. I was thinking of removing the descriptors completely and replace them by lambda functions (which is exactly what you propose). That way the user can choose what to include in the functor or not, being API-less. The issue with lambdas is that they do not have member functions, and thus the user cannot easily decide how often should the descriptor should be called. They would have to put it in code every-time. In the current API, it's hidden and they only care about the main code of their descriptor.

What do you think? We could do the same for logging. ROBOT_DART_LOG().

Overall I am positive with this proposition. But I believe that we need to solve this together with the control API and find how to handle all the small things (e.g., frequency to be called, access to the simulator data, etc.). Both APIs will be very similar and we should find a common solution (easier to handle also).