Question: synthetic device profiling between SITL and HITL?

[och234]

Hi, love the work you doing, the SITL → HITL progression is clean, especially how the same Dockerfile targets both amd64 and arm64.

Quick question: for teams using SITL who don't have a Jetson, is there anything in the stack that estimates whether their pipeline would fit the Orin's compute budget before they set up HITL?

Asking because I'm exploring a platform where users can first screen against a synthetic device profile, then validate on hosted hardware (a device farm with real Jetsons), without owning the device themselves. Trying to learn whether that maps to a real pain in the drone workflow.

[JacopoPan]

Thanks @och234

In SITL, you have a few "knobs" to "compute stress" the system:

• increase the number of simulated drones NUM_QUADS, NUM_VTOLS
• increase the real-time-factor RTF
• increase the rate and/or resolution of the sensors in sensor_config.yaml

Running htop and nvidia-smi gives a sense of the CPU/GPU and RAM/VRAM usage. (Note that the simulation will use significant CPU and VRAM to simulate things—the physics and the scene—that won't be part of the Jetson compute workload.)

If you can run the SITL significantly faster-than-real-time or at real-time with several drones, you likely won't be CPU constrained on Jetson. However, the RTX GPU + x86 CPU architecture used for SITL is quite different from the Ampere GPU + Arm Cortex-A78A architecture of a Jetson Orin so an exact assessment is not possible, especially for the GPU workloads running against real sensors data instead of synthetic ones. (And that’s why this repo tries to make the HITL/deploy transition as easy/quick as possible.)

[och234]

Thanks Jacopo, this is genuinely useful, especially the framing that the SITL stress knobs + htop + faster-than-RT heuristic is good enough that an exact pre-HITL assessment isn't worth the engineering cost when HITL transition is already easy. That's a pretty strong signal that synthetic profiling matters more for categories where HITL is harder to set up (e.g. humanoids without dev kits, VLA-class models on edge hardware that's hard to acquire) than for drones with a Jetson on the bench.
One follow-up if you have a minute: have you seen teams in the drone space stuck on the opposite problem i.e., they have an Orin in the loop but they're trying to predict performance for a different target SoC (Hexagon, an embedded chip without a dev kit, etc.) before committing? Curious whether that ever comes up, or whether teams just stick to one target architecture and avoid the question.

[JacopoPan]

One follow-up if you have a minute: have you seen teams in the drone space stuck on the opposite problem i.e., they have an Orin in the loop but they're trying to predict performance for a different target SoC (Hexagon, an embedded chip without a dev kit, etc.) before committing? Curious whether that ever comes up, or whether teams just stick to one target architecture and avoid the question.

I haven't seen that issue per se but what is a current pain point is the fact that hardware-accelerated and edge compute typically require (or at least perform better when there is) hardware-software co-design and there is a trade-off with the modularity/plug-n-play-ability of the system.

[och234]

That makes sense - sounds like the trade-off is "write generic code that's portable but leaves performance on the table" vs. "co-design tightly and lose portability." That's a pain point I hadn't thought clearly about. Going to sit with that.
Thanks for taking the time on this thread, @JacopoPan really appreciate it.