Skip to content

Frequently Asked Questions

Emergency Braking System

Why are you using a pneumatic actuator for the braking system?

If we need a force of 100 kgf at a speed of 0.5 m/s the power requirement is roughly 500 W. An electric actuator capable of that is bulky and hard to source. A cable and pulley system with a motor and pressure feedback was considered, but cables cannot bend sharply. Since we already have a pneumatic piston from our sponsor Festo, it is the simplest solution.

Battery

Why is the battery placed at the back?

The rear of the kart offered the most practical space for such a large and heavy component. Because the seat, wheels and pedals remain in their original positions, placing the pack behind the driver was the best compromise. Handling is less of a concern since the kart will usually run autonomously without a driver's weight.

Motor choice

Why not use a thermal engine?

A combustion engine would add unnecessary complexity such as fuel, exhaust and cooling. Electric motors require little maintenance and are simpler to control electronically. Since this prototype focuses on sensors, actuators and software, the type of engine does not matter as long as the vehicle moves when throttle is applied.

Software

Can I develop on macOS natively instead of the UTM VM?

Partially. The 2D simulation and training pipeline (scripts/sim2d/) is pure Python (numpy + matplotlib) with zero ROS dependencies — it already runs natively on macOS. This covers GA training, visualization, imitation learning and all controllers.

However, the ROS2 and Gazebo parts (src/kart_sim/, src/kart_perception/, etc.) require Linux:

  • ROS2 Humble on macOS is Tier 3 (community/unsupported). Building from source is fragile, breaks often and many packages don't compile on Apple Silicon.
  • Gazebo Fortress is Linux-only in practice — no macOS packages, and the ign CLI and ros_gz_bridge won't build.
  • Robostack (conda ROS2) works for base ROS2 but lacks Gazebo Fortress packages for macOS.
  • Docker on macOS can run ROS2 but has no GPU passthrough and GUI tools like RViz require painful X11 forwarding.

Recommendation: Keep using the UTM VM for ROS2/Gazebo work. Do 2D sim training natively on Mac. The VM overhead only matters for the 3D simulation, which can't run on macOS anyway.

Why not skip the ESP32 and use the Orin's 40-pin GPIO header directly?

It could actually work, and it would simplify the architecture significantly. Here are the trade-offs:

Pros:

  • Eliminates the entire UART/protobuf comms layer between the Orin and ESP32 — no more serial debugging, protocol mismatches, or baud rate issues.
  • No more ESP32 flashing, crash loops, or boot-button gymnastics — one fewer device to maintain.
  • Faster iteration — change a Python file, restart the node, done. No cross-compilation or firmware uploads.
  • PID tuning from ROS — tune parameters with ros2 param set or dynamic reconfigure instead of reflashing.
  • The Orin 40-pin header has the necessary peripherals: 2 hardware PWM channels (steering servo + motor ESC), I2C (AS5600 steering encoder), and general GPIO.

Cons:

  • No real-time guarantees. Linux is not a real-time OS. The ESP32 runs a FreeRTOS task at a fixed rate with no GC pauses or scheduler preemption. On the Orin, PID loop jitter from userspace could cause steering oscillation. This can be mitigated with SCHED_FIFO priority and a tight C/Python loop, but it won't match a dedicated MCU.
  • No hardware safety watchdog. Currently, if the Orin kernel panics or ROS crashes, the ESP32 detects missing heartbeats and kills the motors. With Orin-only, a kernel hang means motors keep running at the last commanded value. This is relevant for Formula Student AS rules (EBS, ASSI).
  • Only 2 hardware PWM channels on the Jetson 40-pin header — just enough for steering + throttle, but no room for additional PWM peripherals.

Middle-ground approach: Simplify the ESP32 to a dumb I/O bridge — it receives PWM values over UART and applies them directly (no PID on the ESP32). Move the PID loop to a high-priority ROS2 node on the Orin. The ESP32 keeps only two jobs: (1) set PWM outputs, (2) hardware watchdog. This gives you fast iteration on PID tuning while preserving the safety watchdog, with minimal firmware to maintain (~100 lines).