Adding multi-vehicle support for ART repo

[AaronYoung5]

This discussion is three fold:

1. We have the first ART vehicle (ART-1) that diverged from master a long time ago. There is code there that should be merged with master/pushed to github.
2. We now have multiple ART vehicles that need to interface with the same ART repository, and we need to support multiple computers (nx, AGX, nuc, raspberry pi, Orin, etc.).
3. We need to understand the feasibility of combining the COBRA and ART codebases. What will the mono-repo be called? Is COBRA now an autonomy research testbed (ART)? How do we organize different vehicle experiments (branches, forks, etc.)?

Tasks:

• @harryzhang1018 outline what code is on the nx/ART-1 and what should be pushed and what should be killed
• @zzhou292 @srirama02 move existing COBRA repo to use docker/atk
• @AaronYoung5 add dockerfiles/services for different vehicle hardware (e.g. computer, sensors, etc.)

[AaronYoung5]

My thoughts on 3. I see the 1:10th scale vehicles as autonomy research testbed (ART) vehicles. The ART platform is the physical robot design we've put together that builds off the 1:10th scale vehicles. So to me, it's clear that all ART platforms should use this repository (autonomy-research-testbed). In this way, COBRA isn't an autonomy research testbed, it's independent. And so if we want to mono-repo this project, we need to change the repository name or make a new one that reflects this idea.

I'll do some research on mono-repo design and report back.

[DanNegrut]

@AaronYoung5 you ask "What will the mono-repo be called?"
Would "Autonomy Stack Infrastructure" like ASI or something in that spirit make sense?
The current name is "autonomy research testbed", which the new AStack Infrastructure will enable, this latter thing though is more than just an autonomy research testbed.
I'll leave this task of finding the right name to other folks, but i think the spirit should be that this is an enabler of the AStack for our robots/rovers.
My two cents :-)

[AaronYoung5]

So @StefanCaldararu and I had a long discussion. This is what we concluded. TL;DR: do as @DanNegrut suggests the first time, it will save you a lot of time...

High level

1. Mono-repo: Code for all vehicles, sim, and docker config exist in the same repository (how this is organized is described below). This simplifies maintenance (single place for all discussions/issues/PRs to occur) and usage (one hyperlink, one clone, one directory).
2. Single main branch: There is one main branch for all vehicle code. Independent build configs are baked in (i.e. through the --optionals call in atk and vehicle specific launch files). Simplifies maintenance (one source of truth; for code to be merged into main, it has to play well with all code - I see pros and cons with this).

Technical Details

1. Launch files: Each vehicle has it's own launch file (e.g. art-1.launch.py, art-2.launch.py, cobra.launch.py) that spins up it's specific suite of sensors, nodes, etc.
2. Docker build config: The --optionals flag in atk will be used to conditionally install/build elements specific to a vehicle. For instance, the on-vehicle ART-1 image may not need to have a camera driver, but ART-2 does. So you'd run atk ... --optionals art-2 where art-2 is defined in the atk config file and will correctly build the image is required for that vehicle. As a note, this is applies to both the development containers (NOT run on target hardware) - though there may not be much that is not shared across vehicles here - and vehicle-specific containers (run on target hardware).
3. Colcon build: This is the tricky one. We will need to somehow tell colcon (the build mechanism for ROS 2) to select packages that correspond to the specific vehicle you're using/system packages you have (i.e. you can't build the ROS camera node for ART-1 if you didn't install the driver which is only for ART-2, so colcon will error out when it can't find the driver). I propose a few solutions:
   1. Meta packages: each vehicle will have a meta-package associated with it. Meta packages in ROS basically define the dependencies needed to install this package. As such, if a package should be built for the vehicle to work, you add that dependency to the vehicle meta package and it will build correctly when you call colcon build --packages-select <vehicle-meta-package>
   2. Colcon launch files: launch files that call colcon with the desired packages that you need. If you need to build a different package that isn't in the launch file, you can use colcon build --packages-select ... or add it to the launch file.

Other

Package organization is still up in the air. I think we can keep the current package structure, and rely on README and/or launch files to determine what it's purpose is. Thoughts anyone?

This is independent of my discussion with Stefan, but putting here as it pertains to this idea. I think the COBRA model is chrono specific, and should therefore not live in this repository. The place I recommend for it is in chrono-projects.

[StefanCaldararu]

I agree with the above. No Cobra is also fine. Can you elaborate a little more on Technical Details 3? I like (ii) from my understanding, but what would be the benefits/drawbacks of each?

[AaronYoung5]

Personally, I think meta packages make more sense. Basically, within the meta package, we specify all the packages we need (localization_py, control, yolov5) and when we call colcon build --packages-select art-1-vehicle-meta-package it will only build those packages we want. This is I think more clear than a launch file, which will basically just be a list of string of packages that get passed to a launched os process within the launch file.

[AaronYoung5]

So then TODOs:

• @harryzhang1018 outline what code is on the nx/ART-1 and what should be pushed and what should be killed
• @zzhou292 @srirama02 move existing COBRA repo to use docker/atk
• @AaronYoung5 add dockerfiles/services for different vehicle hardware (e.g. computer, sensors, etc.)
  • See Rewrote the dockerfiles to be more extensible and readable #35 for first iteration. See need to add vehicle specific dockerfiles.
  • @ishaanamahajan to test
• @zzhou292 Move COBRA to chrono-projects