STM32N6570-DK can anchor a flying-RC-target tracker, but the first milestone should prove one sensor’s acquisition-to-control path before adding camera classification, an NPU, and pan/tilt hardware. Choose the sensor only after defining the target distance and the required outputs: range, radial velocity, or both.
What must the sensor-to-actuator path deliver?
Trace the data path before selecting an MCU. The sensor observes the target and produces measurements; an acquisition stage timestamps and buffers them; signal processing extracts detections; a tracker estimates target state; and the controller turns that estimate into pan/tilt commands. Each hop can add latency, jitter, dropped samples, or stale data. Log timestamps at the boundaries so you can tell whether a missed follow command began at sensing, processing, tracking, or actuation.
Separate the outputs. Range is distance to a target; radial velocity is motion toward or away from the sensor, not the target’s full three-dimensional velocity. A bearing or direction estimate is also needed to aim a pan/tilt mechanism. Decide whether the first version needs absolute range, radial velocity, direction, or a subset. Then define the maximum useful distance and the smallest target motion or position change the system must distinguish. These requirements determine the sensor and test setup more reliably than choosing a development board first.
For a portfolio milestone, a single sensor with stable acquisition, timestamped measurements, simple tracking, closed-loop pan/tilt control, and replayable logs demonstrates embedded architecture and controls without making camera inference a prerequisite.
How do FMCW radar, HB100, and LiDAR differ?
| Approach | What it can contribute | Key decision or limitation |
|---|---|---|
| FMCW radar module with onboard DSP | Can provide processed detections such as range and range-rate, depending on the module and its output interface. | Check which measurements and raw data the module actually exposes. Onboard processing shortens the path to a working tracker but may limit access to intermediate data. |
| FMCW radar with I/Q or analog data access | Lets the project implement and inspect more of the signal-processing chain. | Requires a suitable acquisition path and enough processing and buffering capacity for the chosen waveform and sample stream. Confirm signal format and interface from the module documentation before designing the MCU connection. |
| HB100 | A lower-complexity radar starting point for exploring Doppler-based motion measurement. | Do not treat a Doppler-only measurement as an absolute range measurement. If the requirement includes distance, add a separate ranging method or choose a sensor that supplies range. |
| LiDAR | Provides distance measurements that can support target-position tracking. | Velocity can be estimated from successive timestamped positions; it is not the same as obtaining radar Doppler data directly. Confirm the sensor’s field of view, update behavior, and target performance for the intended distance. |
An FMCW radar’s frequency sweep encodes range in the received signal’s beat frequency; repeated measurements across chirps can support radial-velocity estimation. A module that performs DSP internally can expose results without requiring the host to build every processing stage. A module that exposes I/Q or analog signals offers more opportunity to study DSP, but shifts acquisition, processing, and validation work into the project.
Three-dimensional point clouds are not a sensible first acceptance target. Begin with a one-dimensional or two-dimensional result that can be plotted and tested: range or range-rate, then a sequence of detections with timestamps. A point cloud is useful only when the selected sensor and interface provide the necessary spatial information and the application needs it.
Which sensor approach should the first milestone use?
Choose based on the output that must be demonstrated, not on the number of technologies in the sketch. If the goal is to learn radar DSP, select a radar module with documented access to the relevant signal data and make range/range-rate extraction a bounded milestone. If the goal is a quick distance-to-position tracker, LiDAR may reduce the amount of radar signal processing. If using HB100, frame the first milestone around motion/Doppler behavior; do not claim it solves absolute ranging by itself.
One comment estimated useful FMCW range at roughly 6–30 m and described detection near 30 m as only a presence indication. Treat that as a project-sizing warning, not a universal specification. Actual usable range depends on the chosen module, target, setup, and the detection criterion. Read the selected module’s range and performance specifications, then measure the intended RC target at the actual required distances. A flying toy’s distance envelope must be a project requirement, not an assumed radar capability.
For a radar module such as the named IWRL6432W, verify whether its documented interface exposes processed detections, raw or intermediate data, or both. An onboard DSP path is appropriate when reliable measurements are the priority; a raw-data path is appropriate when implementing DSP is itself a goal. Do not infer a host-compatible analog stream or data format from the fact that a module contains radar DSP.
Where can the design fail before tracking?
| Observed result | Likely layer to inspect | Diagnostic |
|---|---|---|
| Target is detected, but distance is absent or unusable | Sensor capability or processing output | Check whether the sensor provides absolute range or only motion/Doppler information; inspect the module’s documented output fields. |
| Measurements appear, but the tracker follows erratically | Measurement timing, noise, or association | Log timestamps and raw detections; separate missed detections from changing measurement quality and tracker behavior. |
| Measurements are valid, but pan/tilt response lags | Processing-to-control path or actuator loop | Measure elapsed time from sensor acquisition to command update, then inspect the closed-loop response independently of classification. |
| Raw radar data cannot be processed reliably | Acquisition interface, buffering, or workload | Verify signal format and sample delivery first; profile acquisition and DSP before adding camera inference or point-cloud work. |
| The system works in a short demonstration but fails at the intended distance | Range requirement and target detection conditions | Test the actual target across the required operating envelope and define what counts as a usable detection, not merely a presence indication. |
Keep sensor failures distinct from control failures. If the target measurement is stale or intermittent, a Kalman filter cannot recover information the sensor never supplied. If measurements are timely and repeatable but the mount does not follow, investigate state estimation, control behavior, and actuator response separately.
How should acquisition, tracking, and control be staged?
Use the smallest chain that proves the end-to-end behavior. Keep sensor acquisition independent from tracking and motor control so each can be recorded and tested without the other. A Kalman filter is a later state-estimation step, not a substitute for timestamp quality or a working measurement stream. Add camera classification only after the sensing and control baseline succeeds; treat NPU classification as a second layer that can be evaluated without disrupting the real-time chain.
- Write acceptance requirements. Specify the target distance range, required measurement outputs, acceptable missed detections, and the motion or aiming behavior the demonstration must show. Do not use an unverified generic range estimate as the acceptance limit.
- Select one sensor path. For radar DSP learning, confirm access to useful signal data and the required interface. For LiDAR, confirm that distance data can support the intended target-position estimate. For HB100, constrain the initial objective to Doppler/motion exploration unless another ranging sensor is added.
- Prove acquisition without motors. Capture the sensor output, add timestamps, record interruptions or invalid samples, and visualize the measurements offline. This establishes whether the sensor and data path meet the requirements.
- Add basic target tracking. Start with a simple estimator and explicit handling for missed or noisy detections. Compare its output with logged measurements before making the estimator more sophisticated.
- Close the pan/tilt loop. Feed the estimated target direction or position into the control loop. Test motion and settling without camera classification, then record measurement-to-command latency and tracking behavior.
- Expand one capability at a time. Add radar DSP, richer spatial processing, camera classification, or NPU use only after the baseline remains observable and repeatable. Keep logs that allow offline replay when a new layer changes behavior.
Is STM32N6570-DK the right host?
It may be suitable later, especially if NPU inference is part of the project goal, but selecting it does not prove that the sensor interface or real-time workload fits. First establish the sensor’s output format, transfer method, data volume, and processing needs. Then benchmark acquisition and the initial processing path on the intended board. Compare the measured workload with the board’s available interfaces and processing resources before adding camera inference.
For an RTOS design, keep acquisition, processing, logging, and control responsibilities explicit. A queue or buffer between acquisition and processing lets the application detect overruns instead of silently losing measurements. Timestamp data at acquisition, not only when a later task processes it. Choose Zephyr, FreeRTOS, or another environment based on the project’s actual drivers and integration needs; an RTOS choice cannot compensate for an unsupported sensor interface or an underspecified sample stream.
How do you verify the tracker before adding classification?
Verification should prove each hop with the same target and operating envelope. Start with recorded sensor data, then verify extracted measurements, state estimates, and motor response in sequence. Use logging to replay failures offline and report measured latency rather than describing the system as real time without a measurement.
- Check that the sensor reports the required measurement type at the required distances; for range-rate, confirm that the measurement represents radial motion rather than assuming it is full target velocity.
- Inspect timestamped logs for gaps, stale samples, and inconsistent detection behavior. Compare plotted raw measurements with the tracker output.
- With the actuator disabled, verify that the estimated target state follows the recorded detections and handles missed measurements without an unexplained jump.
- Enable pan/tilt control and record the time from measurement acquisition to command update, along with whether the mount follows the target over the required motion.
- Repeat the test across the defined target-distance envelope, then save the logs, diagrams, failure cases, and measured latency as the baseline before enabling camera/NPU classification.
What do engineers ask about an RC radar tracker?
How do I choose FMCW radar or LiDAR for a flying RC target?
Choose FMCW radar when range-rate or radar DSP is a project requirement and the module exposes the data you need. Choose LiDAR when distance measurements are the priority and estimating motion from timestamped positions is acceptable.
Can HB100 measure the distance to an RC aircraft?
Do not use a Doppler-only HB100 setup as an absolute range measurement. Use it to explore motion sensing, or add a separate ranging sensor for distance.
How do I start learning radar DSP with an FMCW module?
Choose a module whose documentation states what raw or intermediate signal data it exposes. Begin with logged one-dimensional range or range-rate measurements before attempting point clouds.
Should I use the STM32N6570-DK for the first version?
First prove sensor acquisition, timestamping, basic tracking, and control on the intended hardware. Add NPU classification after profiling shows the sensing and control chain works.
How do I verify that the tracker is ready for camera classification?
Record timestamped measurements and demonstrate stable tracking and pan/tilt response across the required distance envelope. The final check is to save the logs and measured acquisition-to-command latency as the baseline before enabling classification.