08/20/2020 at 10:56 •
TKIRV was a great platform, but if we were going to build a 'bot that could survive in the wilderness, we needed solar power, and a more robust construction. Thus, SOLARBOI was born!
Fitted with improved 4G antennas, a new fisheye camera, and a power system capable of making the most of the juice from the sun, SOLARBOI is ready to head out into the world. Missions take place over on Twitch.tv, where we stream live from Mission Control.
As SOLARBOI drives into the night, Mission Control monitors battery voltage, mission distance, and commands the 'bot to navigate the distant streets of a regional Australian town. Command and control is via custom Python code, which runs the drivetrain, steering, and other functions. Batteries have been switched to a dual system, allowing the motors to drain the drive battery without affecting the communication link back to base.
Missions happen regularly, and the ultimate goal is to travel over 10km from the launch point to visit a telephone box still standing despite the advent of cellular technology. Wish us luck, and come check us out on Youtube and Twitch!
09/15/2016 at 00:49 •
TKIRV - now controllable over the internet! Because hell yes. Check out the orange wheeled monster in action...
From the beginning, the goal of this project has been to build an R/C car that can travel far and wide. This necessitated a way of controlling the vehicle remotely at a far greater distance than is normally possible with typical radio control setups. Thankfully, humanity has seen fit to develop high speed cellular internet connections which are perfect for this very purpose. We had a lot of work to do, but we cracked it.
There were issues using a cellular connection, of course. Unfortunately, unless you're using very specific business-grade plans, telecom companies here won't give you a public IP and you'll struggle to get your cellular connection to accept incoming connections. This was a problem for us; TKIRV runs a Python program as a "server", which we connect to from a laptop "client" to issue drive commands. We also need to be able to SSH in to the Raspberry Pi controlling the show. The easiest way around this is to set up a VPN server on your home connection, and have the cellular remote station connect back to it. Then you can work as if both machines are on a local network. I used OpenVPN to achieve this and it was relatively painless. It's very well documented and there's plenty of great guides on how to use it with the Raspberry Pi and also Windows. However I did have problems with the webcam stream later on.
One basic, yet very important step was to add a USB hub to the Raspberry Pi Zero. We needed to connect a webcam, a mobile internet dongle, WiFi for occasional troubleshooting, and even a keyboard & mouse at times, so we needed more ports. I went for the Stackable Raspberry Pi Zero hub from Makerspot. Four ports, no issues. With some extra polycarbonate mounting hardware I bought, I was able to bolt this up and mount the whole Pi Zero assembly to TKIRV without any problems.
Next on the agenda was to get a webcam stream up and running on TKIRV. I found a Microsoft Livecam VX-2000 for $7 and that seemed as good a choice as any. Thankfully for me it's got good Linux compatibility and thus works great with the Raspberry Pi. However, I quickly learned that streaming a webcam in the manner I wanted wasn't actually so easy.
It's easy to get a webcam feed running off virtually any computer these days. Whether you want just a still shot updated every few seconds or if you want video, it's not hard at all. However, we needed to be able to DRIVE using the webcam, and so latency was a huge issue. We needed to be streaming as close to real time as possible. At that point things became a massive headache. After a huge amount of research, I happened across a tool called MJPEGstreamer. It took me a full 10 hours to get it compiled and running properly, and suddenly - huzzah! I had a webcam stream with less than 500ms latency running over a 3G cellular modem. But even that wasn't good enough. For one reason or another, MJPEGstreamer doesn't drop frames when the connection varies in speed. This means that you may start at 500ms latency, but if throughput temporarily drops, it starts cueing up frames for delivery, making sure every last one gets sent - and gets further and further behind live updates. After just a minute or two I was seeing over six seconds latency! I suspect this is due to MJPEGstreamer using TCP over UDP but I can't be sure. All I knew was I needed another solution.
I then happened across gstreamer. It's an incredibly flexible program, but it's also one of the most complicated and arcane pieces of software I've ever used. That's the price you pay for power, but damn. I think perhaps one of the bigger problems is it's not super well documented as far as I could see; I eventually patched together a working send and receive "pipe" after assembling scraps off different forums from people doing the same as me. The biggest headache I had was getting gstreamer to run over the VPN connection. My laptop base station was able to connect to the RPi stream but wouldn't actually display anything. After hours spent pulling my hair out, I realised that as the stream was an outgoing connection from TKIRV, I could simply squirt it directly at my laptop over the internet, ignoring the VPN entirely. All I then needed was to set up a Dynamic DNS so that TKIRV can always find my laptop over the internet, and I was good to go. Now I had a stream running over 3G with less than 300ms lag on a good day! Finally.
Alex, wondering why he was spending ANOTHER Sunday standing around in the driveway...
So it came time to test. During development we'd used an Optus 3G USB dongle for our cellular connection. We fired up the webcam stream and got the control program hooked up, but we were suffering huge lag and frequent dropouts. The stream was buggy and our Python command and control app kept losing connection. I suspected it was a bandwidth issue, so we ran a quick test using my mobile phone as a 4G WiFi hotspot. Things improved enough that we rushed out and bought ourselves a 4G hookup. Unfortunately there weren't any 4G USB dongles at the supermarket and everything else was closed for the weekend, so we settled with a 4G WiFi hotspot to keep us going for now.
TKIRV with its new 4G WiFi unit taped on because it was late and damn it, we needed a result!
Did it work? OH BOY DID IT WORK.
TKIRV cutting some mad shapes on the street at night.
It was absolutely elating as Alex walked the car out to the pavement - the video was smooth and responsive, and we could actually drive! The first night we did have some issues with the main motor drive, which we later tracked down to low battery voltage which was easily fixed. The feeling of being able to drive this thing as far as possible was totally electric.
Sooner or later, they all have to leave the nest.
We took turns driving and walking with TKIRV, doing a shakedown of all systems. We did identify some issues. Maximum resolution we can currently run the webcam at smoothly is 160x120; any more than that and we run into bandwidth issues. I suspect this is due to the inefficiency of streaming our webcam's native MJPEG format; we may be able to run higher resolution with an h.264 native webcam if we can get one cheaply somewhere. We also had problems with the webcam mount being knocked around during crashes, so that's a prime candidate for improvement.
TKIRV on a grand adventure, driving off into the sunset...
Another main target for improvement is control. Currently our main drive is hard forward or hard reverse; our steering is hard left or hard right. This makes controlling the vehicle difficult in tight spaces, particularly when webcam and control latency comes into play as well.
We've got a long list of upgrades to do to get the platform up to a more robust and reliable state.
- Improve webcam mount
- Improve electronics mounting and tidy all wire routing
- Install brushed ESC for variable speed control
- Implement variable speed and steering control in Python control code
After we've finished this and got some more driving under our belt, we'll look at implementing the next stage - solar hardware for indefinite mission operation. I can't wait to actually do some serious, long drives with this beast.
Till next time - TK out.
07/25/2016 at 08:18 •
At the end of our last episode, we had steering and drive control through the Raspberry Pi... just. But we'd gained it at the expense of some poor blown transistors and things weren't really going too well.
It was time for upgrades. In this episode, we replace the original steering box with a servo and reassemble the whole car. Then it's time to try out remote control with our Python code over WiFi... and it works! It's a truly elating feeling getting the thing screaming around the kitchen and bathroom all done wirelessly over the network.
So what's next for TKIRV? A webcam and cellular internet, of course. Get thirsty. But for now, feel free to read the log.
First things first, we switched from a Raspberry Pi (original flavour) to a Pi Zero. Why? Well, the long term goals of the project involve solar power and the Pi Zero draws less current than the other models of Raspberry Pi. That, and Alex wanted his Pi back so he could play emulators again. Damn.
It really was painless going from the original RPi to the Pi Zero - we literally just swapped over the SD card and things booted straight up! I thought that was really impressive. We then got this cute little Protozero "hat" for the Pi Zero. It's basically a protoboard that neatly fits the form factor and allowed us to really tidy up our wiring.
In Part 2, we'd done a lot of damage to the original car's steering electronics and an absolute hatchet job of fixing them up. I reasoned that maybe it was time to just sub in a big fat servo from Hobbyking. This was great... except I blew up our Pi Zero in the process. Cue a 3 week wait for a replacement to ship. They're not easy to get a hold of.
The job involved a whole lot of epoxy and special plastic glues to adapt the original steering box's servo saver to fit the new servo, and a bit of hacking away to get everything to fit nicely. But once it was done it was sturdy and neat.
Now all of a sudden we found ourselves at the point where we had steering, drive... we just needed power and hell, we could drive this thing! I had a hunch a typical 12V 2A USB car charger would operate just fine off the 8 or so volts in our 2 cell lithium battery. I think I was right; initial testing showed it putting out a solid 5.1V under load to run the Pi Zero brains of the operation.
Then it was time to wrap everything in electrical tape and try it out. Finally.
I delicately plugged in the batteries and set TKIRV on the floor. Jumping back to my laptop, I SSH'd in to the Pi and ran the Python control program. I felt like a 90s Hollywood computer hacker. It was great. I fired up my remote control program on the laptop and handshakes happened across the WiFi and suddenly... everything was connected.
My hand hovered above the cursor keys. I drew my breath in anticipation.
The thing was immediately fantastic. After crashing it into the hallway walls about sixteen times we took the thing for a spin around the kitchen and damn, TKIRV handles, bro. Things might be different when it gets out in the real world with 200ms+ lag on a 3G connection but over WiFi this thing was a dream. Then it was time for some carnage.
Poor guy never saw it coming.
It was so great to finally get this thing rolling again after having so many headaches and delays waiting for parts. We've now got a rolling platform we can drive over WiFi; all we need now is to sub in a few more parts and we'll be truly mobile. Till then, enjoy the log and the video... big things are yet to come.
TK out. ;D
05/07/2016 at 01:43 •
I enlisted the help of my friendly local Alex (TM) and we got to work tracing the PCB and figuring out how the car controls steering and drive. Initially we had a lot of luck and I quickly found a way to control steering and drive; these early gains were quickly scuppered as my youthful overexuberance led me to make some wiring errors which let the smoke out. To get the whole story, check out the video! The picture below illustrates the basics of what we did to control the car.
The motor drive was easy; there's a big fat NPN FET on a heatsink (not pictured; other side of the board) that switches the motor on or off. I found a nice convenient point on the board that triggered this FET when I tied that point to ground, so it was as simple as hooking up a little NPN BJT (BC547) to the Raspberry Pi to control the motor drive. Forward and reverse of the motor is controlled by the relay (not pictured; other side of the board) which swaps the polarity of the motor leads depending on which direction you wish to go. To control this, I cut a trace connecting the coil to ground, and tied the other side of the coil high. I was then again able to pop in a BC547 to switch the relay from the Raspberry Pi.
At this stage, we have motor drive in both forward and reverse. So far, so good. This is when things started to fall apart.
I was really excited when I started trying to figure out the steering. From visual inspection of the top of the board, I saw a series of pairs of transistors, three pairs of two in total, that I figured were a little network used to control the steering motor. I then quickly found two pins on the main IC; one went high when I held left on the RC transmitter, the other went high when I held right. When you're not steering, the car self-centers its steering which is great, too. So I figured I could simply try dragging those pins high myself and see if the steering worked. And it did!
However, I noticed that manually pulling these pins high was drawing 15mA, which was way too much just to switch on a few transistors in the network. I determined that if I cut the traces connecting the steering network to the main IC, I could still activate the steering left or right, but the current draw was much lower. It still self-centered, too. So I was set!
It all fell apart when I connected these steering pins to the Raspberry Pi with a couple of PNP BJTs (BC557s). First, I still had the transistor's emitters connected to the 2.8V (weird supply voltage right?) line on the RC car's PCB instead of the RPi's 3.3V line. I also forgot to tie the grounds of the RPi and the RC car together, so the transistors were all over the place. And finally, I forgot that PNPs are switched on by pulling the base to ground, the opposite of NPNs, so I was switching both the left and right transistor networks on at the same time. I believe it's a combination of these factors that led to the ensuing tragedy...
I let the smoke out, and for my folly, a brave PNP died in my arms. After much desoldering and transistor testing, I determined that this was the only verifiably dead transistor, but I replaced a few on the board anyway. These A928As in particular are high current types rated for 2 A, which I replaced with BC557s I had on hand which I think are only rated to something like 100mA. I got the steering twitching again but it still wasn't functioning right. Eventually I decided to rip out the main IC after finding some strange voltages on it, and... success! I could steer left and right again by manually applying voltage to the steering pins. However, I have lost the self-centering capability which was controlled by the main IC reading the steering encoder.
While I did restore some functionality to the steering after so thoroughly blowing it up, I'm currently torn between two options. I could push on and wire the steering encoder to the RPi and code it to self-center, but I'm at risk of the underspecced replacement transistors burning out and the PCB pads and transistor leads have all seen better days and will probably fail under vibration fairly easily after I replaced them 2 or 3 times each. I'm pretty tempted at this point to sub in a servo instead, driven from the RPi's hardware PWM line. For now, that's a question for another day.
Thanks for reading and keep an eye out for the next update on TKIRV!
04/24/2016 at 05:58 •
Work continues on TKIRV! At this very moment, preliminary work on the Raspberry Pi control system for the car has commenced. We're running things with Python which is a fantastic language in which to build things quickly and efficiently. So far we've got some LEDs flickering over the network which is an important first step towards our goal.
TKIRV has also been entered into the 2016 Hackaday Prize. We're aiming for the Anything Goes category. The basic features of TKIRV are outlined below.
The aim of TKIRV is to build a remote vehicle platform capable of indefinite operation by leveraging cellular connectivity, solar energy, and smart power strategies. With this technology, TKIRV will theoretically be able to roam as far as cellular internet access is available, being controlled over the internet from many kilometers away - potentially even from a different country.
In addition to its camera, TKIRV could be further equipped with sensor payloads to enable it to perform more complex missions. This could range from environmental monitoring (temperature, radiation sensors), mapping (altitude sensors for topographical data + GPS), or packages to enable more autonomous operation (rangefinders, computer vision). This combined with TKIRV's ability to operate for long periods of time through the use of solar power give it many advantages for continuous monitoring applications.
Keep an eye out for the next update, where we try and figure out how to interface with the RC car's drive and steering systems!
04/09/2016 at 01:52 •
In this video, I introduce the TKIRV project and what we're looking to achieve. Then I set about tearing down our base vehicle, a Radio Shack RC car from the early 2000s. It's got 4WD, front and rear suspension, and is pretty much the perfect size for the job.
The wheels come off easy - the car actually shipped with a small tool for undoing the bolts and taking them on and off. Why, I can't possibly imagine - there's nothing to achieve by doing so! Fun though.
With the body shell removed the car looks quite different. Looking at the bottom of the car here, the suspension linkages and driveshafts are visible, as well as a strange 9V battery compartment you can only open by tearing down the whole car. I have no idea what it's there for, there's no contacts in there or anything, and the car runs off a 7.2V NiMH pack anyway. So strange.
Next I took a look at the main PCB. I haven't delved too deeply yet but I have a rough idea of what does what. We have our main IC that I presume is responsible for decoding the radio signals from the original controller and controlling the steering and drive motors. We have the power transistor mounted to a heatsink which is most likely to run the main drive motor, a brushed DC unit. I have a hunch the relay is used to reverse the polarity of the motor connection to the power transistor to switch forward and reverse. It's an interesting relay, controlled by a 5V signal instead of the more usual 12V. Then we have a smattering of discrete transistors which I think are probably for helping drive the steering motor and doing other little things here and there. More investigation to come as the project rolls on.
Last of all we have the steering box. This contains a small brushed DC motor, a geartrain to generate more torque, and an encoder. This allows the car to drive the front wheels back to a straight ahead position after the user stops holding left or right. It could be a bit of a headache to interface with this but I think we'll find a way.
So next on the agenda is to figure out how to interface with the main PCB to get control over the drive and steering, and to start working on the remote control of the Raspberry Pi that's going to run everything. For more detail on the teardown, watch the video at the top of this post, and keep an eye out for the next update!