Open osrf-migration opened 7 years ago
Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).
Update: This error is not seen when running a single task and we are proceeding with our testings on just unique_task1.world.
on a side note, I feel srcsim works almost fine when running one task at a time, if it cannot be made more reliable why not load task specific worlds in finals? We will lose out pointcloud gathered from different angles during completing the previous task but spending a little extra time in start box is a very small price to pay if loaded worlds are more robust.
Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).
I'm unable to get into gdb after this failure. Is there anything more to be done apart from adding debug:=true? This is causing a failure every single time I finish setting both the handles in task1 in the complete world.
Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
Does this error happen only on cloudsim?
Changing srcsim to run each task individually would change the structure of the competition at a fairly late stage.
Let us know if/when you experience this problem during dry run and we'll perform a reset. After a reset, you can skip to the appropriate checkpoint. We'll keep track of this reset so that you won't loose points.
This process is a bit painful, but changing the competition structure will have a different set of pain points.
Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).
Thanks for the comments. I'm running on local setup here and planning to test it out on cloudsim tonight. Unfortunately, there is no way for me to read that state on OCU to know that the realtime factor is 0.
I'm trying to get debug info so as to understand the error better but looks like gdb is not attached to the process. I see the following lines when I launch srcsim with debug flags
process[gazebo-6]: started with pid [27639]
/opt/ros/indigo/lib/gazebo_ros/debug: 5: [: Linux: unexpected operator
Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).
@nkoenig we are facing a similar issue when we open the door handle in task3. How can that be reset to a point where the door handle is open? This error occurs more than 80% of the time and we can help provide debug logs if required but will need some support in generating those logs as well.
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
It's unlikely that we will be able to resolve this issue since the java controllers are a black box to us, and time is short. I can only offer the suggestion of trying an alternate approach. For example, if you're grasping the wheel then maybe try an approach that doesn't create as many contact constraints.
Original comment by Vinayak Jagtap (Bitbucket: vinayak_jagtap).
It is too late for us to change those grasps or trajectories now (we'll try our best to modify it, if possible). Given that we are using the APIs as documented and this issue being out of our scope, could we or any other team get a no score/time penalty reset if this occurs?
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
Changing your grasps and trajectories is your call. I'm not trying to convince you to change your code.
Since this problem is out of your control, then we can reset you without penalty. What could impact you is the overall duration of the final event. We have a hard stop on Friday of next week.
Original report (archived issue) by Vinayak Jagtap (Bitbucket: vinayak_jagtap).
Saw this error twice today. After getting the error, the real time factor is 0.0. In both cases, the robot was fixing either pitch or yaw in task1. Any specific log that I should be looking at to provide more details?