czech english

SubT Tunnel Circuit

Robotika Team

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 real compettition: DARPA 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.
I guess that there will soon also official announcement with the list of qualified teams.
The Virtual Track is going to run in parallel. Note, that the deadline was extended to 10th of June 2019. The score board never-the-less still looks the same:
Robotika and two other (probably DARPA funded) teams are qualified and 13 teams are still with zero points … but they have 6 more weeks to go …
There were are some minor changes like we renamed team from to Robotika and made visible all our subTeams (including newly created spin-offs):
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.
Moreover there are new toys: inertial sensors from LORD, programmable laser scanners TIM-P from SICK, and older 3D scanner from Pulu Robotics.
Note, that there was a relatively long „prelude” period, which you can read at Rules and 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.
Later we found ARTI platform developed by Segway back in 2012, so the plan is something similar.
p.s. this Jointer prototype should serve two goals: SubT and also as an autonomous robot in the field
p.s.2 and here is small video proof

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 only.
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 problems:
  • 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 Fletcher Checksum Algorithm).
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 Settings.
    Click Load Default Settings and a confirming message box appears.
    Click OK and the message box disappears.
    Click Settings.
    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 Control.
    Click Run.
    Click Settings.
    Click Save Current Settings and a confirming message box appears.
    Click OK and the message box disappears.
    Click File.
    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.
It works.
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”).
p.s. I forgot the most important thing: 3DM-GX5-25 manual

21st May 2019 — DARPA E-STOP … (86 days)

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 procedure.
The communication is based on XBee 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.
>>> b = bytes.fromhex("7E 00 04 08 01 49 53 5A")
>>> hex(sum(b[3:-1]))
OK, so at least the checksum is easy.

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?
  • Coordinated Robotics
  • 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:
  • The 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.
But that was just the recent victory. Kevin has history even to very well known Grand Challenge 2005 where he participated in SciAutonics team (see Google Books) and later also in Urban Challenge 2007post from Oct. 28, 2007.
The updated competition schedule is on resources pages: Operations_Guide_Tunnel_Circuit.pdf (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 runs.
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 OBVIOUSLY!
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 Cogito Team shared the picture of new 4WD robot Freyja:
It is „a new baby” loaded with 4 cameras, stereo vision and enough power to carry a human. The next step is finish cabling and exercise the first motion steps say within a week.
MOB 9 years ago
MOB 9 years ago
The 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 disappeared…

12th June 2019 — Virtual Track - starting from 9th position … (64 days)

Last night I checked the SubT Challenge Virtual Testbed Portal for current Leader Board (the postponed dead-line was June 10th, so the list of participants in virtual world should be final):
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: Is 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.

16th June 2019 — Churstenická šachta … (60 days)

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 unexpected:
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 analyzed today.
There is also a short video of Kloubák in the tunnel.

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 August:

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 nightmare …
… 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
rostopic pub -r 20 /X1/cmd_vel geometry_msgs/Twist – '[0.5, 0.0, 0.0]' '[0.0, 0.0, 0.0]'
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:
So each robot will have its own docker container and with a firewall it will communicate to the main simulator.