Project
| # | Title | Team Members | TA | Documents | Sponsor |
|---|---|---|---|---|---|
| 39 | Rapid Adaptation Rover: Learned Dynamics Compensation for a Differential-Drive Robot |
Bhavya Agrawal Devansh Agarwal Srish Vijay |
Aniket Chatterjee | ||
| # Rapid Adaptation Rover: Learned Dynamics Compensation for a Differential-Drive Robot Team Members: - Bhavya Agrawal (bhavyaa2) - Srish (svija4) - Devansh (Da30) # Problem A mobile robot's response to its motor commands depends on physical properties such as vehicle mass, rotational inertia, motor strength, battery voltage, drivetrain resistance, and wheel-ground interaction. A controller tuned for one operating condition can therefore behave differently when these dynamics change. For example, adding payload changes the rover's acceleration and turning response. Increased resistance on one drive side can cause asymmetric motion and heading error. Battery-voltage variation or differences between the left and right motors can also change the motor effort required to achieve a requested speed. A conventional feedback controller can reject some disturbances, but fixed controller gains may produce substantially different transient performance as the physical system changes. In many systems, the controller also has no direct information describing which physical parameter changed. Our project will investigate whether a rover can instead infer information about its current dynamics from its own recent measured behavior and use that information to improve control. The deployed controller will not be told that a payload was added, that one motor became weaker, or that additional drivetrain resistance was applied. It will only observe signals physically available onboard, including previous motor commands, wheel velocities, IMU measurements, motor currents, and battery voltage. The primary engineering question is: **Can a learned controller that estimates a useful dynamics representation from recent onboard measurements improve motion tracking under changing operating conditions compared with a well-tuned fixed-gain controller and the same learned policy without adaptation?** # Solution We will design and build a two-wheel differential-drive rover containing: 1. Two encoded brushed DC gearmotors and an 80 mm wheel drivetrain. 2. A custom STM32-based motor-control and sensing PCB. 3. Onboard current, encoder, IMU, and battery-voltage sensing. 4. A Raspberry Pi 4 executing a learned controller. 5. A simulation and training pipeline for learning dynamics-dependent control behavior. 6. Repeatable physical disturbance mechanisms for quantitatively testing adaptation. The custom PCB will be the real-time interface between the physical rover and the learned controller. It will independently drive both DC motors, acquire both quadrature encoders, acquire IMU data, measure each motor current, measure battery voltage, enforce safety limits, and transmit timestamped telemetry to the Raspberry Pi. The Raspberry Pi will run a learned policy based on a two-stage privileged-training architecture. During simulation training, physical parameters such as rover mass/inertia, left and right motor effectiveness, drivetrain resistance, battery voltage, sensor errors, and delays will be randomized. A privileged encoder will have access to these simulated parameters and produce a compact dynamics representation. A control policy will learn to use this representation together with the current state and requested motion to generate left and right motor commands. For deployment, the true physical parameters will not be available. A second neural network, the **history encoder**, will infer a dynamics representation from approximately the previous 30 policy timesteps of measurements and applied motor commands. The policy will then use this inferred representation to modify its motor commands. The deployed system will contain no explicit disturbance-specific rules such as: - "if payload is added, increase PWM," - "if current exceeds a threshold, switch controllers," or - "if the right motor is weak, compensate by a fixed amount." The network weights will remain fixed during testing. Adaptation will occur because the rover's recent sensor/action history changes, producing a different inferred dynamics latent. The rover will initially operate indoors on a level, dry floor. The target command envelope is approximately 0–0.20 m/s forward speed and up to approximately ±1 rad/s yaw rate, subject to the validated motor operating range. The learned controller will initially run at 50 Hz using a 30-sample history corresponding to approximately 0.6 seconds. The core disturbances will be: - removable payload of approximately 0.25 kg and 0.50 kg, subject to motor-load testing, and - repeatable asymmetric mechanical resistance applied to one drive side. A combination of payload and asymmetric resistance will also be reserved as a held-out physical test condition. # Solution Components ## Subsystem 1: Custom Motor-Control and Sensor PCB The major circuit-level hardware component of the project will be a custom PCB centered around an **STM32G431CBT6** microcontroller. The PCB will be responsible for: - independent bidirectional control of two brushed DC motors, - quadrature encoder acquisition, - IMU acquisition, - independent left/right motor-current measurement, - battery-voltage measurement, - power distribution for low-voltage electronics, - timestamped communication with the Raspberry Pi, - command limiting, - driver-fault monitoring, - watchdog behavior, - and emergency motor disable. Major components will include: - **STM32G431CBT6** microcontroller - **2x Texas Instruments DRV8874** brushed DC motor drivers - **2x Texas Instruments INA240A1** current-sense amplifiers - **2x 33 mΩ, 1%, ≥1 W current-sense shunt resistors** - **SN74LVC14A** encoder-interface/Schmitt-trigger IC - **TDK ICM-42688-P** six-axis IMU - **TLV75533P** 3.3 V regulator - battery-voltage resistor-divider and ADC interface - main fuse, power switch, reverse-polarity protection, decoupling, connectors, and protection circuitry Each motor will use an independent DRV8874 H-bridge. The initial hardware peak-current limit will be approximately 1.2 A per motor, with an additional lower sustained-current limit and stall timeout implemented in firmware. The INA240A1 channels will independently measure signed motor current. With a 33 mΩ shunt and gain of 20 V/V, the current-sense output will be centered near half of the 3.3 V ADC range to permit measurement of positive and negative motor current. The STM32 will generate motor PWM at an initial target frequency of 20 kHz. Wheel-speed estimation and safety checks will run at approximately 1 kHz. Telemetry will be sent to the Raspberry Pi at approximately 100 Hz. Communication between the STM32 and Raspberry Pi will use 3.3 V UART with packet framing, timestamps, sequence numbers, and error checking. If no valid motor command is received for approximately 100 ms, the STM32 will disable both motor drivers. An independent MCU watchdog and a hardware emergency-stop path will provide additional protection. The PCB will also include SWD programming access, reset circuitry, test points, and required supply decoupling. ## Subsystem 2: Differential-Drive Actuation and Mechanical Platform The rover will use two **Pololu #4866 75:1 Metal Gearmotor 25Dx69L MP 12 V with 48 CPR encoders**. The selected motors have approximately 100 RPM no-load output speed at 12 V and use 4 mm D-shaped output shafts. The drivetrain will use: - **2x Pololu #4866** encoded 12 V gearmotors - **Pololu #3690** 80×10 mm multi-hub wheel pair - **Pololu #2676** 25D gearmotor bracket pair - passive caster - rigid rover baseplate - secure battery mount - removable payload mount - adjustable mechanical-resistance fixture With 80 mm wheels and approximately 100 RPM no-load motor speed, the theoretical no-load rover speed is approximately 0.42 m/s. Our initial maximum commanded speed of 0.20 m/s intentionally leaves substantial margin below this value. The motors have a manufacturer-listed extrapolated stall current of approximately 1.8 A. Stall operation will not be treated as a normal operating point. Continuous motor-current limits will be determined experimentally using thermal testing before final disturbance magnitudes are selected. The removable payload will be mechanically secured to the chassis. Payload location will remain fixed between comparable trials because payload placement affects both total mass and rotational inertia. The asymmetric-resistance fixture will apply repeatable additional mechanical load to one drive side without requiring any change to software or controller parameters. ## Subsystem 3: Proprioceptive Sensing The adaptation algorithm will only use signals that exist on the physical rover. The available observations will include: - left wheel velocity, - right wheel velocity, - three-axis acceleration, - three-axis angular velocity, - left motor current, - right motor current, - battery voltage, - previous applied left motor command, - previous applied right motor command, - commanded forward velocity, - commanded yaw rate, - and command-limiting indicators. The two motor encoders require a supply above 3.3 V and will therefore operate from the 5 V rail. Their four quadrature signals will pass through an **SN74LVC14A** operated at 3.3 V before reaching STM32 timer inputs. The **ICM-42688-P** will operate from the 3.3 V supply and communicate with the STM32 using SPI. The IMU provides acceleration and angular rate; it will not be treated as an absolute-heading sensor. Motor currents will be measured using the **INA240A1** amplifiers and 33 mΩ shunts. Current acquisition will be synchronized with PWM to reduce switching-related measurement error. Battery voltage will be measured through an appropriately scaled resistor-divider circuit connected to an STM32 ADC input. The STM32 will transmit both the requested and the **actually applied** motor command so that the adaptation algorithm accounts for any saturation or safety limiting applied by the motor-control board. ## Subsystem 4: Power and Safety The rover will use a **Bioenno BLF-1203AB 12 V-class 3 Ah LiFePO4 battery pack** with its matched **Bioenno BPC-1502DC external charger**. The battery includes an internal protection system and has a manufacturer-listed maximum continuous discharge capability of 7 A. The power architecture will be: Battery → fuse and main switch → protected battery bus The protected battery bus will then supply: 1. the two DRV8874 motor-driver channels, and 2. the 5 V compute/electronics regulator. A **Pololu D24V50F5 (#2851)** regulator will generate the 5 V rail for the Raspberry Pi and supporting electronics. A **TLV75533P** regulator will generate the 3.3 V rail used by the STM32, IMU, current-sense circuitry, and encoder interface. Because a fully charged LiFePO4 pack exceeds the motors' nominal 12 V rating, the STM32 will implement a voltage-aware duty limit so that the approximate average commanded motor voltage does not exceed 12 V. This will operate in addition to current limiting and does not replace current protection. The design will include: - main fuse, - reverse-polarity protection, - adequate bulk and local decoupling, - voltage-rated capacitors, - driver current regulation, - sustained-current monitoring, - stall timeout, - command saturation, - communication watchdog, - MCU watchdog, - driver-fault monitoring, - and a latching emergency-stop circuit that disables both motor drivers independently of Raspberry Pi software. The Raspberry Pi supply will be load-tested during simultaneous processor load and motor startup/reversal to verify that motor transients do not cause compute resets. ## Subsystem 5: Onboard Compute and Learned Controller A **Raspberry Pi 4 Model B with at least 2 GB RAM** will run the learned adaptation and control networks. The policy will update at an initial target rate of 50 Hz. The deployment system will contain two learned components: ### History Encoder The history encoder will initially receive approximately the previous 30 controller samples, or 0.6 seconds of history. Its inputs will contain recent onboard measurements, previous applied motor commands, and requested motion. The encoder will output a compact latent vector representing information about the rover's current dynamics that is useful for control. ### Control Policy The control policy will receive: - the current observation, - commanded forward velocity, - commanded yaw rate, - and the inferred dynamics latent. It will output normalized left and right motor-duty requests. The networks will initially use compact multilayer neural-network architectures. Inference will be benchmarked directly on the Raspberry Pi with a target execution time below 10 ms per 20 ms policy interval. Network weights will remain frozen during the physical evaluation. The system therefore adapts through its sensor history and inferred latent rather than through online weight updates or manually selected controller modes. ## Subsystem 6: Simulation and Training Training will be performed offboard using **Isaac Lab** on a GPU workstation. The simulation will model the physical command-to-motion dynamics of the rover rather than using ideal wheel-velocity actuators. The simulation will include: - rover rigid-body mass and rotational inertia, - wheel geometry, - ground interaction, - brushed DC motor behavior, - gear reduction and effective transmission loss, - driver saturation and current limiting, - battery-voltage variation, - encoder quantization, - IMU bias/noise, - observation filtering, - and command/communication delay. Before training, we will characterize the physical rover by measuring quantities such as: - speed versus motor duty, - motor current response, - acceleration, - coast-down response, - and communication delay. These measurements will be used to construct the nominal simulation and determine realistic randomization ranges. Training will randomize: - rover mass and inertia, - independent left/right motor effectiveness, - rolling/drivetrain resistance, - battery voltage/effective supply loss, - sensor errors, - and communication/observation delay. The first training stage will use privileged simulation parameters to produce a dynamics latent. The control policy will be trained to use this latent. A deployment-side history encoder will then be trained to reproduce a useful dynamics latent using only the onboard observations and recent actions that will exist on the real rover. The initial history length will be 30 samples at 50 Hz, and the initial latent dimension will be eight. The deployed controller will receive no payload mass, disturbance label, motor-strength parameter, resistance value, or external position measurement. ## Subsystem 7: Baseline Controllers and Experimental Evaluation We will compare three controllers: 1. **Conventional baseline:** fixed-gain wheel PI control with feedforward and anti-windup. 2. **Fixed-latent learned policy:** the same learned policy used for adaptation, but with its dynamics latent held at a nominal constant value. 3. **Adaptive learned policy:** the learned policy supplied with the latent produced by the onboard history encoder. The conventional PI controller will be tuned normally on validation trials and then frozen. It will not be deliberately detuned to make the learned controller appear better. All controllers will use: - the same physical rover, - the same sensing calibration, - the same safety limits, - and the same command trajectories. Primary experiments will include: - forward-speed steps, - acceleration/deceleration sequences, - constant-speed motion, - yaw-rate steps, - curved trajectories, - and combined forward/turning motion. Dynamic tests are important because added mass may have little effect on steady-state velocity after feedback has converged. The two primary physical disturbances will be: 1. removable payload, initially 0.25 kg and 0.50 kg, subject to motor-current and thermal limits; 2. repeatable asymmetric mechanical resistance on one drive side. We will additionally reserve a combination of payload and asymmetric resistance as a held-out test condition. An independent overhead camera observing a marker on the rover will provide reference position and heading during evaluation. The camera will only be used for measurement and will **not** provide observations to the deployed controller. The primary quantitative metric will be externally measured forward-velocity RMSE. Secondary metrics will include: - yaw-rate RMSE, - relative heading error, - peak transient error, - recovery time, - RMS motor current, - time spent in actuator saturation, - policy execution time, - and missed control deadlines. Each controller-condition combination will be repeated multiple times, with a target of at least ten trials per condition. Battery voltage and motor temperature will be recorded, and test order will be randomized or counterbalanced. # Criterion For Success The following criteria are designed to be objective and directly testable. 1. **Custom PCB functionality** The custom PCB must simultaneously: - control both DC motors, - read both quadrature encoders, - acquire ICM-42688-P IMU measurements, - acquire independent left/right motor-current measurements, - measure battery voltage, - enforce motor-current and command limits, - and transmit timestamped telemetry to the Raspberry Pi. 2. **Real-time embedded control** The STM32 must reliably execute motor PWM, sensor acquisition, wheel-speed estimation, communication, and safety functions simultaneously during rover operation. 3. **Onboard learned-controller execution** The Raspberry Pi must sustain the learned policy/history-encoder loop at **50 Hz for at least 10 minutes** without missed control deadlines. 4. **Conventional rover control** The rover must demonstrate stable forward-speed and turning control throughout the experimentally validated operating envelope using the conventional PI controller. 5. **Repeatable physical disturbances** Added payload and asymmetric drivetrain resistance must produce repeatable and quantitatively measurable changes in the rover's physical response. 6. **Demonstration of history-based adaptation** The deployed adaptive controller must operate without receiving payload mass, disturbance identity, drivetrain-resistance value, motor-strength parameters, or external tracking information. The same frozen policy and history encoder must be used across all physical disturbance tests without manually changing gains, thresholds, or disturbance-specific control logic. 7. **Adaptation benefit** Our target is for the adaptive learned controller to reduce the primary forward-velocity RMSE by at least **25% relative to the fixed-latent version of the same learned policy** under each primary disturbance. We will additionally target at least a **10% reduction in forward-velocity RMSE relative to the tuned PI baseline without more than a 10% degradation in yaw-rate RMSE**. 8. **Held-out combination test** The frozen controller must be evaluated on a predefined combination of payload and asymmetric resistance that was excluded from controller tuning and from the set of predefined physical test cases. No disturbance label or test-case identifier may be supplied to the controller. 9. **Recovery measurement** For an in-motion resistance change, recovery time will be measured from disturbance onset until: - forward-speed error remains within 0.02 m/s, and - yaw-rate error remains within 0.10 rad/s for at least 0.5 seconds. These thresholds will be verified against sensor noise and frozen before final testing. 10. **Communication and safety** If no valid command is received from the Raspberry Pi for 100 ms, the STM32 must disable both motor drivers within the timeout plus one firmware service interval. The hardware emergency-stop circuit must also disable both motor drivers independently of Raspberry Pi software. 11. **Quantitative final demonstration** The final demonstration must show the same physical rover performing comparable trajectories with: - the conventional PI controller, - the learned controller without adaptation, - and the learned controller with history-based adaptation. We will present commanded versus measured motion, motor commands, motor currents, tracking error, recovery behavior, saturation information, and controller timing so that the effect of learned adaptation can be evaluated quantitatively rather than visually or through inspection of software. |
|||||