DAPRA organizes training rounds called STIX (SubT Integration Exercise), where
the first one is in April 2019 in Colorado. Although the STIX is for System
Track only we plan to work simultaneously also on Virtual Track. This is
English blog for the next three months … Update: 14/2/2019 —
Return strategy ver1
23rd January 2019 — official announcement
Last night there was an official DARPA announcement of qualified teams for STIX
(SubT Integration Exercise):
It was definitely worth it, although there were so many failures starting with
dead battery in the car, bad contact number, dead battery in my camera (I am
used to that one, so I had spare), but also dead Eduro computer, which I really
did not expect and I did not have backup. Next time. It was also freezing and
the entrance was decorated with jaw-like stalactites.
The tunnel was very nice and it could surely imitate Edgar's mine in
Colorado. It was actually too nice (during summer it is open for public), the
rails were below floor surface or covered by stones, clean, dry. We learned
that dripping water is typical as well as mud or small pools.
The teams for STIX in April 2019
already received a list of five selected artifacts, which will be used. They are
grouped into common artifacts for all three events (Tunnel, Urban, Cave)
and event specific.
This selection is good for us — our qualification video used trained network
for backpack, person/survivor and fire extinguisher. The processing was
relatively slow, so we may start with „detect red pixels” as our first
submission to Virtual Track.
28th January 2019 — Virtual Track - narrow passage
There is a very narrow passage in the virtual environment of qualification
world. It is on the left side behind the fire extinguisher (our first
successfully reported artifact). Yesterday I placed robot X2 at -x 158 -y
139 -z -14.8 in order to examine LIDAR data and check if the passage is
passable with the wheeled machine … and it is!
The robot actually went through, turned right and followed the wall until it
has seen red backpack, and because I did not change the strategy, it turned 180
degrees and tried to return to the original start position (via measuring
distance traveled). The way back did not work. After 3.5 hours of simulation I
could see on terminal that the pose did not change:
The position was at the entrance to narrow passage but on the other side. It
seems to me that it is asymmetric, and there is different slope on the left and
on the right side of the entrance.
Another reason could be simulation timeout (20 minutes of simulated time),
because I had to change distance to the wall from 1.5 meters to 0.8 meters and
so the robot moved automatically slower.
Finally a detail, which I realized this morning … I did not change the
parameter for wall following for the way back so it would not pass through
anyway … I guess.
Note, that the surface is variable 3D terrain so to properly decide what to do
with 2D lidar scan only is a challenge:
1st February 2019 — Eduro and Robík testing at home
We did a couple of test of Eduro and Robík robots at home. I took Eduro to dark
basement, where are many storage places and narrow passages and PavelS repeated
tests with osgar.go1m code to verify OSGAR driver functionality. Both log
sets are available for download:
(my bad with the zip file name for Robík, should be 190129 as log files inside).
If you would like to visualize the data you can use osgar.tools.lidarview
which now provides visualization of scan, pose2d and lidar data
It did not work very well (probably no surprise). The entires were too narrow
so Eduro decided to turn around instead. What was worse it stopped in the
corner without further activity — that has to be fixed (we probably have
similar issue in the Virtual Track).
Test of Robík was slightly better. We learned that it is necessary to wait
for LIDAR until the rotation speed stabilize and data with orientation are
ready. Also ramping the speed was not properly working in the low level SW, so
we may need to add wrapper in OSGAR driver. Tonight we plan to test and
integrate OpenCV driver for camera
(#134) and then we should be
ready to use the same high level SW for both our SubT robots.
3rd February 2019 — STIX Group Assignments
Yesterday we received e-mail STIX Group Assignments. where my first
reaction was „proč zrovna my jsme Béčko” (why we are the B-team), inspired by
Cimrman/Posel z Liptákova. We decided to buy plane tickets on 31st January,
because we were warned that it was Lufthansa action price and it will change on
1st February … and it went up by 5000 CZK, but … never mind. I no longer
complain that we will test in Colorado with the second Czech team CRAS … it
could be fun.
DARPA has selected seven teams to compete in the funded track of the Systems
Carnegie Mellon University (Explorer)
Commonwealth Scientific and Industrial Research Organisation, Australia (CISRO)
iRobot Defense Holdings, Inc. dba Endeavor Robotics (CRETISE)
Jet Propulsion Laboratory, California Institute of Technology (CoStar)
University of Colorado, Boulder (MARBLE)
University of Nevada, Reno (CERBERUS)
University of Pennsylvania (Pluto)
… so it is 7 sponsored teams + 2 Czech teams … hmm … interesting.
The Carnegie Mellon team, including a key member from Oregon State
University, is one of seven teams that will receive up to $4.5 million from
DARPA to develop the robotic platforms, sensors and software necessary to
accomplish these unprecedented underground missions.
7th February 2019 — OSGAR v0.2.0 Release
Yesterday we released OSGAR v0.2.0. It
contains all HW drivers necessary for both Eduro and Robík robots and new
osgar.tools.lidarview for log files analysis and debugging. There are also
several small features like base class Node for easier creation of new
nodes and drivers, environment variable OSGAR_LOGS for definition of logs
storage place, and launcher for faster application prototyping.
From the programmers point of view LogReader is now directly iterator
so it can be used as file open():
for timestamp, stream_id, data in LogReader(filename, only_stream_id=LIDAR_ID):
There were also couple of tweaks motivated by SubT Challenge, primarily by
Virtual Track. As the simulation can take several hours there is a fix for time
overflow (resolution in microseconds, the limit used to be 1 hour). Also TCP
driver now supports various options necessary for communication with ROS. The
release of node ROSProxy implementation was postponed to the next release,
mainly with the goal to simplify necessary user configuration.
You can use 'c' to flip camera on/off, +/- for zooming and SPACE for pause. A
simple map from point cloud is displayed in camera off mode.
9th February 2019 — Virtual Track - two X2 robots
Last night we run simulation with two X2 robots (small and fast ground
vehicles). There was a need for small tweaks to run OSGAR ROS Proxy in two
instances (extra ports) but at the end it worked! And it was definitely
more interesting to watch than TV … but everything is, so no big deal.
The strategy was simple: one robot (X2L) followed the left wall while the
other (X2R) followed the right wall. The code was identical to version
0 — follow the wall until you find an artifact, turn 180 degrees and follow
the other wall for previously measured distance. This way the robot should
return close to starting area and report to Base Station should be
After few screenshots, I went to bed … and one robot finished simulation in
almost 3 hours, while the other in 5 hours. Both were convinced to reach the
start which was not quite right in the reality … and now it is time to review
the log files.
Well, the left robot went fine except when it reached the start area the
entrance was detected as wall (maybe bug in the world?) and returned couple of
meters. But the base station was close so the report was delivered
The right robot „overlooked” the valve artifact and continued to red
backpack. But it did not make it back probably due to simulation time timeout
On the generated map you can see that the integrated error is not too big,
approximately 1 meter, and thus it is sufficient for report with 5 meter
BTW why are we „wasting time” with virtual track when we have sharp
system track deadline?! Well, we will probably use the same or very similar
strategy and because the robots are not here at the moment, we can at least
prepare for virtual track qualification (locate 8 artifacts in 20 minutes
of simulation time by the end of April 2019).
p.s. after Jirka parameter tuning both robots returned to the start area, but
… somehow it looks like they „hit the wall”
Note, that X2L simulation took only 47 minutes to return with artifact
position while X2R timeout in 6 hours!? Well, the X2L went straight
until classified the other robot as an artifact and returned home.
We played with artifacts classification over weekend and when we tried to replay
detection of fire extinguisher it failed:
M:\git\osgar\examples\subt>python -m osgar.replay -module detector subt-190208_200349.log
b"['subt.py', 'run', 'subt-x2-right.json', '-note', '2x X2_SENSOR_CONFIG_1, rig
ht, commented out asserts for name size']"
['app.desired_speed', 'app.pose2d', 'app.artf_xyz', 'detector.artf', 'ros.emerge
ncy_stop', 'ros.pose2d', 'ros.cmd_vel', 'ros.imu_data', 'ros.imu_data_addr', 'ro
s.laser_data', 'ros.laser_data_addr', 'ros.image_data', 'ros.image_data_addr', '
ros.odom_data', 'ros.odom_data_addr', 'timer.tick', 'tcp_cmd_vel.raw', 'tcp_imu_
data.raw', 'tcp_laser_data.raw', 'tcp_image_data.raw', 'tcp_odom_data.raw', 'ros
msg_imu.rot', 'rosmsg_laser.scan', 'rosmsg_image.image', 'rosmsg_odom.pose2d']
Exception in thread Thread-1:
Traceback (most recent call last):
File "D:\WinPython-64bit-188.8.131.52Qt5\python-3.6.2.amd64\lib\threading.py", line
916, in _bootstrap_inner
File "M:\git\osgar\osgar\node.py", line 40, in run
File "M:\git\osgar\examples\subt\artifacts.py", line 42, in update
channel = super().update() # define self.time
File "M:\git\osgar\osgar\node.py", line 32, in update
timestamp, channel, data = self.bus.listen()
File "M:\git\osgar\osgar\bus.py", line 81, in listen
channel = self.inputs[stream_id]
Hmm, that is really strange — there was no artifact reported at that time?!
Note that record & replay is the key feature in OSGAR: you record your
logfile as the robot navigate and later, typically on your notebook, you can
analyze various situations „what happened?”. The prerequisite is that the
replay is identical to original run. In this particular example the simulation of
SubT Virtual Track was on different notebook with Ubuntu and ROS.
The simplified artifact detection is split into two phases:
search for sufficiently red objects
if you find local red maxima run classification
So what happened was that the redness of the JPEG compressed image was
different on each machine. If we classify pixels as RED then their count
It is yet another detail you should check before you deploy the code on the
target machine. Surprisingly newly added unit tests for counting red pixels
in uncompressed JPEG image pass on machine with GPU support (our primary
This has to be investigated and we surely have to check also installations on
Eduro and Robík robots.
And one joke at the end: this is recording from the run when two X2 robots
met. You would guess that they are blue, but they are obviously not.
p.s. note, that these are 1:1 output images from ROS simulation, topic
/X2/camera_front/image_raw/compressed with X2_SENSOR_CONFIG_1 and
But the Base Station did not accept it for some reason, so it is still work
in progress, again.
Last night we also discussed the faster return strategy. Current version 0
simply follows the wall back for given distance traveled. This means that if
there is some dead-end branch robot will go there and repeat the same
In version 1 we plan to use shortcuts: There must be a pose from the way
there (if not you are already at the start), so pick the nearest/oldest one
within given radius (say 2 meters). The odometry corrected from IMU should be
good enough (must be for the basic mapping of the artifacts) so it could help
the robot navigate back. Moreover we may use VFH (Vector Field Histogram) for
navigation to avoid potential shift and the old poses would define direction
how to return HOME with the shortest path, right?
Do you like it? Do you see some weak point? Well, do not worry, we will share
it with you as we „hit the wall” …
p.s. note, that this strategy can be used for both Virtual as System Track