As a ros2_control user I would like to define transmissions for my robots about ros2_control HOT 9 CLOSED

hi, what's the status of this port? Karsten's PR has a number of missing things like parsing in actuators, and it's not a 1:1 port with minimal changes from ros1.

from ros2_control.

@ddengster I should have marked this PR as draft. I am agreeing with @bmagyar review and most likely that transmission interface should have a new design in the first place. I just need something going for get started with the gazebo_ros_control part of it.

I think this issue is the right place to voice some concerns or design proposals for a ROS2 implementation.

from ros2_control.

No problem, @Karsten1987. I also happen to be working on a minimal gazebo_ros_control plugin for my own priorities.

With regards to the PR, I was expecting something closer to a 1-to-1 for the parser - doing a minimal working port first from ros_control, then applying breaking design changes later.

Also I'm not sure if we need a TransmissionParser object instantiation? I just need a function call to populate my TransmissionInfo data structures. But then again I'm not of the mindset that we need to 'objectify' things to get our code to do what it needs to do.

from ros2_control.

Over the years there were quite a few attempts at improving ros_control to improve extendability but the one that kept failing was joint and actuator interfaces. They are locked into place by the intertwined structure of transmission_interface and it solidified bad patterns in the entire framework. If you have specific requirements from transmissions please do say so :)

Also, I agree with removing classes when not needed. If a class contains no state but only a bunch of (hopefully static) functions, we have a better name for that: namespace.

from ros2_control.

I'm assuming you're referring to JointInfo and ActuatorInfo? It's members are mostly strings, which are imo the most extendable types you can have without bringing in a whole bunch of other abstractions to resolve parsed xml strings into another type. (And I'm not really a guy who likes bringing in more abstractions without a few existing use cases)

Perhaps I'll pick an example to narrow it down?

default_robot_hw_sim.cpp

There's plenty of transmissions[j].joints_[0].name_, is this the bad thing you're referring to?

Anyway, let me know and mabye we can trash it out.

from ros2_control.

I saw that @bmagyar has merged transmission_interface in ros2_control/master. Is there any plan for the following data structures.

struct JointInfo
{
  std::string name_;
  std::vector<std::string> hardware_interfaces_;
  std::string role_;
  std::string xml_element_;
};

/**
 * \brief Contains semantic info about a given actuator loaded from XML (URDF)
 */
struct ActuatorInfo
{
  std::string name_;
  std::vector<std::string> hardware_interfaces_;
  std::string xml_element_;
};

from ros2_control.

Where do you need those informations?

from ros2_control.

We are missing transmission-loader and an xml format to close this.

from ros2_control.

Done in the recent ros2_control release, 2.6

from ros2_control.