Closed osrf-migration closed 7 years ago
Original comment by Rud Merriam (Bitbucket: rmerriam).
Original comment by Harish Balasubramaniam (Bitbucket: harishbalasub).
Just to confirm another case- When I try to skip to checkpoint 3 standing in front of the wheel, i seem to bump/crash into the wheel .
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
See pull request #53 for Harish's comment.
Original comment by Harish Balasubramaniam (Bitbucket: harishbalasub).
Your changes in #53 are for a different 'unique*' world than the default one (position of wheel, dish, finish line all has changed). I was able to teleport without crashing but the world is new. I see there are too many changes in those 3 files. Would you be able to provide a fix for the default world? I have been working with the default world so far, and would like to revert to it so we can finish our testing there.
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
You can apply the following changes to the unique_task1.world
which was released with srcsim_0.3.0
to have the robot spawning further away from the satellite:
diff -r 3ccf077da06cc7e4fbf7cc3fa1c8498c40aff87c worlds/unique_task1.world
--- a/worlds/unique_task1.world Wed Feb 15 19:07:13 2017 +0100
+++ b/worlds/unique_task1.world Thu Apr 06 09:46:13 2017 -0700
@@ -442,8 +442,8 @@
<entity>valkyrie</entity>
<namespace>task1/checkpoint1</namespace>
<pose>
- 2.3833126437626904
- -0.3967392862909891
+ 2.241891287525381
+ -0.25531793005367986
2.5
0
0
@@ -586,8 +586,8 @@
<task_1_timeout>1800</task_1_timeout>
<task_1_checkpoint_2_pose>
- 2.3833126437626904
- -0.3967392862909891
+ 2.241891287525381
+ -0.25531793005367986
1.1
0
0
@@ -595,8 +595,8 @@
</task_1_checkpoint_2_pose>
<task_1_checkpoint_3_pose>
- 2.3833126437626904
- -0.3967392862909891
+ 2.241891287525381
+ -0.25531793005367986
1.1
0
0
Beware that the configuration of the default world will change with the upcoming release though.
Original comment by Rud Merriam (Bitbucket: rmerriam).
Came up with a big concern about pose not being updated. Can this be done at all? If not, the competition as currently planned using teleportation to skip checkpoints needs a radical change.
My understanding is the teleporting only changes the position in Gazebo. That means there is a requirement to tell the ROS, NASA and IHMC simulation components that the pose is now totally updated. It's not only the overall pose but the pose for all the other joints and components of R5. Hopefully they get updated automatically through the URDF linkages. If I were working this problem my first question would be if there are APIs in the component pieces that would handle this?
My next question is whether a discontinuous change in pose is going to be handled gracefully by the components. The IHMC software seems especially fragile with respect to discontinuities.
I'm fascinated with the glimpses I see of the work going into the development of the competition. That leads me to consider the issues on the competition software side of this problem. I hope my concerns here are unfounded but thought I'd mention them just in case they are not.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
I had assumed that the following topics could be used to update the pose in the state estimator:
/ihmc_ros/localization/pelvis_odom_pose_correction
/ihmc_ros/localization/pelvis_pose_correction
but I haven't figured out how to get that to work.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
I just talked with Doug from IHMC, and he said that those pose correction topics are used for giving small hints to the state estimator and have a threshold (currently 10 cm) that pose hints must be within in order for the hint to be accepted. Even if they increased the threshold, though it would take time for the hinted state to converge, since there won't be any acceleration signals for the robot to observe.
I also spoke to my colleague Tully here at OSRF, and he said that teleporting the robot could be considered drift in odometry, which is a very common situation in robotics. The solution to drift in odometry involves relocalizing yourself against a map of the environment. There is some discussion on the ROS wiki about localization:
I'm going to close this since the solution is that the teams should relocalize after teleportation.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Original comment by Rud Merriam (Bitbucket: rmerriam).
I'd say drift is considerably different than teleportation.
So what is pose supposed to mean? This is another situation where the IHMC document is woefully lacking. Is it forever wrong or will it come back into alignment.
A big remaining question is whether IHMC's software will handle the teleportation. Haven't seen a problem yet but I'm not confident given past experience.
I'm well aware of the need for localization. The Sample Return Robot CC had no absolute references since neither GPS nor magnetometers work on Mars. At least with the SRR we could create beacons for guidance.
Original report (archived issue) by Rud Merriam (Bitbucket: rmerriam).
The information from /ihmc_ros/valkyrie/output/robot_pose is not updated when the task/checkpoint message is sent causing a teleportation of the robot to a new location and orientation.
Running an rostopic echo of the pose message shows no change after sending the message
rosservice call /srcsim/finals/start_task 1 2
or for other checkpoints.
Updated to critical since it is necessary for testing by skipping checkpoints.