consultation about the implemention of hardware_interface::RobotHW

[AriYu]

I'm writing our original hardware_interface inheriting hardware_interface::RobotHW to adjust ros_control. fr01(forest robot) has 6 wheel and 4 steer joints. And wheel is velocity control, steer is position control. But it look like that the hardware_interface class should be definite just only one. Then, the main function is like bellow snippet.

main()
{
  MyRobot robot;
  controller_manager::ControllerManager cm(&robot);

  while (true)
  {
     robot.read();
     cm.update(robot.get_time(), robot.get_period());
     robot.write();
     sleep();
  }
}

If we have to implement all in read() for all motors, the problem is read() require long time. Because, serial servo (B3M Kondo servo) is often mistake (invalid checksum) and we have to re-read from servo motor. In my experience, the maximum re-reading times is 4. Every reading require 5[ms]. As a result, above code snippet's loop rate maybe very slow. How do I should do this ?

reference : https://github.com/ros-controls/ros_control/wiki/hardware_interface

[MoriKen254]

@AriYu How do you handle the problem currently on the real robot? I believe this is the common issue on both the current case and RobotHW case.

If read() method takes long time because of networking failure, it just causes that a constant command is sent to each actuators during read() method procedure.

In other words, a new command calculated from the newest value cannot be gained until read() returns. Does this also happen in the current driver principle?

In the current driver, a command value from the newest joint position is computed in a subscriber when the topic /wheel_state is updated. Until then, a constant joint command should be sent to a motor driver.

This seems same with the procedure cm.update() is computed when the read() is finished. Until then, a constant joint command should be sent to a motor driver.

If I'm getting a mistake, please point it out. Thanks.

[MoriKen254]

I'll be in the lab on 2/17(Wed) in the morning. If you are available, please let me have a discussion on this.

[AriYu]

@mum254 Sorry, I have class tomorrow morning from 8:50 until 10:20. But the other time, we can discuss. Thank you.

In the current structure of fr01_driver, steer control node and wheel control node is independent. So, wheel control node don't need to wait for steer control node updating. But, in ros_control, If we have to implement in read()(reading from wheel encoder and steer servo), wheel controller have to wait some times.

However , I came up with an idea just now. If we can publish some topic in write(), we use current node for wheel motor control. And read() taking long time wont be big problem.

[AriYu]

@mum254 This is real robot implementation problem. Sorry, I forget to say that.

[MoriKen254]

@AriYu ok, understood what you mean. talk about it later =-)

[AriYu]

Now, ros_control for real hardware is implemented in use_ros_control branch. And, almost of them are finished. But, If you find some problem, please pull request. The new rocker-bogie controller have developed, I will do test.

[MoriKen254]

@AriYu great! super quick job! let me check the code & compatibility with gazebo=-)

[MoriKen254]

@AriYu Cool, I believe your code will be compatible with ros_controller. It's my turn to commit.

Now, let me check my understanding on your driver. Is the software configuration like the following fig? (some details are abbreviated.) Please tell me a mistake if it exists.

By the way, when do you want the common ros_controller by? I might be short of developing time until next week. However, I wanna do my best to finish it by the deadline if you have.

[AriYu]

@MoriKen254 Thanks.

I think that your understanding is right and the figure is awesome. Thank you your great works !!! Making the figure should be my work, sorry.

Please don't worry about deadline, because the interim presentation is April and the robot have moved already. Of cause, it is important to compatible with ros_control and I want to move the robot using ros_control. But it is not urgent.

Incidentally, I would like to move codes about ros_control to fr01_control directory from fr01_driver directory. How about this idea ? And I want to remain fr01_driver directory, because fr01_driver is able to control real robot. However in the future, if we confirm to control the robot by using ros_control, I will remove it.

[MoriKen254]

@AriYu

don't worry about deadline

Ok, thanks.

I would like to move codes about ros_control to fr01_control directory from fr01_driver directory.

sure, I got it. I'll modify the configuration of fr01_control.

I want to remain fr01_driver directory

Ok, let's merge them after checking the compatibility. Thanks for your comment =-)

[AriYu]

@MoriKen254 I have a question about fr01_control directory. Where will I put code about ros_control for real hardware ? For example fr01_control/src/real_hardware/some_codes_for_real_hardware.cpp or fr01_control/src/some_codes_real_hardware.cpp If you have any other idea, please tell me it.

[MoriKen254]

@AriYu

I prefer the former one from your options.

Or how about the following one? The main idea is to split hw space from controller one. hw space includes real and sim hw codes, while control space includes ros_controller which is compatible with both real and sim.

├ fr01_control/ (ros_controller. both real and sim can use.) │　├ rocker_bogie_controller/ │　│　└ src │　│　　　└ rocker_bogie_controller.cpp │　└ some_another_custom_controller/ │　　　└ src │　　　　　└ some_another_custom_controller.cpp (not needed for now) │ └ fr01_hw/ 　　├ real 　　│　└ src/ 　　│　　　├ hw_real_node.cpp 　　│　　　├ hw_real.cpp 　　│　　　└ some_codes_for_hw_real.cpp 　　└ sim 　　　　└ src/ 　　　　　　└ codes_for_hw_sim_plugin.cpp (not needed for now)

Umm, what do you think about it? You wanna move driver codes to controller space don't you? I know your idea because some_codes_for_hw_real in fr01_driver also include controller.

In my opinion, dividing RobotHW and ros_controller seems reasonable.

If you have any idea about the issue, please let me know.

[AriYu]

@MoriKen254 Thank you for your suggestion. I think your suggestion is very good. I will try to organize directory structure following your idea in use_ros_control branch.