Bug on delivery?

[Former user]

I get the following error when I try to deliver a shipment.

[ INFO] [1554995839.768574102, 9.167000000]: Announcing order: order_0
[ERROR] [1554995942.251601951, 40.906000000]: agv1::kit_tray_1::kit_tray_1::tray: Handle get content service called by: /gazebo
[ERROR] [1554995942.252541255, 40.906000000]: [INFO] AGV 'agv1' delivery triggered
[ INFO] [1554995946.012338406, 41.658000000]: AGV successfully triggered.

The AGV delivers the tray, but even though there are parts in it, the score remains 0. I used qual_a_2 to try it out, but even with custom ones it doesn't work

[Shane Loretz]

code block for readability

[Shane Loretz]

Those error statements can be ignored; they should actually be info.

Are you sure the shipment is being delivered to the correct AGV? qual_a_2 requires the first shipment to be delivered via agv1 and the second via agv2.

The following works fine for me. If it doesn't work for you, mind posting the output of these commands?

Spawn qual_a_2 with perfect shipments already on the trays

rosrun osrf_gear gear.py -f $(catkin_find osrf_gear --share)/config/quals/qual_a_2.yaml $(catkin_find osrf_gear --share)/config/quals/shipments/qual_a_2.yaml $(catkin_find osrf_gear --share)/config/sample_user_config.yaml --development-mode --verbose

In another terminal:

$ rosservice call /ariac/start_competition
success: True
message: "competition started successfully!"
$ rosservice call /ariac/agv1 "shipment_type: 'order_0_shipment_0'"
success: True
message: ''
$ rostopic echo -n 1 /ariac/current_score
data: 15.0
---
$ rosservice call /ariac/agv2 "shipment_type: 'order_0_shipment_1'"
success: True
message: ''
$ rostopic echo -n 1 /ariac/current_score
data: 30.0
---

[Steven Gray]

No idea if this is the same issue, but I had some test code that called gazebo_ros spawn_model to test getting parts on trays. I had to modify it to spawn the parts a little above the tray, then wait for them to drop onto the tray.

Good way to check is to see how many parts Gazebo says are on the tray, and if gazebo creates fixed joints between parts and tray when you submit. This info probably only prints out if osrf_gear is set to verbose.

[Francesco Rovida]

My bad, I was using the id shipment_0 instead of order_0_shipment_0 .

[Francesco Rovida]

When trying the execution on docker with the sample.yaml trial, I get the following error when delivering:

[ERROR] [1555091338.103465212, 91.947000000]: agv1::kit_tray_1::kit_tray_1::tray: Handle get content service called by: /gazebo
[ERROR] [1555091338.104798886, 91.947000000]: [INFO] AGV 'agv1' delivery triggered
terminate called after throwing an instance of 'std::system_error'
  what():  Resource deadlock avoided
Aborted (core dumped)
================================================================================REQUIRED process [gazebo-3] has died!
process has died [pid 87, exit code 134, cmd /opt/ros/melodic/lib/gazebo_ros/gzserver -u --verbose -e ode -r --record_period 0.01 --record_path=/home/ariac/.ariac/log/gazebo /tmp/ariac/gear.world __name:=gazebo __log:=/home/ariac/.ros/log/0cb41eb6-5d4a-11e9-92ba-0242ac120016/gazebo-3.log].
log file: /home/ariac/.ros/log/0cb41eb6-5d4a-11e9-92ba-0242ac120016/gazebo-3*.log
Initiating shutdown!
================================================================================

[Shane Loretz]

@fraR Mind opening a new issue for that one?

Do you see that every time or only sometimes? I don't see it on my machine. Do you have an example I can use to reproduce it? What are the values of the fields in the service request being sent?

Here's what I'm running

rosrun osrf_gear gear.py -f $(catkin_find osrf_gear --share)/config/sample.yaml $(catkin_find osrf_gear --share)/config/sample_user_config.yaml --verbose

And in another terminal

$ rosservice call /ariac/start_competition
success: True
message: "competition started successfully!"
$ rosservice call /ariac/agv1 "shipment_type: 'order_0_shipment_0'"
success: True
message: ''

[dan]

similar error here. See issue #168

[Shane Loretz]

Question answered, and second issue in comments fixed by pull request #136