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: 16/9/2019 — Photos Day 4

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.

21st July 2019 — Virtual too easy? Let's introduce launch changes … (11+7/25 days)

Well, the original title was „Virtual too easy? Let's add some randomness and chaos at the staging area!”. Sigh. It is not the end of changes from, what it looks like simple now, Gazebo 9 world to competition Ignition world. I did not check if the robots are now at least a little bit moving (#103: X1 and X2 basic motion), but in mean time Zbyněk discovered another game changer Will the robots be spawned at any place in staging area and we need to detect the entrance?. Originally I expected that I just missed something that my X2 robot starts next to the entrance, and that I have to look up how in the new world define its position. Well, do you want to know the truth (or better to say the current status week before the original scheduled end of the virtual tunnel track competition)?
The robots are spawned randomly and you have to find the tunnel entrance yourself!
Note, that in order to have „more fun” the entrance was like a large step, so you would not be able to detect it by laser unless you try to drive over it (see my post and screenshots from Dec 2018). The old workaround was to „close eyes” and simply overcame it with blindly driving straight until the gate appeared and you see left and right wall as it is in the rest of the competition course.
The other joke is the random placement of the team of robots. Forget the simple „keep left” and „keep right” strategy, because you will very probably avoid your robot teammate. You can also end-up circling around the tent in the staging area instead of exploring the tunnel.
Why are they doing this? It is not because of the money prize I believe but because it is the simplest solution to their current design problems. Also in System Track there are specific AprilTags to precisely identify the tunnel entrance and (0, 0, 0) is the tunnel entrance. If you would like to use the same schema then the robot would know automatically from requesting ROS topic /subt/pose_from_artifact_origin in the staging area as it must anyway (to know the offset of reported artifacts).
There is scheduled call with Tim (Program Manager, DARPA Subterranean Challenge) on Monday 22nd (i.e. tomorrow) so we will see.
p.s. note Team Configuration Tutorial … to me it look like that I have never seen it before, but I was — it only changed a lot recently.

23rd July 2019 — DARPA call, Freyja upside down, (9+7/23 days)

Yesterday we had call with DARPA SubT officials: Tim, Viktor and 3rd person I did not got the name of. Our talk was mostly complains that we used Virtual Track as preparation for System Track, but now it changed into time and energy sink. Nothing is really working and the SubT Docker Hello World is, according to Viktor ready for download, but we did not get/found it yet. Hopefully today.
Yesterday we also received regular weekly report from Switzerland. This time with subject subtitle (The Good, The Bad, The Ugly). Robot Freya is strong and can easily climb the walls, but does not hold there. For unknown reasons the safety feature, preventing large tilt and pitch angles, failed to respond quickly enough. The details are still part of investigation — one suspicion is that there is a small lag in the system which turned out to be too long in similar situations. The worst thing is that it landed on one of the SICK programmable prototypes TIM881P and the hit probably broke it. The motor is no longer spinning and the status report is:
$ (echo -e "\02sMN SetAccessMode 03 F4724744\03\02sRN SCdevicestate\03" ; sleep 5) |
sAN SetAccessMode 1sRA SCdevicestate 2
Finally we received nice e-mail from another competitor in Virtual Track: Hi, I'm from one of the other teams in the Subt challenge (virtual teams) - From the issues, I understand you have similar problems to pretty much everyone else - new Ignition simulation is buggy. I had a call with Darpa today and I asked them to delay the competition since there's not enough time (who knows when everything will be fully functional...). They said they'd consider it, if other teams mention the same issues. So if you talk to them, maybe you can request the same thing, to postpone.... Regards, Chris
I believe that DARPA will postpone the Virtual Track by another week, say to 15th August 2019, but not any longer. They have to run simulations of all submitted Docker images, evaluate the results and announce them together with System Track on 22nd August 2019.

24th July 2019 — Virtual Tunnel Circuit extended by two months! (8+7+60/23 days)

Today we received e-mail from Tim stating: The Virtual Tunnel Circuit solution submission window is now expected to close no earlier than September 30, 2019, with a final date determination expected in the next few days.
The things are up-side-down now! It is no longer the top priority to deliver at least something into virtual world but re-focus back on System Track only which continues within the original schedule. I believe that our German competitors could be a bit disappointed as they already bought the plane ticket for the ceremony on August 22, but on the other hand I suppose that everybody is somehow relieved that the „fight” will be more interesting in September.
From the Robotika Team perspective of we may fully focus on System now, and what is maybe even more important we may have more developers for Virtual Track in September! Somehow it makes me happy, that now I have only one problem to solve (System Track) and not two.
p.s. in mean time we exercise the latest Docker image, remotely via ssh-tunnel (thank you MapFactor) to our GPU workstation:
gpu@gpu-desktop:~$ export DISPLAY=:0
gpu@gpu-desktop:~$ docker run -it -e DISPLAY -e QT_X11_NO_MITSHM=1 -e
  XAUTHORITY=XAUTH -v "XAUTH:XAUTH" -v "/tmp/.X11-unix:/tmp/.X11-unix" -v
  "/etc/localtime:/etc/localtime:ro" -v "/dev/input:/dev/input" --network host
  --rm --privileged --runtime=nvidia --security-opt seccomp=unconfined
  nkoenig/subt-virtual-testbed tunnel_circuit_practice.ign
  worldName:=tunnel_circuit_practice_01 robotName1:=X2L
  robotConfig1:=X2_SENSOR_CONFIG_4 robotName2:=X2R
gpu@gpu-desktop:~ import -window root Pictures/Image5.png
p.s.2 it looks like the proposal to align System and Virtual Track was accepted — see the Issue #112 - Will the robots be spawned at any place in staging area and we need to detect the entrance?. Also note that the placement is not random but in regular grid with fixed offset to the tunnel entrance! Never-the-less setting the origin to the tunnel portal should simplify it a bit more.

1st August 2019 — Two Weeks to The Contest

There are two weeks remaining to the first day of Tunnel Circuit SubT competition. There should be „orientation” on Thursday August 15, Move-in teams on Friday and on Saturday August 17 is already going to be our first Scored Run. There is not much time left …
Freyja SLAM
Freyja SLAM
So what is going on in meantime?
Robot Freyja is back and running again after the climbing-wall accident. Many thanks to the generous support of SICK company for the fast replacement of lidar TIM881P. The devices are already in production and by default they are no longer pre-programmed with „Hello World!” old TIMxx code sending scan data. This was in particular trouble for Cogito Team as they are operating purely on Linux (AppStudio runs on Windows). Again it was quickly sorted thanks to SICK developers.
Robot Kloubák has its „clone” nick named K2. It is not identical copy, and to my surprise on the last Tuesday it was not only a little bit wider but also a bit longer. I do not know the motivation but this surely means that each robot must have its own configuration and calibration file. The ordered batteries 42V, 4.4AH already arrived to the „U.S. base” so it is clear that K1 will stay at home (you may see it at „Zemně Živitelka” exhibition next week) and K2 will fly.
Yes, there are many dark sides to this decision: K2 autonomously moved this Tuesday for the first time! It did not drive more than 100 meters in total so far. Also placement of LIDARs (two TIM881P placed horizontally covering 360 degrees, fulfilling the symmetry requirement), cameras and lights is not finished yet. There are some issues with Arduino CAN translator, new control computer APU4A is fresh and besides loosing time (should be fixed ASAP) there will be surely some surprises. Yeah, I should take it as a game and live with the fact that K2 is going to have many „childish sicknesses”.
And what about Robík, Eduro and MOBoS? The Robík author was sick (this word repeats here too often) last week which stopped progress on the new cover for 360 degrees scanner. The prototype is already printed and hopefully it will be tested soon.
Eduro is without any change — it is now equipped with the newer board APU3B to support the latest SW packages (scipy) used in the new gridmap and VFH (Vector Field Histogram) code. And yes, it has the same problems with battery and time as APU4A.
MOBoS — we will leave it at home in Prague, I guess. PavelJ will return in a week and he may like the Cogito proposal for running Jupyter notebook on robots as a servers and use browser for Operator Control Center, but the chance is below 10%. Both robots Freya and MOBoS (running ROS) have huge logs so it would take unreasonable just to copy the log files from robot to the control center computer. We will see. The plan is that within a week we should be
LoRa devices
LoRa devices
able to control Freyja remotely, navigating in the basement in Switzerland.
Maybe one more update regarding LoRa (Long Distance Radio). František prepared 5 devices capable to receive and transmit short messages via radio. They work for several kilometers above the ground and probably tens maybe even a hundred meters underground. The used frequency is illegal in Europe and the devices are in U.S. anyway so František prepared setup of 3 Raspberry PI stations placed in and around his house in order to enable remote testing. The goal is to place one unit in the control station and others on each robot. The messages are automatically re-transmitted so if nothing else the operator may know where are all four robots. There is also option to send positions of automatically detected artifacts.

12th August 2019 — Pack your bags (and robots)!

It is time … I got this message from AirBnB (Reservation reminder - August 13, 2019, Pack your bags!, It’s almost time for your trip to Bethel Park.) and our flight via London to Pittsburgh is tomorrow. Are we ready? No way
So who is coming? Freyja, Robík, Kloubák K2 and Eduro.
The biggest HW changes (yes, still) are on Kloubák K2, which is now equipped with two SICK TIM881P for symmetric navigation, two IP cameras and two lights.
[I am sitting at the railway station now waiting for my train to Prague. It is hard to believe --- ,,České Dráhy'' is really expert! First of all they canceled every second train, so instead of taking train at 21:04 I went for later one at 21:34. But as I was approaching the station I have seen the train leaving to Prague! That was around 21:25?! So I stamped my ticket and waited. Shortly there was an announcement that my train will be delayed by 55 minutes! So if somebody will go for another train it will mis it by 5 minutes too ... from this point of view SubT Challenge problems are just fun to solve If nothing else then I have enough time to finish this last report before we takeoff tomorrow morning … hopefully I will have all necessary tools at home to take Eduro robot apart and prepare it for the trip and also I hope I will wake up and not mis the flight …]
So where are we? Yes, the status. So Kloubák K2 is completed, I mean hardware. Now the SW, sigh. Usually I would refuse to work on platform which is not ready at least one month before the competition, but these times are changing probably … and sure enough, there were/are problems. The first issue was with lidar — there were self-reflections but I am no longer sure they were caused by mounting bracket or position of the camera.
The second issue was reading of tachometer from vESC drivers. There is older version 3.40 not supporting transmission of selected value so the whole status is sent. And it is large (59 bytes) from the „CAN point of view”. The message is split into nine messages containing 7 data bytes plus one extra message with checksum. Multiply this by four motors and you will get higher traffic … and this fails to be logged properly and the data are no longer synchronized with the rest of the system. But if you record them separately everything works … so there is some „magic” behind to be resolved over next two (?) days.
The latest news from Freyja are also not great. First of all it collided again at speed 1m/s … but at least she was slowing down and only the holders were damaged, not the SICK lidars. SLAM will have to be 2D only and the Z-coordinate will have to be „approximated”. Slowing down, dropping features … which is maybe the way how it should be, right?
Robík did some in-house practices with following the wall using its symmetry, rsync for synchronization of log files between robot and the base station … and we will see.
Eduro is hopefully at home where I left it on Wednesday.
And that's it. Sigh. Excited? Originally I wanted to describe the different strategies for Freyja, which is like „Google car” with many sensor and logging 3GB per minute, vs. „OSGAR driven robots” (Robík, Eduro and Kloubák) where the key is relatively small log file and 3GB should be enough for the whole hour … but I should double check it. Due to the amount of data Freyja collects there is no way to copy them first to the base station computer. Freyja serves the data via Jupyter notebook as a server and operator uses a web browser to assess it. OSGAR should use already mentioned rsync.
[I am sitting in the train now --- it left 22:32 so two minutes BEFORE next scheduled train]
[22:38 I should not be exited about my train --- it will be terminated and I will have to switch to another train! Now I am starting to doubt to catch the last subway train at midnight ...]

14th August 2019 — U.S. Day 1

This is just a quick report for friends and supporters. Let's start with the good news:
  • all of us (7 people, 4 robots) are safe at nice house in Pittsburgh
  • it looks like nothing was seriously damaged (not counting small twists and disconnected connectors)
  • robots Freyja and Eduro collected „New World” some data
And now the bad news:
  • the three ordered battery packs for robot Kloubák2 were bad or even fake?!
  • Robík network is not stable
  • the immigration fail to give Jirka business visa so he will have to try to fix it tomorrow at the airport (You will not be allowed on campus with an I-94 that shows a B-2 OR W-T (Tourists) class of admission.)
Standa, Jakub and Franta were searching local shops and bought some new (smaller) batteries. PavelS was soldering connectors for Robík's batteries and helping Kloubák. Freyja has now working E-STOP via DIO1 pin and Eduro has it integrated now via USB (it turned out that we could receive the DARPA signal, but we did not forward it emergency stop message). Also couple of LoRa messages were transmitted from Eduro, but the receiver on Windows7 has some issues as it resets the device on opening COM port (somehow it reminds me Arduino behavior) … so it has to be sorted out, as otherwise autodetection fails.
p.s. I have had the first hand experience operating Freyja via Chrome browser with Jupyter notebook page — it is kind of fun and also a bit scary if I imagine what she is able to do. We will see in the tunnel …

15th August 2019 — U.S. Day 2

Today were all four robots moving and e-stoping. Surely, there were still „devil's details”, like broken Hall's sensor connector on K2 front left wheel, swapped phase cables on front right wheel, but these „minor” issues were found and fixed.
A big surprise was robik-subt-estop-190815_170135.log test, when Robík was following the right wall but suddenly instead of turning left it turned right and decided to climb the wall. There was manual intervention (STOP button), but later we unblocked it, as robot recognized dangerous pitch angle and returned to the base.
The detail analysis of the log file showed problem with 360 degrees lidar index, which, probably due to some race condition in buffer access, was rotated by 90 degrees. The buffer was corrected in the next few scans but that was already too late. Funny enough this bug must be there in the code for years, but did not show up sooner (or better to say the „emerging behavior” was never that bad). So now PavelS is working on low level firmware patch.
What else? OSGAR driven robots could now use LoRa command GoHome implemented early in the morning, but it was not properly tested yet and so it is not merged in master.
Yeah, maybe a small detail — the contest officially started today! It was nice to see Tim, Elissa, Viktor and others again. STIX surely helped us to have better idea what to expect … but maybe not, we will see tomorrow, the move-in day. Sure, we are here the „Aliens In Transit” and several people had also problem with I-94 form (business vs. tourist … different stamp in the passport and something else online … so our Jirka is not the only one). Also people from Czech CRAS team, because of this problem, were going again to Pittsburgh airport to find a paper on the doors saying, that you should call somewhere and then they direct you to e-mail somewhere else … etc. somehow it reminds me the beginning of the Hitchhiker Guide into Galaxy.
p.s. they must be really afraid of us — we will have our own escort service …

16th August 2019 — U.S. Day 3 (Move In Day)

OK, today it will be only few pictures, as I am too tired and it is time to go to bed. Tomorrow we are competing for the first time. In the lottery we got number 4, which means Experimental tunnel and start time around 10am.
I will start with a „joke” with rabbit — see video. This was recorded by robot Kloubák K2 testing following of the left wall …
And here is micro-sample of pictures from the move-in day:

17th August 2019 — DARPA TV - Subterranean Challenge Tunnel Circuit

Robotika Team starts today at 10:45 but the feed will be delayed for 1 hour … so for Czech Republic this means + 6 + 1 hour = 17:45 CET

Game 1 — Experimental Course

OK, Robotika Team first run is over … and it was not easy but we met our goal to score at least one point!
Get Status {"score":1,"remaining_reports":33,"current_team":"robotika","run_clock":3400.5}
As Murphy promised something will go wrong and it did. And it was an unexpected nice trick — shortly before the start (in seconds) the power in the whole staging area went out! Yeah, we have notebooks, robots have batteries so how can this be a big deal?! Well, we also have a new router and a directional WiFi transponder which handles all communication with our robots. I should write „almost all” communication with „almost all” robots, because Robík was too often failing in client mode so we use it as an access point instead. Further, OSGAR powered robots could send LoRa messages to share position info.
So without power there was no communication and the robots could not be even started. It was very very discouraging. Up till yesterday, we used direct AP communication only but we changed it to go through the WiFi router to accommodate easier control of all 4 robots.
And the recovery took a long long time — the whole half hour we received to prepare again as somehow the WiFi did not properly clear its state (?).
The official start moved from 10:45 to 11:15. The plan was to send Freyja 20 meters just to test how it feels like. And Freyja did not like the shallow water pools at the entrance at all. She moved 1 meter forward but then returned that she is too afraid to enter the tunnel. And this repeated four times until we changed the plan to proceed with the next robot.
Robík was more brave and ran there and back nicely with timeout set to 240 seconds. This quick check unfortunately did not discover any artifacts behind the first hidden corner. We started the second Robík's run immediately and set the timeout to 10 minutes … and that was the last time we have seen it in this run. It got stuck trapped too close to a wall.
The next robot on the scene was Kloubák K2. Jakub suggested speed 0.4 m/s, but it moved so slowly that I killed that before crossing the entrance line and switched to 0.7 m/s. Much nicer! What was not nice was a detail that I did not set the timeout value (!) and we were wondering how much that actually was … 10 minutes. Yes, it was also the last time we have seen this robot at the staging area as it got stuck at around 200 meters into the tunnel. Nevertheless, thanks to the good WiFi connection we were able to download the logfiles and check for artifacts … there was one, but it was a nightmare to properly establish its position. Kloubák still has problems with odometry and processing/storing tachometer data, so it is not reliable … probably priority task for tonight??
I do not want to (I am even not sure if we are allowed to) publish videos and logfiles as the setup is probably the same for all teams and the same will repeat tomorrow for the second half of the teams. The same holds for detail pictures from robots :-(.
At the end Freyja went for another trip (note that she always returned home, but the odometry was not precise enough as the wheels were slipping. She ended up 10 meters in the tunnel so we had to add „manual correction” for home position.
Finally I wanted to send Eduro to double check the positions of artifacts — we have seen at least two … but maybe my head was just getting dizzy. It was already too late and Eduro got stuck on the rail again, so no extra point this time. BTW nobody turned the light on it …
Status: 1 point and all 4 robots survived (knock, knock, knock). Let's get ready for another muddy business tomorrow!
p.s. results from DARPA Twitter:

18th August 2019

Game 2 — Safety Research Course

The second mine was interesting. I expected a lot of mud and deadly lidar conditions, but it was not that bad. Or I should rather say that water and mud was not that bad, but there were other „killers hidden in the darkness”.
Get Status {"score":1,"remaining_reports":37,"current_team":"robotika","run_clock":987.4}

Control center setup

Today, the setup was without any surprise. Everything went smoothly, each Pit Crew Member already knew what to do. Today we used two laptops: Zbyněk's linux machine for Freyja control (via Jupyter notebook), and my Windows 7 for console terminals for robots Robík, Kloubák K2 and Eduro. It served also as center for LoRa data collection (see next section for details).

LoRa — Long Range Radio

Today all 3 OSGAR robots „inherited” and integrated new functionality to be potentially controlled via LoRa. There were only two commands implemented: GoHome and Stop. The main motivation was that in the case like yesterday, when Robík lost WiFi connection and we could still hear that the poor robot having problems, we would have a chance to do something. Now we can send Stop and the problems are over. [yeah, there is still a bug where if you stop Eduro on the way out it first tries to turn 180 degrees … it is on our ever growing TODO list].
The communication log is surely harmless to share, so here is test-lora-windows-190818_142524.log 1 hour recording of all what robots and control center „discussed” over the LoRa communication channel.
Some best quotes today:
0:19:36.938317 1 b'4|alive-534689\n'
0:19:55.799396 1 b'4|[3020, -4473, -8385]\n'

0:22:05.781830 1 b'5|alive-674082\n'
0:25:25.373246 1 b'5|[93104, 48744, -3523]\n'
0:25:36.281870 1 b'5|[93104, 48744, -3320]\n'

0:34:01.471765 1 b'4|alive\n'
0:35:51.222043 1 b'4|[27187, 13934, -14688]\n'

1:03:53.831283 1 b'2|alive\n'
1:07:44.485475 1 b'2|[-46996, -67139, -3010]\n'
1:07:54.444045 1 b'2|[-46996, -67139, -2968]\n'
Lot of fun, right? The first message at 19:36 is from Robík (#4) going ready for action and the furthest point is approximately 5 meters away (note, that the coordinate system is not aligned with DARPA coordinate system!). Robík simply did not want to go into the tunnel and immediately returned to the staging area.
Then Kloubák (#5) started but after 3 minutes got stuck approximately 100 meters (?) into the tunnel.
That was followed by the second try of revised Robík version at 34:01 but near the April Tags (say 30 meters) it decided to go home again.
The last call at 1:03:53 after starting the LoRa base station was Eduro (#2) and it got stuck at approximately 80 meters at the graveyard of robots.

Eduro kissing the earth

The last message from Eduro robot sounded scary:
0:03:47.016693 Roll limit triggered termination: (roll -20.1)
0:03:47.016693 Going HOME
0:03:47.016693 turn 90.0
0:03:50.133154 stop at 0:00:00.550812
0:03:50.133154 turn 90.0
0:04:10.141207 turn - TIMEOUT!
0:04:10.210226 stop at 0:00:00.069019
0:04:10.215868 Pitch limit triggered termination: (pitch -54.0)
… so the 10 year old robot was on a slope, recognized the problem but instead of backing up it wanted to go home, turned and fell on its nose. Luckily this situation now automatically triggers stand still and program termination. Sigh, I did not check the SICK lidar yet …

Kloubák odometry

Today we collected detailed tachometer data from all four wheels to improve the odometry (which cost us one point yesterday). Now it is computed as it should be, from the passive wheels. Kloubák uses the original navigation where only the front wheels propel the robot and the rear half acts only as a trailer. And when the robot moves back both halves simply swaps their roles.
You can see that one wheel was in the air while all others were stationary. This happened around the 3rd minute with distance say 100 meters (one tick is approximately 1cm). So now we have nice data for the next revision.

Kayton camera auto-exposure

I almost forgot what was turned out to be the deadlies trick of this tunnel for us: bright lights but not illuminated environment! All I could see from Freyja and partially also from Robík Kayeton cameras was black and few ultra bright spots! Really hard to find anything! Where again Kloubák and Eduro had superior performance mainly due to much stronger lights.
p.s.2 Eduro SICK lidar survived
p.s.3 Kloubák K2 failed not because of the collision but because of bad CAN message:
Traceback (most recent call last):
  File "D:\WinPython-64bit-\python-3.6.2.amd64\lib\", line
 916, in _bootstrap_inner
  File "M:\git\osgar\osgar\drivers\", line 312, in run
    self.time, channel, data = self.listen()
  File "M:\git\osgar\osgar\", line 23, in listen
    return self.bus.listen()
  File "M:\git\osgar\osgar\", line 104, in listen
    getattr(self.node, channel)(dt, data)
  File "M:\git\osgar\osgar\drivers\", line 249, in slot_can
    if self.process_packet(data):
  File "M:\git\osgar\osgar\drivers\", line 220, in process_packet
  File "M:\git\osgar\osgar\drivers\", line 140, in update_buttons
    assert len(data) == 1, len(data)
AssertionError: 8
and yes, there was one button message 8 bytes long instead of 1 byte:
0:03:43.254717 2 [1, b'\x00\x00\x04\x1f\x00\x1f\x00\x7f', 0]
0:03:43.257067 2 [1, b'\x00', 0]
0:03:43.258182 2 [2, b'\xa0', 0]
(verified from PeakCAN separately recording vESC tachometer)

19th August 2019 — Day Off … maybe, maybe not

Today we had „day off”. Now I know that it was not meant to relax or recover, but that DARPA needed some time to modify the tunnels! I feel much more exhausted than during the competition days … so what are the news?
Robík is being reprogrammed to handle „Safety Research Course” start section … just go straight and do not much worry about following the right or the left wall. It is now equipped with new lights (we bought all battery construction lights in both nearby Walmarts).
Freyja has also new light pointing to the sides and up. She is getting ready for large exploration trip and she may not return, but hopefully she will. The client interface is improved for indication which of four cameras sees suspicious object, SW control of brightness post-processing, faster video forward/backward motion etc.
There is no change on Eduro robot. It was used for testing LoRa Pause and Continue commands for manual coordination of multiple robots near tunnel entrance, improved virtual bumper for detection collision and WiFi scanner for Cell Phone artifact.
We were asked by DARPA to provide collected data so now there are first videos converted. The best view seems to be for recordings from Kloubák, so here are two samples using rear camera:
p.s. yes, there is minor detail filtering out all suspicious CAN messages on Kloubák … hopefully it will help and it will not die in the first few minutes again …

20th August 2019 — Game 3: Safety First, right?

I must admit that our expectation today were quite high, or I should say that at least my expectation were (now I would say unreasonably) high. Not only that we will beat our previous score 1 point but maybe get 5 points as our Czech competitor CTU-CRAS. Sigh, naive, very naive.
Shortly we did not score a point! We had only one indication of artifact but failed to score its position. I cannot tell you which now, but you may guess it … update tomorrow night.
So what went wrong? I do not know — maybe just the „treasure” is hidden further in the tunnel and there are no easy catches?? Instead of black images two days ago I had perfect contrast view from Freyja seeing every detail on the wall, but I could not find anything (and yes, the automatic pre-selection failed too).
Well, maybe I will mention the joke anyway … we changed report of artifact to submit 3 positions at once. I added parameter -1 to keep the old behavior, but …
M:\git\osgar\subt>python S 180 -2 2
usage: [-h] [–only-one]
                      {Survivor,Backpack,Cell Phone,Drill,Fire
                      Extinguisher,S,B,C,D,F} x y z error: the following arguments are required: z
Just be aware that negative numbers are interpreted as parameters.
OK, so what else went wrong? First of all 360 degrees lidar is broken now:
We have spare lidar for Robík and it is already replaced — the robot is ready for the last strike!
Kloubák K2 worked nicely … well, until it reached the problematic point as the last time, decided that it is still a problem and returned home. Twice. The 3rd time we tried the other side partially blocked by Robík and both robots collided as the lidar plane for Kloubák is higher than for Robík … sigh.
Freyja went for a long trip (destination set to x=10km) but returned after approximately 100 meters, as she got scared of sharp turn at T-junction.
And Eduro did not even get a chance today :-(. We all know that it would probably fall over as two days ago.
  • 23, 9, 9, 6, 5 … 2, 2, 1, 1, 0, 0 … so minimum is to score at least 5 artifact to have a micro chance for awarded place (if nobody else will score, which is also quite unlikely, right?) …
So what we will do tomorrow? We decided to have a fun: we will probably start multiple robots at once, keep 10km and 10 minutes as minimal values as larger values do not have much sense, but why not to try „random walk” and if there is a problem on once side then to try the opposite wall? Maybe more LoRa commands: RWall and LWall, maybe even with distance parameters?? Well, I need to sleep and I can work early in the morning, so we will see. This is the last chance …
p.s. I am thinking about WallE command … what it could do? „Zoufalí robotici dělají zoufalé věci”

21st August 2019 — Game Over, Deprecate the operator!

It is over now. We have lost, at least from the score point of view, but it was much more fun today! Only the operator is the one to blame … (too many rude words). It is funny that as we walked towards the Experimental Mine and chat with Mike about what we like and what could be improved, and we suggested that in real disaster scenario would be more realistic to have at least two people: Operator and Copilot. Two hours later, when we had problem to report Cell Phone again after successful scoring of Fire Extinguisher I would change my mind — !!Eliminate the operator!! (yeah, deprecate is maybe nicer word). That would actually make my life easier … and System Track would be closer Virtual Track again.
So let's rewind and start with yesterday night. Robík upgraded/replaced 360 degrees lidar, Jakub took care of Kloubák and added and tested code to slow down when the joint angle is out of desired limits +/- 10 degrees (this was shortly before the thunderstorm). I went to sleep. Freyja got new code with vector field histogram more tolerant to perpendicular walls, tolerate now larger roll angles and original safety rectangle was replaced by oval.
The strategy was similar to previous days except swapping order of Kloubák and Robík, so Freyja first, Kloubák second, then Robík and at the end Eduro.

Kloubák K2

As usual, the code was really fresh so Freyja did not want to enter the tunnel again. Jirka went to debug it and we started Kloubák. This articulated robot had 1 hour old code which was reviewed only from log files, but at least the basic was tested twice (ha ha ha) this morning in the garden. Whenever Kloubák encounters problem (large pitch or roll, get stuck for 10 seconds in circle smaller then 0.5 meter) it switches front-rear, moves for 2 meters with increased distance from the wall by extra 20cm (it started today with 1 meter desired distance from the wall) and it tries to go forward 4 meters along the wall. If everything goes well then it returns to its original wall distance. If it fails it tries another extra 20cm and repeats reverse and forward motion. Then it gives up and tries again original distance. All is terminated by global timeout set to 10 minutes today for all robots.

Freyja meets Kloubák

Freyja went the second. Sure enough she met robot Kloubák on its way back home. They did not collide, but Kloubák was confused and completely blocked the tunnel (perpendicular to the tunnel direction). Freyja evaluated situation to be too complicated and decided to return home. She was still online so operator could send command „re-try” and in mean time Kloubák was forced to move blindly forward to make space for Freyja. And it helped, Freyja passed (maybe after 2nd re-try).


Then Robík — new lidar had different timing and I have seen warnings, that the scan is not reliable. Another re-calibration was needed (from 144ms, to 182ms, 190ms … 250ms final).

Eduro meets Kloubák

Finally Eduro — I wanted to see it moving and it was actually cool. It shared the same code tested in the morning on Kloubák with increasing distance from the wall, but the weak point is that Eduro is not symmetric and so it is not 1:1. To my surprise it went all the way to blocked Kloubák and couple times got stuck on the rails, recovered and was heading home. But suddenly as Robík was starting it turned sharp right into pool of water! (that's the devil's detail we reviewed after the game).


So far so good? Awesome! (as Americans like to say) … maybe we forgot something?? The artifacts! I re-processed detector running on Kloubák showed 21 images and WiFi-scanned detected Cell Phone:
python -m subt.check_phone Ykloubak2-subt-estop-lora-190821_155852.log
0:00:34.035534 PhoneArtifactFT -83
0:00:45.479972 PhoneArtifactFT -85
0:00:56.958820 PhoneArtifactFT -82
0:01:08.637661 PhoneArtifactFT -84
0:01:20.244273 PhoneArtifactFT -78
0:01:31.656184 PhoneArtifactFT -78
0:01:43.421268 PhoneArtifactFT -78
0:01:55.191406 PhoneArtifactFT -79
0:02:06.618603 PhoneArtifactFT -79
0:02:17.999966 PhoneArtifactFT -84
0:02:29.379054 PhoneArtifactFT -79
0:02:40.778966 PhoneArtifactFT -84
0:02:52.513556 PhoneArtifactFT -78
0:03:04.151822 PhoneArtifactFT -84
0:03:15.810386 PhoneArtifactFT -59
0:03:27.513408 PhoneArtifactFT -75
0:03:39.106487 PhoneArtifactFT -81
0:03:50.549879 PhoneArtifactFT -76
0:04:02.292117 PhoneArtifactFT -76
0:04:13.961007 PhoneArtifactFT -76
0:07:11.773538 PhoneArtifactFT -73
0:07:23.395250 PhoneArtifactFT -75
0:07:35.109542 PhoneArtifactFT -77
0:07:46.962463 PhoneArtifactFT -76
0:07:58.704235 PhoneArtifactFT -80
best: 0:03:15.810386 PhoneArtifactFT -59
Windows Live Photo Gallery — I love this program! I just realized what went wrong!!! I opened the images in artf directory went through images, noticed
Reported and Team Robotika scored 1 point. But the other images were also converted but the program did not refresh so I have not noticed newer images like:
Do not worry about the misleading names — we used detector from Virtual Track before they changed the list of artifacts. Somehow it worked reasonably for System Track filtering, so we used it.
Kloubák had seen 3 artifacts (Fire Extinguisher, Drill, Backpack), and noticed Cell Phone on WiFi scan.

Freyja again …

Freyja moved much further and beside artifact noticed by Kloubák, she spot also Survivor. Sigh. It is really sad that I reported only the very first Fire Extinguisher and tried (unsuccessfully) to „guess” the position of Cell Phone. So the last message was:
Could be easily 3 (the artifacts were clearly visible near the main line), sigh again.
The good new is that it would not help us anyway — see the results. If I remember correctly we ended on shared 7th-8th place (the order depends on report time, so it is 7th or 8th, not shared).
p.s. the worst thing today (so far) was the lost of the half of 15 minutes Freyja logfile :-(. Jirka waited several minutes, but could not connect … and the reason was that the robot was flushing the recordings … in total 1TB for last 4 days.


Unlisted raw DARPA videos

Final Results

Congratulation CTU-CRAS!

23rd August 2019 — Never laugh at live dragons!

..., Bilbo you fool!
Well, that somehow came to my mind yesterday after Jirka's presentation of team Robotika. There were announcements of the first 3 places (CTU-CRAS got its $200 000 cheque) and then the teams presented themselves: the technology used and „SubT Lessons Learned” (15 minutes per team).
Jirka's talk was about complexity to deploy first responders systems and that we are actually more prepared as we are forced to fit our robots in checked-in luggage on the plane. We can pack it in less than hour and fly, but the large robots require non-trivial transport and logistics. BTW assembly time has to be also taken into account — Kevin, one man team Coordinated Robotics, had quite hard problem to assemble all his drones when he flew to Pittsburgh from California(?) … it took him 2 days(!) if I remember correctly. BTW he received „prize” for the most robots per team member. … and I almost forgot that we received „prize” (all bottom line teams got some award) for the most distinctive robots … if nothing else it was nice to see professional pictures of Freyja, Robík, Kloubák and Eduro.
The second comment was about our efficiency — that we scored more points per invested dollar than any other team. However, what he did not cover is that we can expect each additional point to be more difficult and expensive to get than a previous point. Let's see if we keep the efficiency when, hopefully, we score more points next time.
Jirka's presentation did not cover difficulty of the competition itself because, frankly, we had not seen much of the mine at that point. Our robots did not explore much of it. Even after visiting the mine (thanks, Kevin, for taking our team members under you budget of allowed visitors!) after the presentations our team is torn on the difficulty. On one hand, it was an environment with many obstacles, water of unclear depth, mud and with some artifacts hidden so well that even a person would have hard time to look for them, on the other hand, it could have been even more difficult with ladders, running water, deep holes and what not.
And that is almost the end of System Track - Tunnel Circuit story. Some people are flying home today and the rest will visit U.S. premises and return to Czech Republic on Tuesday morning.

28th August 2019 — Photos Day 0

29th August 2019 — Photos Day 1

Here are some pictures from the first competition day when we deployed our robots to Experimental Mine. Remember Freyja not entering the tunnel? Also there are some pictures of CMU robot Explorer, which won the competition at the end. Finally note deer in our garden.

4th September 2019 — Photos Day 2

The second competition day we competed in Safety Research Coal Mine

5th September 2019 — Photos Day 3

The 3rd competition day was again in the Safety Research Coal Mine. This time we expected much better score then in Day 1 and 2, but instead we got 0 points! Robík 360 degrees lidar broke shortly after start and the robot hit the wall in full speed, Eduro was not deployed and Kloubák 3 times did not find anything interesting except broken Robík and several time finished in a small alcove and returned home.

10th September 2019 — The Grand Truth

Today DARPA released the grand truth dataset for Tunnel Circuit in Pittsburgh. It is like getting the map from Treasure Island.
There is also Tunnel_Artifact_Ground_Truth.xlsx Excel table of location of all artifacts for both tunnels and two setups. The idea is similar to recent RoboOrienteering, where there is precisely measured set of potential artifacts locations and then they are placed or not.
With the map in hand it looks somehow very easy … to let's see:
1st Day, Experimental tunnel — reported location 1, backpack (67.316, -3.726, 1.906) … report was 66.7 -3 0 … I should not ignore the Z-coordinate! Location 2, Fire Extinguisher at (102.473, 1.660, 2.919) … too far
2nd Day, Research tunnel — location 31, backpack (61.904, 1.399, 2.113) … was it by time? 58 1 1
3rd Day, Research tunnel, everything was behind the T-junction, 0 points
4th Day, Experimental: again Fire Extinguisher at location 2 (102.473, 1.660, 2.919) this time it was reported correctly, missed Drill location 3 (124.958, -2.697, 2.664), Backpack location 4 (155.009, -6.043, 2.942), and more …

16th September 2019 — Photos Day 4