forest_robot_project's People
forest_robot_project's Issues
About tf tree
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.
- If you commit and push your codes, please write the details about the modification in English.
- If you have some question, ask at this issue page. Of course, in English please.
- 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 ofcontroller spawner
and tag ofrobot_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.
- 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). - 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). - 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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.