Tucker’s Intelligent Torque System
4wd torque vectoring for Ankle Wreacher
Strap in for a long and technical thread.
Legal
I have and am putting a lot of work and money into this project, and plan on sharing a lot here. I’m not a litigious person, but I want to add this legal disclaimer for some CYA.
The contents of this post and subsequent posts by @tuckjohn is is licensed under CC BY-NC-SA 4.0
I started this project back in July 2024, and it’s still far from completion
(mostly through my own lack of controlling project scope 
)
Scope has grown to include:
- Tire temperatures
- Live display
- Data logging
- Data analysis
With the goal to eventually add:
- Torque Vectoring
- Rudimentary on-track interface
- Traction Control
- Antilock braking
- Speed wobble dampener
- Tire Forces
I’ve been teasing progress in the Ankle Wreacher thread… but it’s reached a point where I can share this journey with y’all. Below is a summary of the last 16 months:
The idea
- Sensors across board capture the board state, most notably truck angle(s)
- “Arduino-like microcontroller” reads from the sensors and receiver input
- “Arduino-like microcontroller” does calculations based on sensors and receiver
- “Arduino-like microcontroller” sends commands to VESCs to control the motors
The Start… TITS Main PCB V1.0
First hardware prototype iteration had some good ideas, and other bad ones.
Development of V1
Hand assembled Custom PCB
Full assembly. Has a Teensy 4.1 for the main brain, ESP32c3 for display drawing, and second ESP32c3 as a vesc express.
The PCB was designed to fit inside the bellypan
Screen mounted up front with the MEGAN display
Picture of all the required wiring for V1 (after I pulled it out to upgrade to V2)
Testbench for Development
V1 taught me how much software work was required for this project, I needed a testbench where I could test experimental code without affecting my raceboard.
I bolted a bunch of spare parts to an old 3D printer frame to make a fully electrically representative skateboard.
Later on, tired of how much desk space it used, I screwed everything to the bottom of my lofted bed.
This has been invaluable for my software development efforts.
Truck angle Sensor
With the main goal of this project being torque vectoring, measuring rider intent is paramount. Truck angles is the best proxy for desired turning radius, so opted to measure this to calculate the angle of turning;
- Accelerometer? → To hard to reliably remove environmental factors and noise
- Potentiometer/Encoder/RVDT? → Requires complex linkage geometry that I don’t have space for
Ended up using a magnet-based option. Specifically, I’m using a 3-axis magnetometers on the front and rear trucks.
Some magnets (in a 3D printed holder) are epoxied to 3-link hym
Then, using two extra collars mounted to my hanger, a custom magnetometer PCB is mounted directly above them
First test of the system proved very promising (graph showing XYZ magnetic field strength).
I’ll definitely post more information about the algorithm I came up with to convert this XYZ magnetic field magnitudes to deck angle/turning radius in the future, it’s quite complicated (probably more then it needs to be lol)
This PCB has gone through numerous revisions, fixing issues and changing the system architecture.
I anticipate doing another soon for reasons
Tire Temperature Sensors
Originally, I added these for the meme. However, I’ve found them to be invaluable while racing.
To measure my tire’s temperature, I use 4x MLX90614-BCC sensors.
I choose these because they’re readily available, cost-effective, and work decently enough.
These sensors are readily available soldered to this sensor breakout PCB. My first revision just used it directly by mounting to a 3D print, which then bolts to tapped holes in the motor mount plate.
First trials with them proved to be plenty accurate
After lots of problems with these breaking, I designed a custom PCB that allows for a beefier mount.
These have allowed me to do some cool stuff, like testing experimental tires here.
Can’t imagine having a raceboard without live tire temperature feedback now.
TITS PCB V2
V2 was a ground-up architecture redesign of V1. It copied what worked, and changed what didn’t.
Most notably was the location. By locating it directly under the MEGAN, it:
- simplified some wire routings and harness construction
- Lifted it out of the bellypan, where stray rocks were starting to cause PCB damage
- Wider PCB was easier to layout/route
I built two systems. One got installed onto Ankle Wreacher, the other was assigned to the testbench for software development (with a matching copy of sensor PCBs).
Installed on Ankle Wreacher. My board has a comical amount of wiring.
V2 Bus architecture
Here’s where thread gets technical “How is everything connected?”
This is my system architecture at the moment (subject to change as the project progresses, obviously)
My magnetometer and tire temperature sensors are on an I2C bus.
I2C bus design notes
Using an I2C bus for the sensor communication isn’t ideal. I2C was designed to be protocol that exists entirely on-PCB, and never more then a meter long. My bus goes across 7 custom PCBs, and is about 1.5m long, in a very EMI noisy environment.
Despite this, I decided to use I2C for two reasons
- It’s a protocol that a lot of hobby-grade sensors use
- All sensors can share the same wires (ex. SPI would require a separate CS wire for each sensor)
To protect signal integrity against EMI, everything is run through shielded wires. However, this greatly increases the bus capacitance/impedance, which reduces max clock rates because I2C is a open-collector and relies on pull-up resistors to reset the bus. Great TI application note on the topic
In future revisions, I’d like to incorporate I2C Redrive buffers to help with signal integrity.
I originally tried solving this with a PGA9615, which is a software-transparent solution that reencodes the I2C signal as a higher voltage differential signal (which can be de-coded at the other end)
However, PGA9615 was never very reliable, frequently failing on me. To get a system that worked, I just bypassed them and used some much stronger (low resistance) pull-up resistors. This resolved issues, but requires sensors/microcontrollers to work a lot harder to pull the bus low (lot more current). I’m surprised that I haven’t burned anything out yet 
In future revisions, I’d still like to incorporate a I2C buffer to help with signal integrity. In hindsight, the PGA9615 was complete overkill and a more “normal” i2c buffer like P82B715 or similar would be fine
The Teensy 4.1 does all the sensor/vesc communication, relevant calculations, data logging, etc.
The Teensy 4.0 is a overqualified GPU. The much shorter distance to the display on V2 allowed for much faster communication, allowing higher framerates (~22fps atm)
Interfacing with the VESCs is done directly over the CAN bus, with a custom CAN library that I wrote. This utilizes the Teensy’s internal CAN controllers, allowing for very low overhead communication (Low latency and FAST!).
Isn't this just a copy of Radium RTS?
Inevitably what I’ve built here is going to be compared to Radium’s RTS system that ships with the Mach One. TITS and RTS are similar at a high-level, but I hope this thread is proof enough that this is not a reverse-engineered clone of RTS.
- Entirely different system architecture
- Entirely different hardware (including individual components)
- Slightly different truck sensing method/algorithm
- Live display feedback
- SD Logging
- Tire temperatures
Additionally, the RTS system has features that I don’t like
- Much simpler for an average user to use/tune (just not something that I’m optimizing for)
- More cost optimized
Radium, you do cool stuff, love you guys
Everyone go buy motors from them
Logging infrastructure
Given that this is an experimental system, I need to log everything possible for post-race analysis and system debugging.
However, to allow for my TITS control loop(s) to run at as high frequency as possible, I needed to reduce the processing overhead for logging to be as low as possible.
Highly technical exploration of the infrastructure I've built
On a hardware level, a Teensy 4.1 supports QSPI, where it writes to the SD card with a 4-bit bus which is ~4x faster then SPI (1-bit bus). (I’ve also gotten a U3 rated SD card, just to ensure it’s not a bottleneck)
On a software level, I went way overboard
In previous Arduino projects, I’ve formatted the data into a CSV format, then appended the CSV-formatted string to the end of the log file.
However, this was relatively computationally and memory hungry. Additionally, every additional byte of information written to the card increases the write-time, which will decrease how fast I can run TITS (because Teensy’s are single-threaded).
Say I have a integer variable containing the number 433312. Instead of formatting and writing the string “433312,” (7 bytes), I can write the raw binary 0x00069CA0 (4 bytes).
A binary(.bin) file! Incomprehensible, but very information dense.
For example, these 4 bytes contain the milliseconds since powered on. 5203ms
To do anything with this data, it need to be post-processed, parsing the raw binary into separate variables. This requires the paser to knowing the number, order, and types of data in the binary file.
So naturally, I also wrote a custom matlab parsing script.
I could’ve hard-coded my parsing script with my known format, but I expect this format to change as I develop the system, add variables, etc. I definitely don’t want to need to change my parsing script every time I do this;
- Would make updating TITS source code take more work, and take away focus from what I would actually be trying to update
- Updating the parsing script would make it unable to parse older log files that use an older format. Strict version control to preserve this would be more annoying and take extra work.
So, upon board startup, TITS creates a “spec” plaintext file(.txt) that contains all information necessary for parsing the Binary file (.bin).
(I also use the Teensy’s onboard RTC clock to name the files with a datetime when they were created, really helps with usability and identifying the right log file)
The contents of this spec file is automatedly generated with a custom python script at source code compiling.
This spec file is automatically found and used by my Matlab parsing script, which uses it to dynamically parse the data into Matlab variables, ready for graphing/export/other dushbaggery.
All of this happens entirely transparently and automatically. My TITS source code can change, and my Matlab parsing script automatically adjusts to compensate 
With this infrastructure up, I’ve got tons of cool graphs of data! Right now I’m able to get 50~100Hz data, and definitely will be sharing more as this thread goes on.
For starters, check out this one of my 4 tire temperatures. You’re able to see the ~40s laps just because of the tires cooling on the straightaway 
Misc steam deck
In addition to my desktop, I got my development environment set up on my steam deck so I can do mobile development/code updates. Should be useful if I ever need to modify code or look at data at a race event.
This post is an overview of what I’ve already achieved, but this is obviously a WIP project.
I’ve got a hardware revision in the works (with more features!) and lots of software still to write.
More to come!
