Technical debt

[zbynekwinkler]

Please add all stuff we say "let's merge now anyway, fix it later".

[zbynekwinkler]

#636 (comment) osgar/drivers/lora.py

[zbynekwinkler]

#636 (comment) move ArtifactsReporter away from subt/artifacts.py file.

[zbynekwinkler]

#639 (comment) delete confusing comment in cloudsim2osgar

[zbynekwinkler]

• SubT allow wall side change based on the robot name #641 (comment) add documentation to robot name encoding strategy

[zbynekwinkler]

#644 (comment) refactor osgar.Node and all different SomethingHandler classes in bus.py (when one is updated/changed, all of them need to be changed).

[zbynekwinkler]

#657 (comment) refactor CommsClient out from ros_proxy_node and move the rest of it to cloudsim2osgar.py. CommsClient sends and receives bytes so said bytes can contain msgpack encoded data from osgar and only osgar needs to be able to parse them (not the c++ CommsClient).

[zbynekwinkler]

Follow left wall should not follow wall on the right and vice versa. Currently it finds the closest wall and then turns with its left or right side to it. We had a nice counter example in system urban where mobos was running in circles due to this.

[zbynekwinkler]

Run validator automatically on each and every cloudsim run (run it on some server, autodownload logs, generate some html report, email it, publish it to a website).

[zbynekwinkler]

Create our own cloudsim somewhere - need at least 5 computers to be worth it (1 with nvidia gpu for simulation, 4 for robots - no gpu needed if we switch from pytorch to opencv). The computers don't have to be super fast - we could limit RTF on the simulation side. The simulation is effectively able to use only 4 cores + GPU with 4GB. If the robots won't need GPU, a 4 cores might be enough. So about 20 cpu cores and one nvidia gpu.

[zbynekwinkler]

• subt.tools.ignstate: extract also breadcrumbs #662 (comment) add legend to link robot names with colors in the ground truth picture

[zbynekwinkler]

#667 (comment) in zmqrouter log all uncaught exceptions in child processes

[jisa]

We don't need to switch from pytorch to opencv to avoid running on GPU. All it takes is to say we want to run on cpu:

osgar/subt/artf_node.py

Line 90 in e4d77a3

device = torch.device("cuda" if use_cuda else "cpu")

Or simply to not have the gpu, in which case it will switch to cpu automatically.

[m3d]

Cleanup zmq-subt-x4.json - it contains "mines" like

["rosmsg.orientation", "app.orientation"]

which is now working, because subt/main.py is using self.orientation from pose3d.

[zbynekwinkler]

Running two DNN detectors in sequence is not ideal for a local development. I am getting so much delay errors that the console is unusable.

Also the opencv dnn running on CPU seems to be allocating nontrivial amount of threads that compete over the cpu cores with everything else. That leads to unpredictable runtime behavior - the other CPU cores are for other modules and not for greedy opencv. Having such a behavior also complicates planning for our own cloudsim and its hw needs.

[zbynekwinkler]

#667 (comment) in zmqrouter log all uncaught exceptions in child processes

I thought that when a node crashes, the whole thing is taken down, but that is not true. The crash goes unnoticed. The only time the whole thing stops is when any of the nodes stops regularly. For example exception thrown from the __init__ goes totally unnoticed (except message to the console, which on cloudsim means /dev/null).

[zbynekwinkler]

#693 (comment) we should introduce something like --draw profile or --draw delay ... i.e. optional --draw extra parameter (there are other modules where I am also commenting out graphs of different variables).

[zbynekwinkler]

Follow left wall should not follow wall on the right and vice versa. Currently it finds the closest wall and then turns with its left or right side to it. We had a nice counter example in system urban where mobos was running in circles due to this.

Like here: robotika/subt-artf#55 (comment)

[zbynekwinkler]

Add unittest to subt.drone setting height: #702 (review)

[jisa]

Add capability to report multiple artifacts from a single image. Our detectors can handle multiple objects of interest in the same scene, our reporting cannot.

[zbynekwinkler]

Wait until ROS starts up #713 (comment)

[m3d]

System Track robots do not have working artefact detector - change from 2D answer to extended info with 3D relative position. See #735

[zbynekwinkler]

I think we should figure out a way how to use the information provided by the service returning the robot offset from the artifact origin for limiting from where artifact may be submitter, thus not reporting artifacts while we get the offset. That would remove the need for the constants defining the staging area. #738 (comment)