Let's Make Robots!

T'REX robot controller


The T'REX robot controller makes controlling robots easy!

The Arduino compatible controller comes pre-programmed with sample code that lets you control it with a supplied Android app, Radio Control or with an external controller via I²C.


  • Wide voltage range from 6V to 30V.
  • High current power switching FET (110A) allows low current power switches to be used.
  • Switch mode regulator with 6V @ 3A output for servos.
  • ATmega328P MCU using Arduino Nano w/ 328 bootloader.
  • 5V regulator can deliver in excess of 2A for powering external controllers such as the Raspberry Pi, Beagle bone etc.
  • I²C interface with voltage translation can work with external logic from 1.5V to 5V.
  • Can be programmed via USB, FTDI interface or ISP socket.
  • Socket for optional Bluetooth module.
  • Dual FET "H" bridge with electronic braking rated for stall currents up to 40A per motor.
  • PTC self resetting fuses for each motor.
  • 4x servo outputs with 6V power in high voltage mode or direct from battery in low voltage mode.
  • 2x servo headers at 5V that can also be used for RC inputs or encoders.
  • 3-axis accelerometer (±1.5G or ±6G sensitivity) for impact detection, angle and acceleration measurements

The supplied sample code automatically detects the method of control (RC, Bluetooth or I²C) on power up. Bluetooth and RC methods offer quick, easy methods of testing your robot chassis.

The I²C mode offers complete control of all function using only 2 I/O pins making it a perfect choice for interfacing 32bit controllers such as the Raspberry Pi to your robot.

You can download the instruction manual from here:


Please make sure you read the manual before asking questions!
I may have answered your question already so make sure you read the other questions posted here first.

If you have a question then ask it here so everyone can learn. Do not email me because then no one else can read the question or the answer.




Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hello All,

I was wondering if anyone had schematics available for the T'Rex Controller? I'm experiencing some issues with my board and I would like to and diagnosis it before sending it back to SparkFun.




I'm sorry but at this time I cannot give out schematics.

Start a forum post and explain the problem in detail. Include good quality photos of your setup.

I have only built 1 balancing robot. Unless your a clever mathematician then you won't succeed with an acelerometer alone because when you move to correct the angle you need to then know how hard your accelerating to compensate for your compensation.

I found you needed a gyro sensor to measure the rate that the robot is tilting at and then just use the accelerometer to check the angle when rotation is near 0 otherwise the robot tends to fall over very slowly or constantly roll forward/backward depending on the gyro sensitivity.

At this point I will remind you I am not a mathematician nor an expert on balancing robots, I speak only from limited experience.


Though I can usually follow a written paper if the variables are defined.

I was hoping that the accelerometer in the TRex controller was good enough that I wouldn't need a gyroscope. I have an Accel/Gryo/Mag that I want to use for this. I can run it off if I2c.

I'm first going to try this with the TRex. If that is't fast enough, then I'll try a Teensy 3.1 handling the control code and the TRex handling the motor code. If that isn't enough, I'll write custom code so I can send much smaller packets.

I plan on using a complementary filter for the gyro/accelerometer, with a kalman filter dealing with the entire mess. In addition there are the wheel encoders and the control design is actually 3 PID loops.

Basically I need 50-100 Control cycles per second with the ability to change the motor's torque as quickly as possible.

Does this sound reasonable?

Your problem will not be the controller speed. It only takes about 780uS to read all 3 axes of the accelerometer. The problem you will face with an "Accelerometer Only" setup is compensating for the robot's change in acceleration as it moves to correct it's balance so that you can get accurate information about the angle of the robot.

The data from the accelerometer will be a combination of acceleration due to gravity and acceleration due to movement. The advantage of a gyro is it is not affected by the robots acceleration, only the change in angle.

Agreed. I would be reading from my external IMU (OK, accellerometer/gyroscope/magnetometer thing) via I2C so that I get the same reading. I'm worried about the ability of the inner Arduino to be able to do that many floating point calculations quickly enough.

From my reading, the motors should be updated somewhere between 50 and 100 Hz, depending on the quality of filtering. Though if it falls too far, all the updates in the world won't help you and may just slam it into the floor a bit faster. And yes, I intend to make a blooper roll if I can get enough light into my basement.

Balancing on an arduino uno (so same chip as here really) has been done before no problem.

It shouldn't be a problem. However, the videos I've seen where they balanced well and moved well used a bit more horsepower.

Of course, I haven't seen all the videos or even heard of all of the balancing bots around.

All of the algorithms I'm choosing require heavy use of floating point math. The algorithm I'm going with for now involves a complementary filter, a kalman filter, and three PID controllers. Unfortunately I don't know enough about PID controllers or filtering to know if I need all of these yet. I will have to test things as I go and find out. Once I get this running on the Teensy 3.1 I will work on putting the sketch onto an Arduino Uno and see if it can handle it fast enough.

My guess is that it would require two Arduinos: one to filter the data and one to run the control algorithm. However, I'm hoping I'm wrong.

The only balancing robot I made used no floating point math or fancy algorithms. In the end the motor output was just a linear response to Gyro output with and offset determined by the accelerometer.It was admittedly clumbsy but it did work as you can see in this video: https://www.youtube.com/watch?v=UxksujPGXyw

I left the fancy math for the University teachers who ordered it.

That balancer seemed pretty darn good to me.

It did the spin test which is where a lot of them fail.

I'd love to see the code that ran that, because it worked and worked well. What processor did you use?