From 7272be2936e9f381e66fc3b60b14c81fd3aa2b52 Mon Sep 17 00:00:00 2001
From: Max SCHMELLER <max.schmeller@tier4.jp>
Date: Tue, 17 Sep 2024 15:05:13 +0900
Subject: [PATCH] chore(at128): add explanatory comment on why fov bounds are
 hard-coded

---
 nebula_common/include/nebula_common/hesai/hesai_common.hpp | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/nebula_common/include/nebula_common/hesai/hesai_common.hpp b/nebula_common/include/nebula_common/hesai/hesai_common.hpp
index 79c3946c7..0ffa424f1 100644
--- a/nebula_common/include/nebula_common/hesai/hesai_common.hpp
+++ b/nebula_common/include/nebula_common/hesai/hesai_common.hpp
@@ -400,6 +400,10 @@ struct HesaiCorrection : public HesaiCalibrationConfigurationBase
   [[nodiscard]] std::tuple<float, float> getFovPadding() const override
   {
     // TODO(mojomex): calculate instead of hard-coding
+    // The reason this is tricky is that an upper bound over all azimuth/elevation combinations has
+    // to be found. For other sensors, this is only a function of elevation, so the search space is
+    // tiny compared to AT128. We should be able to find an upper bound of `getAzimuthAdjustV3` but
+    // I have not invested the time for now.
     return {-5, 5};
   }
 };