Rethinking the World

A TIGO Build Log: Part Inspiration, Part Guidance, Part “Look What You Can Do With Almost No Money.”

Back in 2014, small UGVs were finally becoming accessible to researchers, but the good platforms were still wildly expensive: metal chassis, heavy motor blocks, real suspension systems, high-capacity packs… great gear, but nowhere near the reach of a hobbyist with maybe a $50-100/month parts budget.

So I started doing what any stubborn builder does, I scavenged, to build a decent sized rover that would carry substantial payloads, be able to run for very long periods of teleoperated and autonomous times, and be able to handle aggressive terrain.

And the result, after mistakes, experiments, hacksaws, hot glue, aluminum stock, and a Walmart toolbox, became TIGO V2, a tough little rumble rover that wasn’t pretty, wasn’t meant for magazine covers, but absolutely crushed those tiny “robot kit” bodies that barely survive an afternoon indoors.

This isn’t a step-by-step. This is “here’s the pattern, here’s the mindset, build yours from whatever junk you can find.” One person’s junk is another person’s…

Finding the right donor vehicle

My goals and requirements at the time were simple:

• Build a basic rover that could carry 20 pounds or so of the body, equipment, control systems and useful payloads
• Have true remote range that would allow operation from a base station anywhere
• Durable enough to weather the elements and falls
• Enough traction and designed suspension to handle rough terrain
• Power system that would usefully last for extended time ranges and be able to be replenished by solar panels and other means

I was looking for something more akin to a proper platform and not just an RC car with a camera. But just the physical chassis, motor and suspension requirements alone meant either investment of parts, tools, and prototypes, or finding ready made parts to more quickly get through the vehicle build and onto controls and development.

Let’s say you don’t have ready to go motors, suspension, gear and transmission manufacturing capabilities at home, and you want to find a prebuilt solution as the “go” part of your small robot rover, that you want to connect to a control and motor controller system, and get right at developing. An easy choice is a donor RC vehicle to take apart and build with, but which kind? It’s important to think about, how will the rover drive? That will determine, for you, what the best choice is in a donor vehicle.

In terms of steering and build type, I dislike Ackermann steering for robots (the familiar ‘car’ steering method). Maybe it’s because I’m not great at driving RC cars, especially growing up. As a remote operater, as soon as it gets turned around I’ll pause, look at it for a while, then flip the steering in my head to try and back up, promptly realizing I overthought it, and watch it crash the other way. And as I found out with TIGO V1, you have to have a lot of extras when it comes to programming for Ackermann steering, sensors, encoders, positionals… just for the steering part. TIGO V1 was fun… but was not looking forward to teaching those tricks to a larger body that wasn’t going to go that fast. And most of the UGV platforms out there I was looking to emulate didn’t go that route either, and totally makes sense from a long range teleoperated platform.

There’s other steering methods for platforms, especially nowadays with omni wheels. Here’s a great resource on steering theory for robots.

My personal choice, and an effective one for this size of a rover, is tank type driving (or skid steering), where the wheels on one side move one way, as do the others. Both sides roll forward, it goes forward, and reverse. Left and right is when they spin opposite of each other. This is an extremely simple way to think about constructing a small rover, as it alleviates a lot of overhead in steering control between sending instructions, and the rover reliably doing it, and receiving back confirmation it did it.

Skid steering, like a tank, is plain, simple, but a power hungry beast as it relies on friction of the counter rotating wheels on each side in order to turn left and right (when doing stationary rotation – you can get a little directional change if one side is moving faster than the other for changes in forward direction while moving, but for hard, proper turns to rotate the rover into an orientation to a path, it will need to counter rotate). It does require some planning on traction, wheel spread, chassis height, and a host of variables so you don’t have a brick on some wheels that can barely turn.

So if you decide (as I did) that the simplicity that skid steering offers is right for an intended larger build, then many RC cars will not be able to work for your needs. And you won’t be able to ‘get a power wheels and just RC / computer it’, unfortunately (though I did much later for a fun build) because most power wheels are steering type affairs. Though, there may be some now ‘tank type’ products, but with a child passenger and that size of a body, the power requirements alone would be more in the range of a small ATV cost wise. I spent quite a while looking for ‘buy a tank’ options for $200 that aren’t teeny, and most would not fit in the budget constraint and size/power needed for a basic 20 pound total weight. But, what if someone else had already figured that out for you? What ultimately changed the game for me wasn’t a fancy robot kit, it was a cheap, suprisingly large RC truck from Walmart.

• oversized soft foam tires
• simple plastic suspension
• surprisingly punchy 9.6V packs
• and most importantly: dual-side drive trains

This last part is huge, because it meant I could ditch Ackermann steering entirely.

Skid-steering solves so many headaches for early robotics builders, especially before you dive into encoders, IMUs, and path-correction math. With the donor truck, each side already had its own gear train, perfect for independent left/right control.

So after some experiments with the donor vehicle narrow build and being top heavy, I proceeded to tear it apart.

Cutting the Chassis and Keeping What Matters

After peeling the shell off and removing the stock electronics, I was left with the suspension arms and the dual gearmotor assemblies. Honestly, I could’ve removed the arms and motor, cut the body in half, bolted these straight to a plywood box and called it a day. Though plastic gears make up the drive gearing down to the oversize foam tires, the motor is high torque with nice metal gearing. It makes for a decent, singular drive arm that’s terrain adaptive, with ‘suspension’ mount points (Ok, plastic forks with springs, but you know what? They’re not bad.)

But I wanted balance, space for batteries. A body that would protect electronics while still being serviceable.

Perfect size, a central handle, built-in compartments. And strangely enough, a pretty nice aesthetic for a rover hull when looking at it in person. Why not build up from scratch? This was 2014 and I didn’t have a 3D printer, serious tooling more than a dremel and woodworking tools, and I needed a light weight, but tough body. It did the job, and Stanley is a great brand.

Making a Real Chassis From Cheap Hardware Store Parts

The goal: widen the stance, mount the gearbox halves, and create a flat, durable surface for the toolbox hull. So I grabbed:

• cheap aluminum stock from Lowe’s
• a handful of bracket strap
• PVC pipes for wire routing and mounting posts
• epoxy, screws, bolts, zip ties, the classics

This gave me a lightweight but rigid rectangular frame to connect both halves of the drivetrain together. Instead of completely removing the drive arms and suspension, I cut the outer edges of the original chassis, to leave mount points and preserve the ‘suspension’, and conveniently used shaped plastic areas for attaching the aluminum and PVC mounting points.

Then I mounted the toolbox on top, threaded the wires through PVC conduits, and reinforced the body so it wouldn’t flex while crawling over rocks, snow, or frozen dirt.

The final shape wasn’t a thin rectangular pseudo monster truck that was more inline with an Ackermann design, and that squandered rotational skid steering on (and counted on an ultralight body and low slung battery to make up for). It was a more balanced, wider rover frame that came fairly close to optimal footprint design and still preserved the original truck’s weight distribution, critical for skid-steer drivability.

The big, empty toolbox in the middle was an excellent, watertight bay for payloads, and since the battery systems were side saddled over top of the motor and gear boxes, meant I had a huge (relatively) space for control systems and payloads. One of the earlier mission payloads I put in was a ground metal detector to scan down as the rover drove over areas, and the wide, plastic area between the support struts gave the coil an open exposure straight down. Other payloads I experimented with were containers for water sampling, extra batteries and solar chargers, more computing power with a raspberry pi, and support hardware for a robot arm. A big open area in the middle of the rover was ideal for many uses.

Bring on the Power and Controls

Once the physical rover was solid, I added:

• dual LiPo packs (mounted side-saddle where the truck’s decorative gear housings originally sat, perfect fit)
• a big, tactile kill switch
• an Arduino Uno (strictly for motor control)
• a dual-channel motor driver
• wiring harnesses and fuses

Everything was accessible through the toolbox lid or mounts on the side. Everything was swappable in minutes.

I’ve reused the code in many projects, but here’s a simple Arduino sketch: https://github.com/macroflux/Arduino-Blue-Rover-Basic

Semi final build at the time, with lights, camera mounts, mobile network control – but we’ll get to all that.

Using an Old Android Phone as the Rover Brain

Before we talk about how the body drives, there’s one more secret weapon that makes this whole platform way more capable than it looks: an old Android phone strapped to the hull.

Instead of trying to cram Wi-Fi, GPS, camera, radios, and sensors onto the rover one module at a time, I took a $40–$50 Android handset, bolted it to the top, and let it do the heavy lifting:

• It talks to the Arduino over Bluetooth to send movement commands.
• It uses the mobile network to reach a control server, so the rover isn’t limited by Wi-Fi range.
• It streams back GPS position, accelerometer and telemetry data, battery stats, and camera video to a base station dashboard.

The pattern was simple:

1. My base station app (on a laptop or another machine) sent commands to a small web service:
   • FORWARD, REVERSE, LEFT, RIGHT, STOP, etc. with speed and degree variables
2. The Android app on the rover polled that command URL, grabbed the latest instruction, and sent a single character over Bluetooth to the Arduino.
3. The Arduino translated those characters into motor speeds.
4. At the same time, the Android app pushed telemetry (GPS, heading, accelerometer, battery, etc.) back to the base station, which showed:
   • a big GPS map with the rover’s current location
   • a small live video window
   • status bars for battery, temperature, XYZ acceleration
   • and simple click-buttons for movement in the early versions

We’ll go deep into that control system on another page, but here’s a minimal version of the Arduino + Android parts so you can recreate the core idea.

Example: Simple Bluetooth Control on the Arduino

This sketch assumes:

• You’re using an HC-05 / HC-06 Bluetooth module
• It’s wired to pins 10 (RX) and 11 (TX) on the Arduino via SoftwareSerial
• Your motor driver uses:
  • DIR1 = pin 4, PWM1 = pin 5 (left side)
  • DIR2 = pin 7, PWM2 = pin 6 (right side)

#include <SoftwareSerial.h>

SoftwareSerial BT(10, 11); // RX, TX

// Motor driver pins
const int DIR1  = 4;
const int PWM1  = 5;
const int DIR2  = 7;
const int PWM2  = 6;

const int SPEED_FWD  = 200;
const int SPEED_TURN = 180;
const int SPEED_STOP = 0;

void setup() {
  pinMode(DIR1, OUTPUT);
  pinMode(PWM1, OUTPUT);
  pinMode(DIR2, OUTPUT);
  pinMode(PWM2, OUTPUT);

  Serial.begin(9600);
  BT.begin(9600);

  stopMotors();
}

void loop() {
  if (BT.available()) {
    char cmd = BT.read();
    Serial.print("CMD: ");
    Serial.println(cmd);

    switch (cmd) {
      case 'F': forward();  break;
      case 'B': reverse();  break;
      case 'L': turnLeft(); break;
      case 'R': turnRight();break;
      default:  stopMotors();
    }
  }

  // You could also periodically send simple telemetry back:
  // BT.println("ARD:BATT=12.1");  // example placeholder
}

void forward() {
  digitalWrite(DIR1, HIGH);
  digitalWrite(DIR2, HIGH);
  analogWrite(PWM1, SPEED_FWD);
  analogWrite(PWM2, SPEED_FWD);
}

void reverse() {
  digitalWrite(DIR1, LOW);
  digitalWrite(DIR2, LOW);
  analogWrite(PWM1, SPEED_FWD);
  analogWrite(PWM2, SPEED_FWD);
}

void turnLeft() {
  digitalWrite(DIR1, LOW);
  digitalWrite(DIR2, HIGH);
  analogWrite(PWM1, SPEED_TURN);
  analogWrite(PWM2, SPEED_TURN);
}

void turnRight() {
  digitalWrite(DIR1, HIGH);
  digitalWrite(DIR2, LOW);
  analogWrite(PWM1, SPEED_TURN);
  analogWrite(PWM2, SPEED_TURN);
}

void stopMotors() {
  analogWrite(PWM1, SPEED_STOP);
  analogWrite(PWM2, SPEED_STOP);
}

The only thing the Arduino cares about is one character at a time:
F, B, L, R, or S for stop.

Example: Tiny Android Control Loop (Conceptual)

On the Android side, the app really only needs to do two jobs:

1. Poll a command URL every few hundred milliseconds.
2. Send that command over Bluetooth, and periodically push telemetry back.

Here’s a simplified Kotlin sketch to show the idea (not full app boilerplate, just the core loop):

class RoverService : Service() {

    private lateinit var btSocket: BluetoothSocket
    private val cmdUrl = "https://your-server.example/rover/command"
    private val telemetryUrl = "https://your-server.example/rover/telemetry"

    override fun onCreate() {
        super.onCreate()
        connectBluetooth("HC-05")   // name of your BT module
        startCommandLoop()
        startTelemetryLoop()
    }

    private fun connectBluetooth(deviceName: String) {
        val adapter = BluetoothAdapter.getDefaultAdapter()
        val device = adapter.bondedDevices.first { it.name == deviceName }
        val uuid = device.uuids.first().uuid
        btSocket = device.createRfcommSocketToServiceRecord(uuid)
        adapter.cancelDiscovery()
        btSocket.connect()
    }

    private fun startCommandLoop() {
        val handler = Handler(Looper.getMainLooper())
        val runnable = object : Runnable {
            override fun run() {
                GlobalScope.launch(Dispatchers.IO) {
                    try {
                        // 1. Get latest command from server
                        val cmd = URL(cmdUrl).readText().trim()  // e.g. "F"

                        if (cmd.isNotEmpty()) {
                            // 2. Send first character over BT
                            btSocket.outputStream.write(cmd[0].code)
                            btSocket.outputStream.flush()
                        }
                    } catch (e: Exception) {
                        // log / handle error
                    }
                }
                handler.postDelayed(this, 200) // every 200 ms
            }
        }
        handler.post(runnable)
    }

    private fun startTelemetryLoop() {
        val handler = Handler(Looper.getMainLooper())
        val runnable = object : Runnable {
            override fun run() {
                GlobalScope.launch(Dispatchers.IO) {
                    try {
                        val gps = getGpsSnapshot()
                        val accel = getAccelSnapshot()
                        val payload = """
                            {
                              "lat": ${gps.lat},
                              "lon": ${gps.lon},
                              "vx": ${accel.x},
                              "vy": ${accel.y},
                              "vz": ${accel.z}
                            }
                        """.trimIndent()

                        val conn = URL(telemetryUrl).openConnection() as HttpURLConnection
                        conn.requestMethod = "POST"
                        conn.doOutput = true
                        conn.setRequestProperty("Content-Type", "application/json")
                        conn.outputStream.use { it.write(payload.toByteArray()) }
                        conn.inputStream.close()
                    } catch (e: Exception) {
                        // log / handle error
                    }
                }
                handler.postDelayed(this, 1000) // once per second
            }
        }
        handler.post(runnable)
    }

    // Stub helpers for brevity
    private fun getGpsSnapshot(): GpsData { /* ... */ TODO() }
    private fun getAccelSnapshot(): AccelData { /* ... */ TODO() }
}

Again: this is architectural, not drop-in production code, but performs the function:

• Base station writes commands →
• Server exposes latest command at a URL →
• Phone polls, forwards to Arduino via Bluetooth →
• Phone sends GPS and motion back to base station.

Why an Android Phone Is an Unfair Advantage

For the cost of a couple of sensors, you get all of this in one device:

• Camera (with built-in H.264 hardware encoding)
• GPS + assisted location
• Accelerometer, gyroscope, magnetometer, sometimes barometer
• Battery + charging circuit already solved
• Wi-Fi + cellular data for essentially unlimited range
• Full Linux-based OS you can SSH into, script, or build apps for

Whether it’s an old phone from a drawer or a $40 prepaid special, it gives a budget rover the kind of sensor and comms stack you usually only see on research platforms. The flip script here is that, like a lot of ‘Bluetooth Rover’ designs out there, the phone connects to the controller yes (in this initial version) with Bluetooth – but the phone goes with it, instead of sending manually. Which now unlocks the full mobile coverage potential of the system, since it can receive and send anywhere within mobile network range, and the base station can be anywhere.

But how does the body drive?

It’s not really possible, without buying a $10K unit, to compare specs and ability of this platform. It is what it is, somewhere between a hobby platform and a durable rover. But, with basic controls mean to just test the platform itself, a cobbled together skid steer from a RC, toolbox, some struts and suspension, battery and basic control system without a payload, here is TIGO V2’s first steps:

Build Pattern Summary

The Build Pattern (For Your Own $200 Rover)

There’s many paths, and some cheap alternatives out there, but my pattern here was a ground up, high clearance requirement approach that I could start from the ground up and work with a chassis to develop more on. If you follow this route, this is the core template you can adapt with whatever parts you find:

Chassis & Mobility

• Find an RC truck with left/right independent drive (skid-steer compatible)
• Keep the tires — foam is ideal
• Strip down to the motors + suspension arms
• Build a frame from aluminum stock
• Use PVC for supports and wire runs

Hull

• Look for a long, narrow box
• Toolboxes work exceptionally well
• Interior compartments = free electronics bays
• Strong central handle = free carrying solution

Electronics & Power

• Arduino Uno/Mega
• Dual-channel motor driver
• Kill switch
• Dual LiPo packs
• Clean wiring harness, fuses, connectors

Control System

• Old Android phone
• Bluetooth or USB serial
• Simple command protocol
• Lightweight video stream
• Optional pan/tilt head

All of this, combined, creates a rover that is:

• rugged
• cheap
• fixable
• field-ready
• and extensible for more advanced robotics work

Final Thoughts: A Capable UGV for Pocket Change

TIGO isn’t a lab machine, is not mil-spec, and not fancy. You may be thinking, this is a lot of fuss over strapping motors to some metal and a toolbox. You’re right, we’re not talking about an advanced engineering project here, unlike even others I’ve done. But with what I had in mind for payloads, all terrain flexibility, suspension based kinematics, in a light weight but larger form than the typical ‘wheels on a hull’ profile, this turned out to be more effective than you’d first think. Once you take into account specialized tires, form factors, suspension, profile, hitting near the mark in skid steering optimization… give it a second thought.

It worked (unlike many attempts) to get a real world UGV style rover out of other things for cheap, with long range, real runtime, real telemetry, and the ability to survive terrain that store-bought “robot kits” at the time simply couldn’t handle. And for my real goal, get something working that’s durable, not a lot of fuss, and inexpensive, so I could focus on software and hardware on a platform, it performs well.

This project became the platform foundation for everything I built next: better autonomy, Mission Planner integration, sensor arrays, mapping experiments, and all on a budget most beginners can actually work with. This entry is meant as an affirmation that yes, you really can strap some things together, use a little bit of engineering and science to focus it appropriately, and have something that’s more useful than headache, or limited.

And now that the build post part is out of the way, next is the fun stuff, mission planning, mobile network extreme ranges, and mission payloads. And, how I eventually transformed this into TIGO V4, the all steel, very large, articulated drive platform that can push around cars. But rest assured, this version of TIGO is still up and around.

Next post: Upgrades, autonomy, and Mission Planner integration.