This repostory contains software for the virtual track of the DARPA SubT Challenge. Within this repository you will find Gazebo simulation assets, ROS interfaces, support scripts and plugins, and documentation needed to compete in the SubT Virtual Challenge.
License: Other
Please visit the wiki for more information
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
Is it possible to extend existing configurations with one with two 2D LIDARs, when one would be mounted horizontally (as it is now) and the second would be pointing down at angle somewhere between 30 and 45 degrees? Several teams in Robotour [1] are now using this combination where the first LIDAR is used for obstacle avoidance and the second for road surface traverseability (in SubT to detect stones and holes).
I am aware of SubT Challenge Guidance "Virtual competitors must use existing models from the SubT Tech Repo.", but there is also note about potential extensions ... thank you.
Original report (archived issue) by Anonymous.
After about 30 minutes of exploring the training tunnel, I got this message:
[Dbg] [MotionTimerLockPlugin.cc:97] Locking joints in model X1
Where does that come from, does it have any significance, and how do I unlock the joints?
Original report (archived issue) by Jack Kelly (Bitbucket: jack-kelly).
Either need some friction on the ground or wind to not affect them.
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
In the qualification circuit is fire extinguisher placed at
158.000000 140.000000 -15.000000 0 0 0.000000
If you send this coordinates to Base Station you will get 0 score due to limit 4m (newer rules accept 5m). Extra debug output showed 4.5m distance error, so probably offset of the entrance to the tunnel. But according to "SubT_Challenge_Competition_Rules_Tunnel_Circuit.pdf" is X coordinate to the right and Y straight, so the coordinates should be X=-140 and Y=158? Then it would not report such a small distance.
Original report (archived issue) by Anonymous.
Is it possible for you to add a sensor to measure height above ground of the vehicles? It think this would benefit all the teams.
Thanks,
Hector.
Original report (archived issue) by dan (Bitbucket: dan77062).
Here is the error generated after cloning subt_seed and trying to catkin_make_install:
In file included from ~/subt_seed_ws/src/subt_seed/src/subt_seed_node.cc:23:0:
~/subt_ws/install/include/subt_gazebo/CommsClient.hh:30:10: fatal error: subt_gazebo/protobuf/datagram.pb.h: No such file or directory
#include "subt_gazebo/protobuf/datagram.pb.h"
I suspect the problem is that the file is present in the ~/subt_ws/devel/include/subt_gazebo/protobuf directory, but in the install directory, it is located in ~/subt_ws/install/include/subt_gazebo There is no protobuf subdirectory in the install path to that file. Since we source install and not devel, it gets missed.
However, when I copied the subt_seed_node.cc file into my own workspace, setup CMakeLists.txt and manifest.xml, then catkin_make succeeded.
Original report (archived issue) by Anonymous.
Hello,
Following the docker tutorial, the roslaunch command fails with:
#!c++
auto-starting new master
process[master]: started with pid [562]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to 30518de8-f71c-11e8-bbbc-0242ac110002
process[rosout-1]: started with pid [573]
started core service [/rosout]
process[gazebo-2]: started with pid [576]
Gazebo multi-robot simulator, version 9.5.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org
process[gazebo_gui-3]: started with pid [585]
[ INFO] [1543856109.388261148]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1543856109.389172948]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 172.17.0.2
[ INFO] [1543856109.678520660]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1543856109.680797510]: waitForService: Service [/gazebo_gui/set_physics_properties] has not been advertised, waiting...
[Msg] Starting SubT
[Msg] Starting SubT comms broker
gzserver: symbol lookup error: /home/developer/subt_ws/install/lib/libBaseStationPlugin.so: undefined symbol: _ZN4subt11CommsClientC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
[gazebo-2] process has died [pid 576, exit code 127, cmd /opt/ros/melodic/lib/gazebo_ros/gzserver -e ode --verbose /home/developer/subt_ws/install/share/subt_gazebo/worlds/tunnel_practice_1.world __name:=gazebo __log:=/home/developer/.ros/log/30518de8-f71c-11e8-bbbc-0242ac110002/gazebo-2.log].
log file: /home/developer/.ros/log/30518de8-f71c-11e8-bbbc-0242ac110002/gazebo-2*.log
___________________________________________________
Attempting to run the mentioned process directly gives:
developer@74bc78790133:~/subt_ws$ cat /home/developer/.ros/log/30518de8-f71c-11e8-bbbc-0242ac110002/rosout.log
0.a527ae8c41762a101acbf2474382f82acd977df2 Node Startup
0.a527ae8c41762a101acbf2474382f82acd977df2 INFO /gazebo [/tmp/binarydeb/ros-melodic-gazebo-ros-2.8.4/src/gazebo_ros_api_plugin.cpp:159(GazeboRosApiPlugin::Load)] [topics: ] Finished loading Gazebo ROS API Plugin.
0.a527ae8c41762a101acbf2474382f82acd977df2 INFO /gazebo_gui [/tmp/binarydeb/ros-melodic-roscpp-1.14.3/src/libros/service.cpp:80(service::exists)] [topics: /rosout] waitForService: Service [/gazebo_gui/set_physics_properties] has not been advertised, waiting...
developer@74bc78790133:~/subt_ws$ cat /home/developer/.ros/log/30518de8-f71c-11e8-bbbc-0242ac110002/
master.log roslaunch-74bc78790133-552.log rosout-1-stdout.log rosout.log
developer@74bc78790133:~/subt_ws$ cat /home/developer/.ros/log/30518de8-f71c-11e8-bbbc-0242ac110002/rosout-1-stdout.log
logging to /home/developer/.ros/log/30518de8-f71c-11e8-bbbc-0242ac110002/rosout.log
re-publishing aggregated messages to /rosout_agg
subscribed to /rosout
developer@74bc78790133:~/subt_ws$ /opt/ros/melodic/lib/gazebo_ros/gzserver -e ode --verbose /home/developer/subt_ws/install/share/subt_gazebo/worlds/tunnel_practice_1.world __name:=gazebo
Gazebo multi-robot simulator, version 9.5.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org
[ INFO] [1543856308.331064687]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1543856308.332066596]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 172.17.0.2
[Msg] Starting SubT
[Msg] Starting SubT comms broker
gzserver: symbol lookup error: /home/developer/subt_ws/install/lib/libBaseStationPlugin.so: undefined symbol: _ZN4subt11CommsClientC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
developer@74bc78790133:~/subt_ws$
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
The https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/tutorials/qual states that qualification ZIP file should contain 2 files, while SubT_Qualification_Guide.pdf says: "A submission will consist of a single zip (.zip) file that contains three files: simulation.log, subt.log, and narrative.md." ... so which one is correct?
Original report (archived issue) by dinesh lama (Bitbucket: roboticsai).
After i run command "X4_SENSOR_CONFIG_4=1 roslaunch subt_example team.launch", the range of the laserscan in only coming less than than 1 as also shown by below screenshot:
This was happening for the X2 robot also when i used command: "X2_SENSOR_CONFIG_3=1 roslaunch subt_example team.launch":
But after i replaced the sensor part of the planar_lidar.urdf.xacro file with below code the range is coming fine for X2 robot:
#!c++
<sensor type="ray" name="${name}">
<pose>0 0 0 0 0 0</pose>
<visualize>false</visualize>
<update_rate>40</update_rate>
<ray>
<scan>
<horizontal>
<samples>720</samples>
<resolution>1</resolution>
<min_angle>-1.570796</min_angle>
<max_angle>1.570796</max_angle>
</horizontal>
</scan>
<range>
<min>0.10</min>
<max>30.0</max>
<resolution>0.01</resolution>
</range>
<noise>
<type>gaussian</type>
<mean>0.0</mean>
<stddev>0.01</stddev>
</noise>
</ray>
<plugin name="gazebo_ros_planar_lidar" filename="libgazebo_ros_laser.so">
<topicName>${topic}</topicName>
<frameName>${name}</frameName>
<robotNamespace>${robot_namespace}</robotNamespace>
</plugin>
</sensor>
But still the range of X4 laser scan is under 1.
I am running system with 8 gb ram, 300 gb free HD, ubuntu 18.04, and ros melodic with gazebo 9 as described in catkin install tutorial of this subt repository.
But im not using any dedicated nvidia gpu, i'm using i5 3rd gen intel cpu.
Original report (archived issue) by Anonymous.
Hello,
When running through the RViz tutorial, I am unable to get the laser scanner data from X2 to visualize. Looking at the topic, it appears that the data is invalid.
Launched with:
roslaunch subt_gazebo competition.launch scenario:=tunnel_practice_1
-and-
X2_SENSOR_CONFIG_3=1 roslaunch subt_example team.launch
rostopic echo /X2/front_scan
---
header:
seq: 456
stamp:
secs: 559
nsecs: 366000000
frame_id: "X2/front_laser"
angle_min: -2.35619997978
angle_max: 2.35619997978
angle_increment: 0.00655410299078
time_increment: 0.0
scan_time: 0.0
range_min: 0.0399999991059
range_max: 20.0
ranges: [-inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf, -inf]
intensities: [1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0]
---
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
Is there a plan to unify names of topics, in particular for robot X3? These are changes from "expected names" to "current names", when we moved from X1 and X2 to X3 (configuration=1):
#!diff
- ["/X3/imu/data", "std_msgs/Imu", "imu_data"],
- ["/X3/front/image_raw/compressed", "sensor_msgs/CompressedImage", "image_data"],
- ["/X3/x3_velocity_controller/odom", "nav_msgs/Odometry", "odom_data"]
+ ["/X3/imu", "std_msgs/Imu", "imu_data"],
+ ["/X3/camera_front/image_raw/compressed", "sensor_msgs/CompressedImage", "image_data"],
+ ["/X3/odometry_sensor1/odometry", "nav_msgs/Odometry", "odom_data"]
According to https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/api it is rather correct for X1 and X2. I am not sure about the odometry, which is not listed in API, i.e. if it is allowed to be used (I hope so).
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
Steve, did you get this?
Original report (archived issue) by dineshlama (Bitbucket: dineshlama).
In final tunnel circuit event, can we use the communication framework provided in this repository or we have to develop or use other networking frameworks like ACE ORB for multi robot communication.
Original report (archived issue) by dan (Bitbucket: dan77062).
Following the tutorial to set up custom controls.
Step 2: Fork the subt_seed repository using this [link] (https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt_seed/fork).
Bitbucket requests a login. I did that but get access denied. Also happens when trying to access the subt_seed repo directly.
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
In order to be sure that X1 robot will be able to communicate with base station we tested return from tunnel ... and the robot fell off through the floor - see video generated from log file. The algorithm was simple follow left wall, turn 180 degrees and return via following right wall.
Original report (archived issue) by Jack Kelly (Bitbucket: jack-kelly).
Because the comms is following a simple UDP-like model and we get no delivery guarantees, it seems strange to set up scoring to punish multiple packet submissions. If the base station communications callbacks (or perhaps just the class itself) were exposed in the same way that the robots are, we could implement handshakes or other delivery guarantees before calling a submitArtifact() function.
Or scoring could be modified to not remove artifacts from the list when a submission is received and instead take the closest each time, possibly replacing an old score on that particular artifact.
Or we could switch to a TCP like comms model with delivery receipts that has rate-throttling instead of the micro level packet dropping modeling that the current model has.
Original report (archived issue) by Phillip Seaton (Bitbucket: pbs5kx).
Hi,
I am attempting to catkin_make install in the custom controller tutorial.
It gives me this error.
#!c++
phil@phil-ThinkPad-T460:~/subt_seed_ws$ catkin_make install
Base path: /home/phil/subt_seed_ws
Source space: /home/phil/subt_seed_ws/src
Build space: /home/phil/subt_seed_ws/build
Devel space: /home/phil/subt_seed_ws/devel
Install space: /home/phil/subt_seed_ws/install
####
#### Running command: "cmake /home/phil/subt_seed_ws/src -DCATKIN_DEVEL_PREFIX=/home/phil/subt_seed_ws/devel -DCMAKE_INSTALL_PREFIX=/home/phil/subt_seed_ws/install -G Unix Makefiles" in "/home/phil/subt_seed_ws/build"
####
-- Using CATKIN_DEVEL_PREFIX: /home/phil/subt_seed_ws/devel
-- Using CMAKE_PREFIX_PATH: /home/phil/subt_seed_ws/devel;/opt/ros/melodic
-- This workspace overlays: /home/phil/subt_seed_ws/devel;/opt/ros/melodic
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.15", minimum required is "2")
-- Using PYTHON_EXECUTABLE: /usr/bin/python2
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/phil/subt_seed_ws/build/test_results
-- Found gmock sources under '/usr/src/googletest': gmock will be built
-- Found PythonInterp: /usr/bin/python2 (found version "2.7.15")
-- Found gtest sources under '/usr/src/googletest': gtests will be built
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.14
-- BUILD_SHARED_LIBS is on
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~ traversing 1 packages in topological order:
-- ~~ - subt_seed
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- +++ processing catkin package: 'subt_seed'
-- ==> add_subdirectory(subt_seed2)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Could NOT find subt_gazebo (missing: subt_gazebo_DIR)
-- Could not find the required component 'subt_gazebo'. The following CMake error indicates that you either need to install the package with the same name or change your environment so that it can be found.
CMake Error at /opt/ros/melodic/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
Could not find a package configuration file provided by "subt_gazebo" with
any of the following names:
subt_gazeboConfig.cmake
subt_gazebo-config.cmake
Add the installation prefix of "subt_gazebo" to CMAKE_PREFIX_PATH or set
"subt_gazebo_DIR" to a directory containing one of the above files. If
"subt_gazebo" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
subt_seed2/CMakeLists.txt:14 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/phil/subt_seed_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/phil/subt_seed_ws/build/CMakeFiles/CMakeError.log".
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
The original report had attachments: rejected-raw-submission.jpg
I am not sure if this forum is the right place to ask questions regarding "Ignition Robotics - Portal": https://app.ignitionrobotics.org/DARPA/portals/SubT
??
... now the first submitted logfile is rejected, but I have no idea (I can guess) why? Is there plan to add some details? Or should we get notification e-mail?
thank you
Martin
p.s. there is also our second submission (still in state "pending") and it is related to both #40 and #39
Original report (archived issue) by Neil Johnson (Bitbucket: realdealneil1980).
The view angle from the camera on the ground vehicles is not optimal for seeing the top of the cave. Are we allowed to change the mounting angle of sensors? Can OSRF give some quick guidance on how to accomplish this? Is it possible to put the camera on a single axis (or multi-axis) gimbal?
Original report (archived issue) by Jon Fink (Bitbucket: jonfink-arl).
Currently the CommsBroker only allows a single client to register per address. That is a reasonable constraint to simplify book-keeping, but currently it will never un-register a client (and there is not an API on the CommsClient to do this).
This means that repeated running of something like the subt_example_node without also restarting gazebo will result in failures like
Logger::Register() error: ID [X2] already exists
Original report (archived issue) by Anonymous.
The rotors package and other dependencies are put into the catkin_ws/install folder. Most of the custom work we are creating is put into the catkin_ws/devel folder (standard practice? from the ros tutorials at least). Can the additional dependencies be put into the devel folder, or can you suggest a work around? Source'ing both the install setup and the devel setup is causing run time headaches.
Or do we need to change all of our cmake files, and if so, can you post a proper procedure for us to follow?
Original report (archived issue) by Neil Johnson (Bitbucket: realdealneil1980).
All of the 4 vehicles are quite limited on speed. As competitors, are we allowed to tweak settings of the vehicles to make them go faster (i.e. pitch limits on the quads, etc.)?
Original report (archived issue) by Jon Fink (Bitbucket: jonfink-arl).
Rather than only allowing the CommsClient to bind to a member function of a class, accept a std::function that can accept a wider range of C++ functionals. E.g.,
bool Bind(std::function<void(const std::string &_srcAddress,
const std::string &_dstAddress,
const uint32_t _dstPort,
const std::string &_data)> cb,
const std::string &_address = "",
const int _port = kDefaultPort)Original report (archived issue) by dinesh lama (Bitbucket: roboticsai).
why is rosrun rqt_gui rqt_gui showing empty screen in my pc? i wanted to send the mav_msg/actuators from the rqt_gui to rotate the motors to test something. but the rqt_gui is not working properly. i have followed the installation tutorial of this page to install gazebo, subt repo and ros all.
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
Yes, I know that you mentioned on https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/tutorials/qual that "This process can take many minutes." ... but hours? Is it really expected? The original simulation was faster (!) and the files are relatively small (original 259MB and the "filtered" after 3hours 27MB). I think that I just missed dead-line even for the west coast midnight ...
Also is it worth it? I understand that smaller the better but the "price" is maybe too high?
I am referring to command:
gz log -f ~/.gazebo/log/2018-12-22T040945.151018/gzserver/state.log --filter .pose/.pose -z 60 -o ~/.gazebo/log/2018-12-22T040945.151018/gzserver/subt_tunnel_qual_sim_state.log
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
Add a gimbal mechanism so that sensors (such as cameras) can be moved.
Original report (archived issue) by Hector Escobar (Bitbucket: hector_escobar).
Hi,
Is it possible for you to provide a tunnel tile that gets narrow in the middle but is wider on both openings?
Thanks,
Hector.
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
Is the 2D laser in X1_SENSOR_CONFIG_1=1 configuration fixed or can be tilted by program? The main motivation is to avoid down-drops: https://youtu.be/jKeVcoSllNk?t=132
(the robot continues, but I suppose that it would be disqualified).
thank you for any hints
Martin
p.s. can Issue by type of "Question"?
Original report (archived issue) by dinesh lama (Bitbucket: roboticsai).
I was following this instructions to visualize image in rviz. but as i types rostopic echo i didn't find any /X2/front/image_raw topic being published. I also added the Image display and set the Image Topic parameter to /X2/front/image_raw but its not working. It looks like this repo is still in progress. Can i ask when will be the robot models be completed so we can use it properly. for example x4 robot don't have camera sensors right now.
Original report (archived issue) by dinesh lama (Bitbucket: roboticsai).
Isn't their pre made controller to rotate laser scanner sensor at particular speed? Can we modify the files to do that? For example for X4 and X3 robot what topics are used to move their laser scanner?
Original report (archived issue) by Neil Johnson (Bitbucket: realdealneil1980).
In our early testing of the RGBD sensor, we noticed that the output of BOTH the depth data and the RGB data is clipped to 5 meters. This appears to be a bug to me. A real RGBD sensor might not get good depth readings beyond 5 meters (we may challenge this limit in the future as well, but not now), but the RGB sensor is just a camera, and it should report data beyond the 5 meter distance.
Original report (archived issue) by Jon Fink (Bitbucket: jonfink-arl).
It seems that the subt_robot_examples_latest.tgz is primarily required to provide binaries for the Rotors Simulator. However, it also contains the old installed state of the SUBT repository. This leads to confusion and causes issues like #20.
It seems like there are a few possible fixes:
Include checkout of the rotors_simulator (and dependencies) source into the catkin workspace used to compile SUBT (modification to the instructions)
Make debian packages for this repo that install to /opt/ros/melodic and distribute them via the OSRF PPA
Provide a more focused tgz that just contains the necessary files (copying these files into the install space of a catkin workspace is still kind of a hack, however..)
Original report (archived issue) by Neil Johnson (Bitbucket: realdealneil1980).
SSCI proposed using vehicles with multiple mobility modes (i.e. vehicles that can travel on ground and in the air). Will such vehicles be added to the available models? If so, we'd like to request that that be done fairly soon so that we can start using them in our simulations.
Original report (archived issue) by dinesh lama (Bitbucket: roboticsai).
I tried to add gimbal mechanism in X4 robot by modifying some x4 robot xacro but i'm always getting msg" Controller Spawner couldn't find the expected controller_manager ROS interface."
In x4_with_sensors.xacro file i added transmission element and gazebo_ros_control plugin as:
#!c++
<xacro:if value="$(optenv X4_SENSOR_CONFIG_4 0)">
<xacro:camera_macro
namespace="${namespace}"
parent_link="${namespace}/base_link"
camera_suffix="front"
frame_rate="20"
horizontal_fov="2"
image_width="1280"
image_height="960"
image_format="R8G8B8"
min_distance="0.02"
max_distance="100"
noise_mean="0.0"
noise_stddev="0.007"
enable_visual="true">
<box size="0.02 0.05 0.05" />
<origin xyz="0.1 0 0" rpy="0 0 0" />
</xacro:camera_macro>
<planar_lidar
name="${namespace}/laser"
topic="${namespace}/scan"
mesh="package://subt_sensors/meshes/sick-lms1xx.dae"
min_angle="-2.3562"
max_angle="2.3562"
min_range="0.5"
max_range="20"
update_rate="20"
/>
<joint name="front_laser_mount_joint" type="continuous">
<origin xyz="0 0 -0.05" rpy="0 0 0" />
<parent link="${namespace}/base_link" />
<child link="${namespace}/laser" />
<dynamics damping="0.7"/>
</joint>
</xacro:if>
<transmission name="tran1">
<type>transmission_interface/SimpleTransmission</type>
<joint name="front_laser_mount_joint">
<hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
</joint>
<actuator name="motor1">
<hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
<mechanicalReduction>1</mechanicalReduction>
</actuator>
</transmission>
<gazebo>
<plugin name="gazebo_ros_control" filename="libgazebo_ros_control.so">
<robotSimType>gazebo_ros_control/DefaultRobotHWSim</robotSimType>
</plugin>
</gazebo>
than i loaded configuration for this joint from a file like:
#!c++
x4_with_sensors:
# Publish all joint states -----------------------------------
joint_state_controller:
type: joint_state_controller/JointStateController
publish_rate: 50
# Position Controllers ---------------------------------------
joint1_position_controller:
type: effort_controllers/JointPositionController
joint: front_laser_mount_joint
pid: {p: 100.0, i: 0.01, d: 10.0}
than i loaded it from a launch file with lines:
#!c++
<node name="controller_spawner" pkg="controller_manager" type="spawner" respawn="false"
output="screen" args="joint_state_controller
joint1_position_controller"/>
Can anyone show me how they did it?
Original report (archived issue) by Zhengqun Koo (Bitbucket: zhengqunkoo).
From 26c6650, subt_robot_examples_latest.tgz was unpacked after catkin_make install. As a result, gazebo throws this error:
gzserver: symbol lookup error: /home/developer/subt_ws/install/lib/libBaseStationPlugin.so: undefined symbol: _ZN4subt11CommsClientC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
Proposed fix: move catkin_make install to after unpacking.
Original report (archived issue) by Neil Johnson (Bitbucket: realdealneil1980).
We've started using the subt system recently, and we've found a few things that we had to do to make things work that weren't included in the tutorials.
First, in the catkin_workspace install wiki page (https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/tutorials/SystemSetupInstall), we had to upgrade the ignition math libraries to get it to compile:
sudo apt upgrade libignition-math2
Also, in the custom control tutorial (https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/tutorials/CustomControl), we had issues getting the subt_seed repo to build and run.
To make it build, we found it easier to clone subt_seed into the subt_ws directly rather than in a separate catkin workspace. Even after doing so, we had to go in the x1.launch file and disable the laser in order for it to run correctly. It complains about not being able to find the laser linkage or something. By turning off the laser and compiling in a common workspace, we were able to get things to work.
Original report (archived issue) by Cameron Ridgewell (Bitbucket: cameron-ridgewell).
Tutorials say to test successful install with lava_tube.launch
#!c++
# Test installation
roslaunch subt_gazebo lava_tube.launch
This file has not made it to the default branch
Original report (archived issue) by dinesh lama (Bitbucket: roboticsai).
laser scanner is only giving -inf range. i placed the robots in different positions, but still the range is only comming -inf .
Original report (archived issue) by Anonymous.
I am not seeing a topic that reports wheel odometry from the ground moving robots. Am I missing something or will wheel odometry really not be available?
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters).
https://build.osrfoundation.org/job/subt-ci-default-bionic-amd64/54/testReport/
roslaunch.RoslaunchCheck.x2_navigation_launch_gmapping_demo_launch Failed with 0 retries
roslaunch check [/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/src/subt/x2_navigation/launch/gmapping_demo.launch] failed
[/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/src/subt/x2_navigation/launch/gmapping_demo.launch]:
cannot find package [gmapping] for node [slam_gmapping]
unable to find node [gmapping/slam_gmapping]: gmapping
ROS path [0]=/opt/ros/melodic/share/ros
ROS path [1]=/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/src
ROS path [2]=/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/install/share
ROS path [3]=/opt/ros/melodic/share
roslaunch.RoslaunchCheck.x2_navigation_launch_include_gmapping_launch Failed with 0 retries
roslaunch check [/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/src/subt/x2_navigation/launch/include/gmapping.launch] failed
[/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/src/subt/x2_navigation/launch/include/gmapping.launch]:
cannot find package [gmapping] for node [slam_gmapping]
unable to find node [gmapping/slam_gmapping]: gmapping
ROS path [0]=/opt/ros/melodic/share/ros
ROS path [1]=/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/src
ROS path [2]=/var/lib/jenkins/workspace/subt-ci-default-bionic-amd64/ws/install/share
ROS path [3]=/opt/ros/melodic/share
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
Is there any plan to replace CommsClient with ROS interface, i.e. that we could "publish" detected artifacts instead of creation of C++proxy?? We are using ROS from Python "externally", which is probably not very common use case :(. Thank you.
Original report (archived issue) by Clark Zhang (Bitbucket: ChickenSoups).
When running the the competition gazebo world (roslaunch subt_gazebo competition.launch) in a docker, this error pops up
gzserver: symbol lookup error: /home/developer/subt_ws/install/lib/libBaseStationPlugin.so: undefined symbol: _ZN4subt11CommsClientC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb
This doesn't happen on commit . (not sure about all other later versions, but at least that version still works)
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
What are the requirement for competition Docker file? My colleague is recompiling ROS in order to have Python3 as default, but then he looses SubT compatibility, correct?
Original report (archived issue) by Anonymous.
https://osrf-migration.github.io/subt-gh-pages/#!/osrf/subt/wiki/tutorials/SystemSetupInstall
Has error in that a space is missing from the recipe for installation. In particular
#!bash
sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu-prerelease`lsb_release -cs` main" > /etc/apt/sources.list.d/gazebo-prerelease.list'
should be
#!bash
sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu-prerelease `lsb_release -cs` main" > /etc/apt/sources.list.d/gazebo-prerelease.list'
Original report (archived issue) by dan (Bitbucket: dan77062).
I understand that the simulated imu has a noise model and I see the parameters for that. However, I don't understand what the topic imu/data/bias is reporting. Also, will the imu model ever use noise with a dc offset? At the moment, it looks like the Gaussians all have mean = 0, so there is not a constant drift.
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters).
When test-driving the example robots in the tunnels, I spawn them with subt_example team.launch and then delete a few of them to speed up the simulation. I've noticed that gazebo seg-faults when I delete a model that has a gazebo_ros_gpu_laser plugin. I collected a backtrace after installing gazebo and gazebo-ros debug symbols and uploaded it to the following gist:
https://gist.github.com/scpeters/ff2e25b8c07a9cecbd2e10110b07a538
cc: @jchoclin
Original report (archived issue) by Martin Dlouhy (Bitbucket: robotikacz).
How should the controller recognize that the message was not delivered to Base Station? So far we expected that the return value corresponds to success delivery??
Again the qualification world, extinguisher around (157, 138, -15) - I suppose that it should fail to send the message directly, right?
But it returns true and Base Station did not receive anything:
ESC[0m[ INFO] [1545474534.274922683, 483.680000000]: MD SendToBaseStation
ESC[0m
ESC[0m[ INFO] [1545474534.274977079, 483.680000000]: MD x157.02ESC[0m
ESC[0m[ INFO] [1545474534.275003980, 483.680000000]: MD y138.06ESC[0m
ESC[0m[ INFO] [1545474534.275016511, 483.680000000]: MD z-15.33ESC[0m
ESC[0m[ INFO] [1545474534.275180002, 483.680000000]: MD SUCCESS
Original report (archived issue) by Cameron Ridgewell (Bitbucket: cameron-ridgewell).
"Refer the system setup tutorial." leads to nonexistent page
Original report (archived issue) by Anonymous.
I'd like to be able to set the sensor config environment variables in my team launch file. I've tried using the tag inside the tag for spawn_x*.launch, as well as other places in my team.launch file (which is just a single x1 with joystick control at the moment), but I haven't found a place to put it that changes the default sensor config value in the x*.urdf.xacro for the robot.
The tag wiki page only mentions the tag values not being seen by
One concern I have with this approach is that in the competition, different sensor configurations may have different "costs", so we may want to use multiple copies of the same robot with different configurations. So it would be really nice to be able to specify which config goes with which agent when setting up our team.launch file. It would also be nice to be able to experiment with different sensor configurations in different teams using varying values within the launch file instead of having to change the command line call every time.
Thanks
Original report (archived issue) by dan (Bitbucket: dan77062).
Trying to run the custom control example. The sim launches OK.
And x1.launch runs as long as the parameter
laser_enabled is set to false If it is set to true then this error occurs:
process[X1/spawn_x1_model-6]: started with pid [4455]
[ERROR] [1538532710.572949170]: Failed to build tree: child link [X1/base_laser_mount] of joint [laser_mount_joint] not found
It also fails if the parameter kinect_enabled is set to true In that case, this error is generated:
process[X1/twist_mux-5]: started with pid [4733]
[ INFO] [1538533048.515356940]: [twist_marker_server] Initialized.
[ERROR] [1538533048.522391765]: Failed to build tree: child link [X1/camera_link] of joint [kinect_frame_joint] not found
Looking at the tf tree when running without the laser or the kinect shows a disconnected tree. There is an odom ->base_link transform published by /X1/ekf_localization and there is a full tree published by /X1/robot_state_publisher that starts with X1/base_link but there is no connection between base_link and X1/base_link
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.