nishida-lab/forest_robot_project

forest_robot_project's Issues

About tf tree

I checked tf tree for adding /odom frame and found strange transforms like follow image.

I added hokuyo3d_link before checking tf tree.
I think base_footprint should be transformed from base_link or nearly root of tree.
Please tell me why it is, thank you.

consultation about the implemention of hardware_interface::RobotHW

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

What the reason to specify hardware interface in transmission tag of Rocker and Bogie joints.

As mentioned in the title.
In my understanding, hardware interface is needed when the joint is actively controlled but hardware interface is specified for the Rocker and Bogie joints although they are passive. Thus I don't believe hardware interface is required for the joints.

How do you think about it?

If I make some mistakes, please point them out. Thanks.

wheel hardware interface looks not working well

I tried rocker_bogie_controller on real robot.
I add new fr01_bringup pkg for start up all necessary nodes, plugins and so on.
Then, I commanded following

roslaunch fr01_bringup fr01_bringup.launch 

I succeeded to control steering joints. But wheel joints had not moved.
I sought ERROR or WARN on screen messages and found following message

........
[ INFO] [1458821773.685239176]: id: 3
[ INFO] [1458821773.686747237]: Registered joint 'wheel_left_front_joint ' in the VelocityJointInterface
[ INFO] [1458821773.686843818]: Registered joint 'wheel_left_middle_joint ' in the VelocityJointInterface
[ INFO] [1458821773.686888245]: Registered joint 'wheel_left_back_joint ' in the VelocityJointInterface
[ INFO] [1458821773.686929655]: Registered joint 'wheel_right_front_joint ' in the VelocityJointInterface
[ INFO] [1458821773.686971095]: Registered joint 'wheel_right_middle_joint ' in the VelocityJointInterface
[ INFO] [1458821773.687012482]: Registered joint 'wheel_right_back_joint ' in the VelocityJointInterface
[ INFO] [1458821773.687055222]: Registered joint 'steer_left_front_joint ' in the PositionJointInterface
[ INFO] [1458821773.687094893]: Registered joint 'steer_left_back_joint ' in the PositionJointInterface
[ INFO] [1458821773.687133019]: Registered joint 'steer_right_front_joint ' in the PositionJointInterface
[ INFO] [1458821773.687175075]: Registered joint 'steer_right_back_joint ' in the PositionJointInterface
[ WARN] [1458821773.687236808]: Replacing previously registered interface 'hardware_interface::JointStateInterface'.
[ INFO] [1458821773.689524046]: joint_name: joint_2
[ INFO] [1458821773.694015663]: min_angle: -200
...........

So, they say Replacing previously registered interface 'hardware_interface::JointStateInterface'..
I don't know why this is caused, but I suspect to need independent controller manager for every joint type. Now, velocity joint interface and position joint interface are into one Robot::HW.
Do you have any other ideas about cause of this problem ?

Wheels somehow rotates undesirably

For now, I checked some behaviors on current drive controller as follows but haven't found any essential cause yet.

• on rocker_bogie
  • wheel joints somehow rotates even if set 0 command on every update timing.
  • consequently odom is updated undesirably.
• on diff_drive
  • Switching rocker_bogie_controller to diff_drive_controller doesn't solve the issue above.
  • this means the problem essentially occurs from diff_drive_controller or model.
  • in jackal simulator(also using diff_drive), the same problem also happens but the effect is not so large.

If you have found something, please let me know.

Thanks.

About this repository

Nishida-Lab and Ivan-Lab members will share this repository.
So, We set some rules.

1. If you commit and push your codes, please write the details about the modification in English.
2. If you have some question, ask at this issue page. Of course, in English please.
3. Please follow GitHub-Flow method.

Thanks for your understanding and cooperation.

P.S
Only first commit is written in Japanese. Please accept my apology....

---- From here for Japanese. ----
本リポジトリは、イタリアのサレント大学の方も閲覧するようになります。
なので、上記の通り、コミット履歴やissueなどは英語でおねがいします。
色々手間かと思いますが、何卒よろしくおねがいします。
P.S
最初のコミットだけ日本語になっています。ご容赦下さい。。。。

Could you remove the namespace `fr01` from the urdf model?

As mention in the title. If the request is accepted, I want you check all the compatibility about namespace other than the things I noted below. That's why I didn't send pull request directly.

That's because diff_drive_controller doesn't seem to support namespace so the original model with namespace doesn't response when it gets cmd_vel topic. Other robots on github using the controller don't seem to use namespace either I searched so far.

Thus firstly, I tried several approaches to keep namespace fr01 while removing the namespace when applying diff_drive_controller. However, all of them didn't worked well to the extend I worked on.

The only and the simplest way is just removing the namespace from urdf. (To be honest, I don't wanna take looooong time to fix files to remain this namespace stuff lol.)

Then I change files as follows:

• removed fr01 from control yaml file,
• removed ns property of controller spawner and tag of robot_state_publisher in fr01_sim_control.launch,
• removed tag from gazebo plugin load tag in fr01.urdf.xacro.

After that, gazebo model started to run with cmd_vel, and everything seems going well. If possible, please remove namespace like above and fix related items you guys know.

Thanks.

About Gazebo Simulator

I already merged the codes for gazebo elements.
But there are some problems we have to resolve.
So, I want to share these info, and need your help.
Following info is same to #3 Pull Request.

1. Now, steer and wheel joints are moved by joint position controller.
   We need to change this controller to velocity controller (We need to make original ros_controller).
2. Not enough at experiment. We need to experiment on step, obstacle, and unevenness terrains.
   Of course, We need to create such terrains on Gazebo (not yet).
3. Sometimes the calculation (simulation) on Gazebo doesn't works well.
   But now, I don't know the reason and solution.

That is all.
Thank you for your cooperation.

Error occured when I used rosdep command.

When I was doing installation following wiki, I ran into error. Why ?

$ rosdep install -i --from-paths src
ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
fr01_gazebo: Cannot locate rosdep definition for [forest_robot_control]

Please tell me wheel radius and width!

As mentioned in the title. I couldn't figure them out from a collada format file lol.

background

I'm trying to apply diff_drive_controller to the robot as start up.

The controller requires the radius and width of wheels, which are used to compute kinematics of the model inside and should be needed for our robot model as well.