The DARPA Subterranean Challenge is headed to Pittsburgh for the Tunnel
Circuit, the first scored Challenge Event, in August from the 15th-22nd.
Qualified teams will attempt to navigate a former operational mine in
Pittsburgh, PA. … Update: 14/7/2019 —
Updated Tunnel Rules and Operations Guide ... (18/32 days)
5th May 2019 — Here we go again … (102 days)
Well, there was not enough time for rest, I would almost say None!
Yesterday (maybe two days ago) DARPA announced the date and location for the
SubT Challenge Tunnel Circuit Announcement (note, that you have to be
registered in order to see it). Beside the paragraph above there were details
about the mine and link to „motivation video”:
As part of the National Institute for Occupational Safety and Health (NIOSH)
Mining Program, testing in the research mine contributes to advances in
mining industry practices. In August, the mine will serve as the arena for
the SubT Challenge as teams compete to accurately map, identify, and report
the greatest number of artifacts along the mine passages.https://youtu.be/un90P_Pa1F0
When compared to STIX in April we are now
working on NINE platforms! … yes, that is totally crazy and I am quite
aware of the Second-system
effect. I suppose that by the end of May we will reduce this number to
half, and what survives will be duplicated for the trip to U.S.
Note, that there was a relatively long „prelude” period, which you can read at
Prelude (both in Czech) and about
STIX in Colorado.
8th May 2019 — Kloubák — the student's platform … (99 days)
Yesterday I witness the very first motion test of new platform Kloubák (in
English „Jointer”, maybe). It was great to see the students at
the university (CULS) at work to finish the
minimalistic version to see the robot moving. Yes, we argued a lot, that they
should do it even simpler, but now it works, so I am happy.
There is an outdoor competition Robot go
straight in 3 days, on Saturday April 11th, so there is not enough time left.
Now there are two sets of power cables for BLDC motors to be controlled by two
(of four) vESC drivers.
I must admit, that the development was so far quite rapid (especially if you
take into account that some students have to finish their thesis, others are
working full time, etc.). The initial step did Jakub, sent his sketch what he
would like to build (mail dated April 20th) and the next weekend together with
Standa they build and weld the frame.
12th May 2019 — Kloubák at competition Robotem rovně … (95 days)
The robot „Kloubák” (articulated robot) went to its first competition
Robotem rovně (Robot go straight!) in Písek. It was the first milestone for
all platforms but only Kloubák and the CZU subTeam managed to get ready.
The central joint was fixed in order to simplify the robot control and it
helped. The robot reached 78 meters, and sure enough the students also tried
some terrain tests — so far it looks like the robot survived.
If you would like to see the wet video from Písek,
here it is.
15th May 2019 — LORD 3DM-GX5-25 sensor … (92 days)
There are a couple of small notes I wanted to write down, primarily for me and
my colleagues, but it could be useful for other teams too. One of them is
description of the first steps with new 3DM-GX5-25 sensor, which we received
from supporting LORD company.
The sensor is small (approx 2x3cm) and comes with two cable options: USB and
RS232. USB has advantage of power source while in case of RS232 you have to
provide it extra … but RSR232 is often more reliable and easier to integrate
in small embedded devices. So far I tried the USB cable option on Windows 7
First of all you will need to install driver otherwise the 3DM-GX5-25 device is
not recognized. The next step is to install
MIP Monitor for configuration and
visualization of data. I would recommend it because by default is the sensor
silent, so you have to talk to it first in order to receive any data.
In order to integrate the sensor in
OSGAR library I had two
checksum did not match
selected types of messages had to be configured after boot-up
Thanks to great support from Barry both issues were quickly sorted out. The
checksum is computed in two separate bytes and both are stored (see
Setting the configuration was more tricky — you have to switch also sensor to
running mode before you save the configuration! It make sense, as by default you
may want to change parameters before getting loads of data.
Here are the instructions:
MIP Monitor allows you to write your settings to the 3DM-GX5-25 non-volatile
By following this method, each time you power up the inertial sensor, the
settings will automatically actuate without any intervention by the host
As an example:
Launch MIP Monitor software and connect to the 3DM-GX5-25 as normal.
Click once on the 3DM-GX5-25 Model/Serial/etc. readout to highlight it.
Click Load Default Settings and a confirming message box appears.
Click OK and the message box disappears.
Click Device and the Device Setup window appears.
Click the Estimation Filter tab.
Click the Message Format sub-tab.
Select Attitude (Euler RPY) in the drop-down.
Select 100 Hz in the drop-down.
Click OK and the Device Setup window disappears.
Click Save Current Settings and a confirming message box appears.
Click OK and the message box disappears.
Click Exit and MIP Monitor closes.
Unplug the power to the 3DM-GX5-25.
Plug the power back into the 3DM-GX5-25.
Note that after a few blips of the green LED, the LED will begin blipping
rapidly, indicating that the 3DM-GX5-25 has initialized, and is now outputting
100 Hz Euler angles.
Barry also suggested hints regarding calibration and Auto Adaptive functions
… but I would postpone it when the sensor is mounted on the robot (which is
unfortunately not yet, and that would require another „report”).
Remote Emergency Stop (E-STOP) is one of the requirements for all robots
participating in SubT Challenge. DARPA has kill switch, which stops all
robots by broadcasting special command. All robots have to stop within 30
seconds and they have to demonstrate this behavior as a part of qualification
The communication is based on
Pro 900HP radio module mounted on a SparkFun XBee
Explorer USB carrier board. The receiver operates on the 900 MHz ISM band,
which is problem in Europe (???) and it is probably the reason why it is so
hard to buy the specified device. For detail information see:
There are two options how to interface the E-STOP module. One is just to power
the board and use dedicated pin to trigger stop action. Alternative is to power
the board via USB port and talk to it. We used the second option at STIX in
Colorado — it was easier to integrate it into
OSGAR without HW modifications and beside
reset command (in the first option you have to power off the board once kill
switch was used) we could also use the board as transmitter, i.e. test and
demonstrate the functionality on our new platforms.
The binary communication protocol is still unknown for me — there is
obviously length of packet, address, checksum at the end, but what are the
internal codes I do not know yet (any hint is welcome). So short summary of
listed commands in DARPA specification:
7E 00 04 08 01 49 53 5A
query command to the XBee to get state of all enabled digital and analog pins
7E 00 0B 88 01 49 53 00 01 00 02 00 00 00 D7
XBee reponse in normal operation
7E 00 0B 88 01 49 53 00 01 00 02 00 00 02 D5
Emergency STOP also visible on DIO1 pin in HIGH state
7E 00 05 08 01 44 31 04 7D
Reset module — switches DIO1 to original state
7E 00 05 88 01 44 31 00 01
DIO1 Reset Success
7E 00 10 17 01 00 00 00 00 00 00 FF FF FF FE 03 44 31 05 6F
Master kill stop command (published on SubT community forum)
So is the protocol clear? It looks like the prefix is either 7E or 7E
00 depending on the size of length byte/word (8bit or 16bit). Then there is
the payload and one byte checksum.
22nd May 2019 — 11 teams qualified for Pittsburgh! … (85 days)
There are 11 teams successfully qualified team for the Tunnel Circuit/System
Track in Pittsburgh — see the
official DARPA announcement.
You already know 9 of them from SubT STIX
blog: 7 DARPA sponsored teams, CTU-CRAS and Robotika Team.
So who are the 2 new teams?
NCTU: National Chiao Tung University, Taiwan
The DARPA announcement also contains teams currently qualified in Virtual
Track — there are 5 teams including Robotika (our score did not change
since successful 8 points submission
on 14th March 2019, and we focused on STIX and new platforms and sensors for
System Track in mean time).
Originally I wanted to claim, that „we are the only team participating in both
competition categories”, but it is not true. The other team is already
mentioned Coordinated Robotics surely leading by Kevin Knoedler. You can
lookup his history and it is quite impressive:
https://spectrum.ieee.org/automaton/robotics/robotics-software/coordinated-robotics-winner-nasa-space-robotics-challengeThe winner of the SRC was team Coordinated Robotics, which also was the only
team to manage a perfect run with 100 percent task completion, taking home the
US $125,000 top prize plus a $50,000 “perfect run” bonus. “Team” may be a
little bit of a misnomer, though, since Coordinated Robotics consists entirely
of one dude: Kevin Knoedler. We spoke with Kevin about his epic win, and also
checked in with Nate Koenig from Open Robotics, which leads the development of
Gazebo and helped organize the SRC, to get more info on the competition, along
with footage of all the best outtakes.
The updated competition schedule is on resources pages:
(rev2). Based on this document the contest will be for all teams for the
whole week (from Aug 15th to Aug 22nd) and there will be four competition
Our goal is surely to win , but realistically to finish in the first
„smaller half”. According to the rules the first 5 places should be awarded
by prices, and somebody has to pay the bills … Virtual or System? BOTH
Wish us good luck — the tunnel is coming in less then 3 months …
30th May 2019 — Freyja, MOBoS and TIM881P … (77 days)
There were couple of „small” updates last week. First of all
shared the picture of new 4WD robot Freyja:
next born is robot MOBoS (commercially available platform MOB
„on Steroids”). PavelJ started from base he used on
Robotour 2010 (see the old picture) as it
could be a nice toy to test algorithms for bigger robots. But … it turned
out that 3 of 4 motors are somehow corroded, their power is not sufficient, the
wheels are too small in order to have at least some clearance … so PavelJ
bought stronger motors, bigger wheels and as the motors were slightly larger
then original box he decided to print its body.
The result is say impressive (take into account that this all was done within a
week?) and with NVidia Jetson Nano as the main computer and RealSense as the
mapping sensor we may expect cool tricks. Because of that we decided to create
separate article — see MOBoS photo-story.
There has been also some progress with articulated robot Kloubák, but it is not
ready yet. Last Tuesday we tested new sensors TIM881P from
SICK. You would not be probably able to find
anything, I guess, as these are new programmable prototypes. They combine
laser rangefinder technology (270 degrees field of view, 1/3 degree resolution)
with processor dedicated to user application. You can add extra data filtering
already on the sensor, provide alternative communication protocol or program
simple behavior directly controlling effectors.
7th June 2019 — 2nd testing in tunnel Josef … (69 days)
Yesterday Zbyněk, Jakub, TomášP and me tested robots Robík, Eduro and Kloubák
in tunnel Josef. Two of us (and
also two of robots) were there before, but nevertheless it was good exercise.
We were not prepared — surprise, surprise?? I may use excuse that the test
was planned by competitor team CRAS and
we just use this opportunity to meet and test our robots too, but … no, we
were not prepared.
Robík had slightly different configuration where the slope lidar was pointing
back with a plan to test scenario there and back again without turning,
i.e. return to tunnel entrance with backward motion. The code was not ready and
the new fish-eye camera generated cryptic message No space left on device.
If you would think that it was because of too much log files on the disk you
would be wrong. The reason, as Zbyněk later found out, was that the bandwidth
of USB does not contain enough „space” for newly connected device. The camera
runs at 120Hz and by default estimates the need based on plain data. In reality
it sends JPEG images, i.e. much much less. After some workaround it generated
tons of error/warning messages, so it is still issue to be resolved.
Kloubák was in the state as on Wednesday test: „Ahoj, udělali jsme s TomášemP
narychlo pár testů go1m přes prkno (cca 2.5 cm). Nepřejede.” Well, this report
made me quite angry, but what could I do. Also the IMU was not recognized by
embedded PC, and what showed in the tunnel, that even USB camera did not work!
Really really bad. So instead of testing in the tunnel we started to overcome
2.5cm board obstacle. The limit for motor current was removed (increased from
16A(?) to 75A), current from batteries was increased from 4A to 8A. The vESC
messages were still strange — they should report current but even when the
motors were blocked the current was only around 300mA?! We increased
the control current to 20A, and the robot finally overcame the obstacles.
You can see the evolution in the videos: limited
current, down and up hole test,
wheel in hole recovery and
meeting Husky robot.
Eduro was taken as „backup robot” and because the charger for Kloubák was
broken and there were no spare batteries it was time to collect some data with
the old tricycle. And it run through the tunnel nicely showing that it is actually
simple environment. Yes, it got stuck many times too, typically large (means
10cm high) rock, where insufficient clearance showed up. The CRAS team did also
some tests with fog, and it was funny trap for Eduro. We put it in the blocked
corridor and went in larger and larger circles as the vapor slowly
and it looks like there are new competitors and we end up on 9th position! My
colleagues would surely argue that it is actually 4th-9th position as all
these teams have qualification minimum of 8 points.
There is a progress in the sense that there is a new dedicated machine for
simulations. But as I read the issues I am not sure if we should invest the
precious time now:
the new simulator working for anyone?: We have been trying for the last two
weeks to get the new version of the subt simulator working (ignition). We have
tried on many different machines, and so far, we cannot figure out how to
connect to the agents and drive them around in the team.ign file. Has anyone
gotten this working on the new ignition system? It appears that the effort to
get our system ported from the gazebo9 system to the ignition system is going
to quite burdensome, but we can’t even start that yet because the simulator
doesn’t run for us.
I wonder if we should wait one more week as it will probably not be trivial to
port the code to the new ignition engine. BTW there are only 9 weeks left.
Yesterday we visited Chrustenická
šachta (iron ore mine in village Chrustenice). It used to be one of the
biggest mines in the area west from Prague. It had 84 underground floors
reaching depth of 426m, which means 120m under the sea level! During the
hundred years of operation (1861-1965) there were extracted over 8 millions of
tons of iron.
Our guide was Miki Dobrý, who is behind the project to made this huge human
creation available to general public. The exposition is around 1km long, mostly
on the 8th floor, and on the way back you take the mine train. Very nice even
for family with kids.
We have not seen other deeper floors because they are flooded by acid water.
Imagine the incredible amount of this liquid! Yes, Miki had many great stories
including one related to future tunnel from Prague to Beroun, which should be
on the other side of the valley, but the mines underground are connected so
this water will surely cause problems … we will see, maybe. If I would ever
build an autonomous submarine then this would be the place to explore!
OK, so that was the nice part of the hot summer day, when we could practise in
the 8 degrees Celsius of the tunnel. So now the bad part. Our robots were not
prepared, I mean they would not be able to handle this tunnel even if they would
be more ready. We had three of them: Robík, Kloubák and small MOBoS. PavelS
wanted to return back home soon due to expected bad weather conditions (storm
and hail), so Robík did only quick test there an back and that was it. :-( I
would like to see the log files when available.
Kloubák was surprisingly in similar bad condition as last week in tunnel Josef.
The batteries were not fully charged and it was probably 75% source of the
driving issues. There were other discoveries: the translation Arudino board
between standard and extended CAN addresses lost some messages as the control
computer (APU) start to send commands. All four
motors talk at 100Hz and they also receive commands at 100Hz, which is probably
not necessary. It turned out that sometimes vESC
motor driver did not talk for the first 5s! Why? During restart we observed
that some were booting maybe two minutes, was this the case?
What was probably the biggest surprise was test in the tunnel (when batteries
were at least partially charged) and it showed that the wet air makes really
the difference! It was comparable to fog test in Josef, just here it was
It is funny that the real wall on the right is clearly visible but the ghost
surely wins and Kloubák wants to turn around.
And finally there many issues with USB, on all robots. Zbyněk managed to run
multiple cameras on his notebook, but I am not sure if that was also case of
robot Robík at the end. PavelJ fight with combination of USB3 needed by the
latest RealSense sensor on MOBoS (BTW two days ago he finally solved the
issue RealSense on NVidia Jetson Nano, so he was able to at least collect some
data in Chrustenice mine), and it did not work well with remote control and
badly jammed WiFi communication dongle. And Kloubák had problém with IMU on
boot, which is not necessarily related to power, as we thought on Tuesday, but
to old kernel?? IMU was talking to us but the data were constant … to be
30th June 2019 — Kloubák and Freyja qualified, MOBoS pending … (46 days)
The robots Kloubák and Freyja are finally successfully
qualified for Tunnel Circuit! The video for MOBoS
PavelJ recorded at 3am and it is still in „pending state”. Officially the
robots qualification terminates tomorrow, July 1st 2019.
Tomorrow also starts the Virtual Track: The solution submission window for
the Tunnel Circuit will opened on 1 July 2019 and will close on 1 August 2019.
The submissions will then be evaluated and the final results will be announced
alongside the Systems Competition results on 22 August 2019.
DARPA also released preview of NOSH tunnel, where the robots will compete in
11th July 2019 — Freyja and Virtual Nightmare … (21/35 days)
More than two months ago I was going to write a small report named Ender's
Game and Ignition Acropolis Release. By that time I was re-reading
Ender's Game (successful
sci-fi) and I was wandering why it so nicely correlates with SubT in my mind?
I tried to update my linux machine in order to match the latest
Ignition Acropolis Release and
then I realized what is the common feature … the teachers are the enemies and
they can change the rules and the Battle Room at any time.
While in the real world (System Track) you have to face the real problems:
connectors are not properly tight, batteries are dead, the water damaged some
boards, in the virtual world anything can happen. It is not only the basic
task, which is not trivial by the way, but you are fighting with alpha version
of the simulator, dynamically changing API and the core SW is still "under
development" even in the middle of contest period (ends on 1st Aug 2019).
The easy solution is to give up. There are 10 teams which passed the 8 artifact
qualification limit in former Gazebo 9 — I doubt that any team used the
Ignition version as it is still unusable. I must admit that it is very pity as
originally we used virtual world as practice area for SubT exploration and
mapping algorithms, but now it slowly turns into time and energy demanding
… so here are at least some good news from the real world — see Cogito's
robot Freyja driving through narrow corridors, including door video with all
sensors and map overview:
14th July 2019 — Updated Tunnel Rules and Operations Guide … (18/32 days)
The rules were updated yesterday (unfortunately on the community forum only …
hopefully they will propagate to
resources soon) —
SubT_Challenge_Tunnel_Rules_Rev3.pdf. Probably the most important change
is regarding the gate entrance. There will no longer be special frame, as it
used to be in STIX in Colorado, but the real tunnel portal will be used:
Also the detailed measures were published so when combined with the
preview DARPA video, you can get better idea
about the dimensions.
In the Operations_Guide_Tunnel_Circuit_Revision_3.pdf is preliminary
schedule of the competition days. The 11 teams will compete four times,
twice in each tunnel, and the better score from both attempts will be taken
into the final sum: For the Systems Teams, the final ranking in the Tunnel
Circuit will be determined based on the sum of a team’s top score on each
competition course. The highest scoring run on the Safety Research course will
be added to the highest scoring run on the Experimental course.
Other then that there is not much happening. The virtual world is unusable even for the simple
which looks like is related to extremely pure simulation speed. At least
Sophisticated Engineering UG confirmed that in virtual_stix the robot
can move but not in the other worlds. Hardly worth of comment. :-(
There is at least
schema, how the
simulation should look like available: