search

osrf / srcsim

Space Robotics Challenge
Other
9 stars 4 forks source link

Foot glitches near table on sample task 2 #186

Open osrf-migration opened 7 years ago

osrf-migration commented 7 years ago

Original report (archived issue) by GoRobotGo (Bitbucket: GoRobotGo).

The original report had attachments: footGlitch.mp4, withcontacts.mp4, twostep.cpp, contact_flicker.mp4, contact_flicker.log

There appears to be an odd contact behavior that causes the foot to glitch or fall near the table on sample task 2. I am not sure if it is present elsewhere in other worlds, but it is present in this world. It does appear to be repeatable. I have attached a video with collisions and one with contacts to illustrate the issue. To repeat:

#!c++

roslaunch srcsim unique_task2.launch  init:="true"
rosservice call /srcsim/finals/start_task 2 3
take a couple of small steps forward
osrf-migration commented 7 years ago

Original comment by Tom Tseemceeb Xiong (Bitbucket: Tom_Xiong).

I've experienced this exact same issue several times now. Though it's only really bad when I use the 2ms boost. Otherwise without it I don't see those problems

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

I was able to reproduce it here, using the software from srcsim_0.5.0. I haven't figured out how to always reproduce it though, I'm using the keyboard teleop and the steps are a bit different. I only saw it once in about 10 steps.

Just looking at the contact visuals on the video, it doesn't look like Gazebo is calculating strange forces, with large magnitudes or weird directions. But it's hard to tell just from the video.

If you have a command or script which I can use to reproduce the exact step you're taking, I can try to gather some data here. It would be interesting to plot the forces being applied to the foot and ankle.

osrf-migration commented 7 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I have attached a short c++ program that will hopefully help reproduce it. It can be run repeatedly.

osrf-migration commented 7 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

osrf-migration commented 7 years ago

Original comment by Jeremy White (Bitbucket: knitfoo).

I've just seen this for the first time. It may be unrelated, but for me, it seems to have only happened after I updated to the tip (r650). Previously, I had been using r633, with higher_array at r635 manually merged in. That may be a red herring; I'll keep testing and see if I get any consistency to it.

osrf-migration commented 7 years ago

Original comment by Jeremy White (Bitbucket: knitfoo).

I think I'd ignore that; I've just gotten a bunch of clean runs with the tip, so I think my input is likely a red herring.

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Thanks for the code, @GoRobotGo . I'm now able to reproduce it more reliably, but it doesn't happen 100% of the time.

One weird thing I did notice though is that sometimes there are contacts registered in the middle of nowhere, which could be related or not:

contactfoot.gif

osrf-migration commented 7 years ago

Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).

I just pulled from step_size_2ms branch and saw this issue. Also, the robot was at least 2m away from the solar array box.

osrf-migration commented 7 years ago

Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).

Similar glitches are seen in Task1 as well. This is after pulling the latest default branch today. In the attached gif the footstep was a single step at the location where the foot touches first

foot_glitch.gif

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

@vinayak_jagtap , it calls my attention that the green lines representing the force of contact are shorter on your example. Is the robot putting its full weight on the feet?

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

The question I'm asking myself is: is this a problem with Gazebo sending unrealistic data to the controller, or is it a problem of the controller misbehaving for some corner case?

osrf-migration commented 7 years ago

Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).

When I look at the contacts during simulation, the forces look fine. when I play the log file, the lines are smaller. I'm seeing these glitches in 1 out of 3 runs. In some cases, the robot balances itself and the task doesn't fail but if the robot has the panel in hand it falls down due to this glitch. To me, it looks like some delay in communication between state estimator and controller which forces the controller to believe robot is in a different state and sends wrong control torques. I never noticed this issue in the previous version of master.

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

@scpeters , have you seen this issue?

osrf-migration commented 7 years ago

Original comment by Shlok Agarwal (Bitbucket: shlokagarwal).

I am seeing a similar issue near the table in sample task 2. I have attached a video to illustrate the same.

foot_glitch.gif

osrf-migration commented 7 years ago

Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).

One more observation is that the glitch occurs at the intersection of 2 segments of the walkway. All the images and videos posted here have walkway segment collisions. Can that be a coincidence?

foot_glitch.jpg

osrf-migration commented 7 years ago

Original comment by Jedediyah Williams (Bitbucket: Jedediyah).

I'm curious if you can you see any horizontal contacts when this happens? I suspect you're right about it happening when the foot is near an edge of one of the platforms. I think Gazebo uses a heuristic when identifying contacts, that when there are multiple potential contacts it will attempt to correct the deepest. When meshes are near edges though, this tends to "correct" the wrong contact, shooting objects sideways.

contact.png

osrf-migration commented 7 years ago

Original comment by Víctor López (Bitbucket: Victor Lopez).

Happened to us too several times today. Out of 20 attempts of walking around the walkways, we had 4 valkyrie falls when walking on the connection of two walkways.

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

I'll change the collisions of the 45 degree walkway so they don't overlap, let's hope this helps. Please do let me know if you observe this glitch on a different walkway, so I don't put time into changing this. Thanks!

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

osrf-migration commented 7 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

I think we may be able to fix this by adjusting the contact parameters of the walkway models. I'm investigating

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

osrf-migration commented 7 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

I think we could change the contact geometry to using polylines instead of overlapping boxes, which may fix the glitches. @chapulina I did some quick testing, and I think this might work well. We'll see if we can make a quick fix for this.

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Pull request #97 removes the overlapping collision shapes

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

pull request #98 generates a single polyline collision for the whole walkway, to also get rid of boundaries between two touching collisions

osrf-migration commented 7 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

I prefer pull request #97

osrf-migration commented 7 years ago

Original comment by jordan_palacios (Bitbucket: jordan_palacios).

The same glitch happens in the habitat.

Reported this in pull request #97 but mentioning it here too for visibility.

osrf-migration commented 7 years ago

Original comment by Víctor López (Bitbucket: Victor Lopez).

This is critical, we have wasted one day of grasping tools and walking to the wall and falling in the way there because of this.

osrf-migration commented 7 years ago

Original comment by GoRobotGo (Bitbucket: GoRobotGo).

I think the habitat issue is different - I am submitting a new issue for it.

osrf-migration commented 7 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

pull request #100 for the habitat

osrf-migration commented 7 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

I've cropped a log file that shows the flickering contact point behavior and made a short video. In order to play back the log file, I recommend that you clone srcsim and add the models folder to the GAZEBO_RESOURCE_PATH and GAZEBO_MODEL_PATH. You don't have to build it; just clone it. It won't show the valkyrie meshes, but if you View Contacts, that should be enough. You can even right click on valkyrie in the model list widget and click View Inertia, then it will show the robot bodies.