I noticed in the sample launch file that development mode is set to true. Removing the --development-mode flag causes the gantry not to spawn.

I had thought all the development-mode flag did was enable the cheat topics on the interface page, but it seems to be doing something else.

  <node name="ariac_sim" pkg="nist_gear" type="gear.py"
        args="--development-mode
          $(arg verbose_args)
          $(arg state_logging_args)
          $(arg gui_args)
          $(arg load_moveit_args)
          $(arg fill_demo_shipment_args)
          --visualize-sensor-views
          -f $(find nist_gear)/config/sample.yaml
          $(find nist_gear)/config/sample_user_config.yaml
          " required="true" output="screen" />

From gear.py

if not args.development_mode:
    os.environ['ARIAC_COMPETITION'] = '1'

I'm pretty sure we weren't allowed to run in development mode for the actual scored competition runs.

Working on sample2.yaml, the updated order does not arrive until immediately after the original order is submitted. The original order had 5 parts and the update conditions are:

announcement_condition: wanted_products
announcement_condition_value: 4

Changing announcement_condition_value to 2 makes no difference, the order update still does not happen until after submission of the filled first order.

Changing the condition to time works OK.

Lifting a single part is giving me a speed drop from 0.98x to 0.11x. Until the part has been resting long enough that Gazebo suspends collision checking on it (i.e., you don't see the visualized contacts anymore), the sim speed remains very low.

Video on Youtube

Check out the real time factor on the bottom.

Failed building ariac_example:
Problemed file: ariac_example_node.cpp:192:89
Descritption: error: no matching function for call to ‘count_if(std::vector::const_iterator, std::vector::const_iterator, laser_profiler_callback(const ConstPtr&)::<lambda(float)>)’

/home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp: In function ‘void laser_profiler_callback(const ConstPtr&)’:
/home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp:192:88: warning: lambda expressions only available with -std=c++11 or -std=gnu++11
     msg->ranges.begin(), msg->ranges.end(), [](const float f) {return std::isfinite(f);});
                                                                                        ^
/home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp:192:89: error: no matching function for call to ‘count_if(std::vector<float>::const_iterator, std::vector<float>::const_iterator, laser_profiler_callback(const ConstPtr&)::<lambda(float)>)’
     msg->ranges.begin(), msg->ranges.end(), [](const float f) {return std::isfinite(f);});
                                                                                         ^
In file included from /usr/include/c++/5/algorithm:62:0,
                 from /home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp:17:
/usr/include/c++/5/bits/stl_algo.h:3982:5: note: candidate: template<class _IIter, class _Predicate> typename std::iterator_traits<_Iterator>::difference_type std::count_if(_IIter, _IIter, _Predicate)
     count_if(_InputIterator __first, _InputIterator __last, _Predicate __pred)
     ^
/usr/include/c++/5/bits/stl_algo.h:3982:5: note:   template argument deduction/substitution failed:
/home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp: In substitution of ‘template<class _IIter, class _Predicate> typename std::iterator_traits<_Iterator>::difference_type std::count_if(_IIter, _IIter, _Predicate) [with _IIter = __gnu_cxx::__normal_iterator<const float*, std::vector<float> >; _Predicate = laser_profiler_callback(const ConstPtr&)::<lambda(float)>]’:
/home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp:192:89:   required from here
/home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp:192:89: error: template argument for ‘template<class _IIter, class _Predicate> typename std::iterator_traits<_Iterator>::difference_type std::count_if(_IIter, _IIter, _Predicate)’ uses local type ‘laser_profiler_callback(const ConstPtr&)::<lambda(float)>’
     msg->ranges.begin(), msg->ranges.end(), [](const float f) {return std::isfinite(f);});
                                                                                         ^
/home/frank/ariac_ws/src/ARIAC/ariac_example/src/ariac_example_node.cpp:192:89: error:   trying to instantiate ‘template<class _IIter, class _Predicate> typename std::iterator_traits<_Iterator>::difference_type std::count_if(_IIter, _IIter, _Predicate)’
make[2]: *** [CMakeFiles/ariac_example_node.dir/src/ariac_example_node.cpp.o] Error 1
make[1]: *** [CMakeFiles/ariac_example_node.dir/all] Error 2
make: *** [all] Error 2

Looking at the competition spec, it looks like the shelves can be in a large number of configurations. Will these be known before we specify the locations of the sensors in the world?

From the description, qual_a_3 should have a pulley to be flipped - and the order is looking for a red pulley.

However, there are no pulleys - only gears and gaskets. I think one of the blue gear areas - either on the shelf or bin - should be a red pulley.

@Pavel-P Changing the depth cameras to RGBD cameras makes a huge difference in the competition. I was originally hoping to use RGBD cameras this year. Their absence pushed me to use the digital cameras and A LOT of work has gone into getting things running with the digital cameras. To go back and redo that would be very painful, yet necessary, due to the cost difference and the large numbers of cameras needed. I strongly feel that since the sensors were specified at the start of the competition, they should not be changed mid-way. That imposes a big penalty to teams that focused on camera code vs teams that focused on other aspects of the environment.

If you offer the RGBD cameras as a new sensor, with the same cost as the digital cameras, that would be OK. It would allow teams that want to use RGBD cameras to do so, without forcing teams that have already invested tons of time into code for the digital cameras to switch to RGBD.

I found this document maybe have some error.

There are two "Scenario 1: Baseline Kit Building" and no "Scenario 2", please check, thanks!

In issue #38 , there was a comment:

Dan, your code will be tested against qual_b files which you do not have access. qual_a files are meant for participants to try their system and whatever you submitted will not be tested using any qual_a files. As long as your system deals with flipped parts then you should be good.

Is this correct? I thought that both qual_a and qual_b were used for the qualifiers score.

I just wanted to confirm - there is no topic for info related to the moving obstacles, right? We need to place cameras (or other sensors) throughout the world in order to detect them.

Not a big deal, but something to clean up. When the robot model is loaded, a warning is generated:

[ WARN] [1583863722.975019695]: Skipping virtual joint 'virtual_joint' because its child frame 'long_rail_1' does not match the URDF frame 'world'

The tutorial for preparing submissions links to an osrf repository that was used last year. Is that still valid for this year? If not, is there an updated repository for ariac-docker?

Issue: adding parts onto the torso tray slows the sim to a crawl
(from 0.98x -> 0.28x with 4 parts for my laptop with i7-8850H, 32GB RAM)

Suggestion: it'd be good to handle parts on the robot torso tray the way they're handled when attached to the gripper -- have gazebo create a temporary joint. This joint would be removed when something other than the robot torso tray comes in contact with the part again.

The wiki states that "Only the pulley_part will ever be requested to be flipped." In contrast, gasket part is required to be flipped as well in qual_a_2.yaml:

order_part3: gasket_part_red

order_0:
products:
part_3:
type: order_part3
pose:
xyz: [-0.15, 0.15, 0]
rpy: ['pi', 0, 0]

Please clarify, what is to be expected in the challenges? Thanks in advance!

I know that the order score is zero if the robot contacts itself or a dynamic obstacle. However, there does not seem to be any penalty for contacting structures such as shelves or the walls of the conveyor belt or the AGVs. Is that correct behavior?

I've encountered a weird bug and am wondering if anyone else is seeing this. For some reason, the right shoulder pan joint only has a range of 0 - 2pi instead of -2pi to 2pi. To see this, just use rqt immediately after startup. rqt shows a range of -2pi to 2pi in the slider bar, but moving past 0 to negative values does not get a response from the arm; it just stops at 0. The left arm works fine, as do all the other joints on the right arm.

Hello,

I had a significant issue getting the sample_environment to run. What finally fixed it was altering the "collision" and "visual" elements of the logical camera definition in ariac.world.template. The original text was looking for a mesh from a uri this way: "model://logical_camera/meshes/camera.dae." The logical camera model in nist_gear is named logical_camera_ariac. I altered the uri to: "model://logical_camera_ariac/meshes/camera.dae" and the sample_environment works now.

I hope this is helpful.
thediff.txt

I'm noticing very different behavior running inside vs outside of docker -- it seems to be related to simulation speed.

Out of curiosity, can you please share the specs of the machines you'll be running this on?

• Logical camera transforms (i.e. world -> camera) are duplicated on /tf, since they're already on /tf_static
• Transforms for objects seen by logical camera are published one at a time, which is slower than publishing them all at once each update cycle.

Fix and speedup in pull request #31

@stevegray954 @avidacs This seems like a bug rather than being the intended behavior.
The intended behavior: Drop only the first blue gear that is being placed in the tray.
The actual behavior: Drop only the first blue gear that each arm is placing in the tray.

We will need to get this fixed as soon as the qualifiers end. Thanks for reporting this.

Originally posted by @zeidk in #41 (comment)

When trying to run inside docker, the move group setup fails because it cannot find robot_description. Is there a different namespace for that in the docker version? Can you provide an example?

Modifying run_team_system.bash, replacing rosrun ariac_example ariac_example_node with rosrun ariac_example moveit_example results in this output:

[ INFO] [1584895281.650363526]: Loading gazebo_ros_control plugin
[ INFO] [1584895281.650491640]: Starting gazebo_ros_control plugin in namespace: /ariac/gantry
[ INFO] [1584895281.650881238]: gazebo_ros_control plugin is waiting for model URDF in parameter [/ariac/gantry/robot_description] on the ROS param server.
[ INFO] [1584895281.812392778]: Loaded gazebo_ros_control.
[Msg] VacuumGripper plugin loaded
[Msg] VacuumGripper plugin loaded
Error [parser_urdf.cc:3170] Unable to call parseURDF on robot model
Error [parser.cc:406] parse as old deprecated model file failed.
Error [parser_urdf.cc:3170] Unable to call parseURDF on robot model
Error [parser.cc:406] parse as old deprecated model file failed.

The sim starts but just eventually times out.

With my own code, it is unable to find robot_description. I'm using the namespace /ariac/gantry, so the full patlh is /ariac/gantry/robot_description It finishes quickly since it cannot assign the moveit groups:

�[ERROR] [1584894762.678864949]: Robot semantic description not found. Did you forget to define or remap '/ariac/gantry/robot_description_semantic'?
[FATAL] [1584894762.784235012]: Group 'Full_Robot' was not found.

When running qual_a_2, some parts are suddenly dropped from the agv tray while the robot is picking up part somewhere else.

Part dropped from agv2 tray: gasket_part_red, The config file includes:

drop_regions:
shipping_box_0_impeding:
frame: agv1::kit_tray_1
min:
xyz: [-0.3, -0.3, 0.0]
max:
xyz: [0.3, 0.3, 0.5]
destination:
xyz: [0.3, 0.3, 0.05]
rpy: [0, 0, 0.2]
product_type_to_drop: gasket_part_red

But this drop happens on AGV2 and not from gripper but after the part already sitting on tray for a while. Is that behavior supposed to be normal?

I try to add a small video of the event
auto-amgical-drop.zip

According to the updated scoring wiki page: 1 point is given for each correct product type touching the tray, and additional 1 point for each correct product color. However, it seems that no point is given when the color is wrong.

Example order:
Type: [piston_rod_part_blue]
Type: [gear_part_green]
Type: [gear_part_red]

Served parts:
kit_tray_1_bin4|piston_rod_part_red_1
kit_tray_1_bin3|gear_part_red_8
kit_tray_1_bin3|gear_part_red_6

Scoring:
<shipment_score >
Completion score: [2]
Complete: [false]
Submitted: [true]
Product presence score: [1]
All products bonus: [0]
Product pose score: [1]
Delivered to correct agv: [true]
</shipment_score>

Do the moving obstacles always start at the end of an aisle? If so, is it always the same end (e.g., near the conveyor belt)? Are they always in the same Y location (e.g., location: = 1.57 in the config file) within an aisle or do they sometimes start with other values for location (e.g., 1.50) within a particular aisle?

In qual_1_a, if the parts get delivered such that the second part needed for the updated order is delivered last in the original order, then the update is not triggered until after the original order is completed. This means that we have to wait around a bit after completing an order before submitting it, just in case there is an updated order about to show up.

Is there some way to know how long we should wait? In other words, is there some maximum time after an order is fully delivered to the tray that there will not be an updated order sent?

As far as which code version we'll be running, I think the best option would be to let teams specify if they want to use a particular commit as long as that commit falls within the qualifier window. I don't think the version differences will be enough to change who does or doesn't qualify, and this way teams that already submitted aren't forced to make any new changes. We're open to other options though.

Originally posted by @Pavel-P in #41 (comment)

Probably due to reverting back to the original version of the depth camera.

Observed following error during catkin build:

Errors << nist_gear:install /home/frank/ariac_ws/logs/nist_gear/build.install.000.log
CMake Error at cmake_install.cmake:675 (file):
file INSTALL cannot find
"/home/frank/ariac_ws/src/ARIAC_ORIGINAL/nist_gear/rviz".

make: *** [install] Error 1
cd /home/frank/ariac_ws/build/nist_gear; catkin build --get-env nist_gear | catkin env -si /usr/bin/make install; cd -

It seems that there is a missing folder?

Check out this video of moving a gear:
https://www.youtube.com/watch?v=d4r4zSL8EOg&feature=youtu.be

All the other contacts on all other objects activate. This shouldn't happen. Unfortunately, it's likely a gazebo bug. Any time a part moves, all contacts go active. This does not happen when the robot moves.

Easy to replicate - turn on contact visualization and move anything.

Edit: Note, this video has my fix from #4 present, which is why it only slows to 0.72x instead of 0.12x on my machine. This issue was present before and after that other fix.

Trying to test the sample environment for ARIAC 2021 using

roslaunch nist_gear sample_environment

Takes several minutes of inactivity to load, even when accounting for the time it takes to fetch the models used by the simulation.

The problem seems to be that the configuration file for the environment in sample_test.yaml contains two models that are not available to load the current time, piston_rod_part_blue and gear_part_red.

This also impacts testing moveit on the environment (when using load_moveit:=true), because the joint controllers timeout while waiting for a service because of the extra time, crashing and leaving the simulation unable to be controlled using rviz/moveit once it finally loads.

Commenting out the section here https://github.com/usnistgov/ARIAC/blob/master/nist_gear/config/sample-test.yaml#L116 allows the simulation to load much faster and allows to test moveit on the environment.

I'm guessing you are editing the wiki directly on Github. Please don't. It makes the commit history difficult to skim through to determine what has changed as we get things like 10 successive commits labeled 'Update automated_evaluation.md'. It's easier when the commit description is meaningful (and there aren't a ton of them).

Thanks!

Turned on verbose mode and see this with sample.yaml and sample_obstacles.yaml. I haven't tried other configs yet.

[Wrn] [World.cc:1079] Model with name [bin4|piston_rod_part_blue_6] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin4|piston_rod_part_blue_5] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin4|piston_rod_part_blue_4] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin4|piston_rod_part_blue_3] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin4|piston_rod_part_blue_2] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin4|piston_rod_part_blue_1] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin3|gear_part_green_2] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [shelf1|gear_part_red_5] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [shelf1|gear_part_red_4] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin3|gear_part_green_4] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin3|gear_part_green_1] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [shelf1|gear_part_red_1] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [bin3|gear_part_green_3] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [shelf1|gear_part_red_3] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.
[Wrn] [World.cc:1079] Model with name [shelf1|gear_part_red_2] already exists. Not inserting model. This warning can be ignored in certain situations such as rewind during log playback.

Is this expected behavior?

Related to @dan9thsense's comment in #38 (comment)

It would be good to tag a version of the code we know is going to be used for qualification evaluation, while development continues on code to be used in the finals.

The tutorials and samples for 2020 list arm-related topics as "/ariac/arm1..." and "/ariac/arm2/..." but when I run the environment with "roslaunch nist_gear sample_environment.launch" there are no "arm1" or "arm2" topics. There are "/ariac/gantry/left_arm_..." and "/ariac/gantry/right_arm_..." topics. Is there a mapping of arm arm1/2 to arm right/left I should know about?
Accordingly, the "Interacting with GEAR" tutorial has many steps that don't work since the topics don't exist. For example, nothing in the "Controlling Arm Joints" section works as-is. I can spend the time figuring it all out, but I am hoping there is a mapping or an updated tutorial (and sample files) somewhere. Thank you!

To speed development with docker, I'd like to add a local folder to the docker image. Can I do that with the build_team_system.bash script?

With dockerfiles there is the add command:

add ~/some_local_folder ~/my_team_ws/src

but the add command does not work with bash

Setup according to the instructions, but seg faults when trying to run
roslaunch nist_gear sample_environment.launch

The gazebo screen pops up momentarily and then crashes. The initial error is:
[Err] [REST.cc:205] Error in REST request

Looks like it happens when gazebo gets unpaused:
gazebo_unpauser.py", line 33

Here is the error stream:

[INFO] [1614202877.670063, 0.000000]: Loading model XML from ros parameter robot_description
[INFO] [1614202877.678518, 0.000000]: Waiting for service /gazebo/spawn_urdf_model
[Err] [REST.cc:205] Error in REST request

libcurl: (51) SSL: no alternative certificate subject name matches target host name 'api.ignitionfuel.org'
[ INFO] [1614202879.546309021]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[INFO] [1614202879.599366, 0.000000]: Calling service /gazebo/spawn_urdf_model
[ WARN] [1614202879.631251693]: spawnURDFModel service called
[ WARN] [1614202879.631973562]: spawnSDFModel service called
[ INFO] [1614202879.636066130]: Physics dynamic reconfigure ready.
[INFO] [1614202879.753070, 0.000000]: Calling service /gazebo/spawn_urdf_model
[INFO] [1614202879.788453, 0.000000]: Calling service /gazebo/spawn_urdf_model
[ WARN] [1614202880.727154377]: spawnURDFModel service called
[INFO] [1614202880.727325, 0.000000]: Spawn status: SpawnModel: Successfully spawned entity
[ WARN] [1614202880.727953991]: spawnSDFModel service called
[spawn_gazebo_sensors-5] process has finished cleanly
log file: /home/dbarry/.ros/log/0485617c-76e9-11eb-8336-181deaec5b6c/spawn_gazebo_sensors-5*.log
[ WARN] [1614202881.004908991]: spawnURDFModel service called
[INFO] [1614202881.005148, 0.000000]: Spawn status: SpawnModel: Successfully spawned entity
[ WARN] [1614202881.005499598]: spawnSDFModel service called
[INFO] [1614202881.006428, 0.000000]: Waiting for service /gazebo/set_model_configuration
[INFO] [1614202881.008359, 0.000000]: temporary hack to **fix** the -J joint position option (issue #93), sleeping for 1 second to avoid race condition.
Service call failed: transport error completing service call: unable to receive data from sender, check sender's logs for details
[ERROR] [1614202881.144598, 0.000000]: Spawn service failed. Exiting.
Segmentation fault
================================================================================REQUIRED process [gazebo-2] has died!
process has died [pid 3312, exit code 139, cmd /home/dbarry/ariac_ws/src/ariac-gazebo_ros_pkgs/gazebo_ros/scripts/gzserver -u -e ode /tmp/ariac/ariac.world __name:=gazebo __log:=/home/dbarry/.ros/log/0485617c-76e9-11eb-8336-181deaec5b6c/gazebo-2.log].
log file: /home/dbarry/.ros/log/0485617c-76e9-11eb-8336-181deaec5b6c/gazebo-2*.log
Initiating shutdown!
================================================================================
**[gazebo_unpauser-15] killing on exit
Traceback (most recent call last):
  File "~/ariac_ws/src/ARIAC/nist_gear/script/gazebo_unpauser.py", line 33, in <module>
    time.sleep(3)**

Running the example with
roslaunch nist_gear sample_environment.launch

The environment loads ans shows up in Gazebo OK ans lots of rostopics are being published, but it cannot find the gantry and arm controllers.

Here are the errors:

[ERROR]: Could not load controller 'gantry_controller' because controller type 'effort_controllers/JointTrajectoryController' does not exist.
[ERROR]: Use 'rosservice call controller_manager/list_controller_types' to get the available types

[ERROR]: Could not load controller 'left_arm_controller' because controller type 'effort_controllers/JointTrajectoryController' does not exist.

[ERROR]: Could not load controller 'right_arm_controller' because controller type 'effort_controllers/JointTrajectoryController' does not exist.

Here is the result of the suggested call,
rosservice call controller_manager/list_controller_types

ERROR: Service [/controller_manager/list_controller_types] is not available.

I am seeing pose scores of 0 for parts that are the wrong color but the correct pose. For example, deliver red gear parts instead of blue gear parts in order 1 of qual_a_3. The order calls for:

      part_0:
        type: order_part2
        pose:
          xyz: [0.1, -0.2, 0]
          rpy: [0, 0, 0]
      part_1:
        type: order_part2
        pose:
          xyz: [-0.1, -0.2, 0]
          rpy: [0, 0, 0]

and here is the output from rostopic echo /ariac/trays

destination_id: "agv2::kit_tray_2::kit_tray_2::tray"
products: 
  - 
    type: "gear_part_red"
    is_faulty: False
    pose: 
      position: 
        x: -0.102597193884
        y: -0.205921971299
        z: 0.0148429286886
      orientation: 
        x: 0.00778541131923
        y: -0.00481658327204
        z: 0.00435378759387
        w: 0.999948614895
  - 
    type: "gear_part_red"
    is_faulty: False
    pose: 
      position: 
        x: 0.0998754446981
        y: -0.198373526491
        z: 0.0150794675094
      orientation: 
        x: 0.0110030839075
        y: -0.00520408240934
        z: -0.00154785025691
        w: 0.999924724082

but the score gives 0 points for pose.

When I call the service to submit a shipment, error messages occur. The shipment gets submitted successfully, but I am concerned that something I am doing wrong is triggering these messages.

[ERROR] [1583860898.686263548, 31.877000000]: agv1::kit_tray_1::kit_tray_1::tray: Handle get content service called by: /gazebo
[ERROR] [1583860898.695310152, 31.885000000]: [INFO] AGV 'agv1' delivery triggered
[ INFO] [1583860899.461913803, 32.637000000]: AGV successfully triggered.

I could not re-open the following issue.
#12 (comment)
Thus, I will copy and paste my question on here.

@Pavel-P
Hi, I have a question on depth_camera and rgbd_camera.
I understand that you update depth_camera can only publish PointCloud topics.
Before the update, we could subscribe also RGB data.
But because of RGBD camera update, there are no sensor can publish RGB data except rgbd_camera.
I can apply this modify and I understand your great effort for making the rule fair.
But I am wondering that this year's task, we need to detect the color.
And we have no choice to detect them except most expensive cost sensors(rbgd_camera).
Thus, if possible, I would like to use simple rgb camera as low cost sensor ($100 cost sensor).
If not possible, to utilize rgbd_camera makes no sense because, the cost is same as logical_camera which returns TF and color.
I think, in the following source code, simple rgb camera can use. But I could not launch them with type: camera parameter.
https://github.com/usnistgov/ARIAC/blob/master/nist_gear/script/gear.py#L62
In anyway, I would like to ask you about the answer for using simple rgb camera.

Thank you for your kind.
Best Regards,
Ryodo

Did I miss an update? When did the baseline cost change from $1700 to $10000.?

The pulley part easily slips from the gantry torso's tray even if the robot moves with ridiculously low acceleration. It feels like the friction coefficient was zero. On the other hand, other parts remain on the gantry tray when the robot moves with reasonable accelerations. Is that behavior deliberate?

(Suggestion: increasing the friction on the gantry tray would help a lot when using the robot to collect as many parts as possible, and not just delivering parts two-by-two.)

Do updated orders not get the x3 priority order bonus? Didn't happen for qual_1_a.

The arms are allowed to pass freely through each other as well as through the base. This means that the check for arm-arm collision in RosAriacTaskManagerPlugin::OnContactsReceived() doesn't register when the arms collide.

To replicate: use rqt robot_description:=/ariac/gantry/robot_description to pass the arms through eachother. The line ROS_ERROR_STREAM("arm/arm contact detected: " << contact.collision1() << " and " << contact.collision2()); in OnContactReceived() should print to ROS ERROR

Based on the earlier discussion, I am suggested to post my question here. We are asked to submit the emails of the team members for adding them to the team's competition page. With that I have a quick question:

Are we able to update the team members after submission of the contributor's list? Or is the list fix until the end of the competition?

Are there any more details you can share about the qualifier? April is just a month away we are short on details. Even dates in April would be useful for time budgeting. When can we expect finalizing competition details like sensor configurations and shelf layouts? What about releasing qualifier scenarios? When will the deadline be?

The wiki says the qualifier runs April 6-10. Is that when you guys will be evaluating the submissions? Does that make the deadline April 5th at 11:59pm or April 10th at 11:59pm?

Pulled from the repo today. Looks like qual_a_3 has changed from when it was originally released, with the gear part blue in bin3 moved to shelf 8 and replaced with a pulley part red. Is that right?
If the qual_a trials are part of the scoring, this sort of change makes things really hard for teams that submitted earlier in the quals window and do not happen to have time this week to make and then test code changes.

Running without the --development-mode flag, ariac/conveyor/state is always power: 100, enabled: True when /ariac/start_competition is called. This is true for all the qual_a scenarios, including 1 and 3 - though in their descriptions they say Conveyor belt is not active.