Royce has been tinkering away on his entirely 3D-printed, water-gun-toting, tracked robot. We were so impressed that we insisted on taking a closer look at FRED. 

If you’re into robots (and who isn’t?) you’ve probably thought about building your own personal servant to fetch a cold one, fold your laundry, or take out the garbage. While we might not be there yet, here’s a very cool project built from the ground up. Using a combination of open source Thingiverse files, some powerful yet simple hardware, and a little code, FRED will roam the house and squirt water at whomever dares enter! Standing almost 30cm tall and now in its third generation, he’s come a long way from the first version, with better sensors and motor control. We asked creator Royce, all about FRED. 

Tell us a little bit about FRED’s capabilities?

At the moment, FRED can roam around the house (he’s an inside pet), avoid most obstacles, and get himself out of tight corners. FRED’s main board is currently at revision 3 and the head board is at version 5. FRED was created for two purposes: firstly, as a fun test bed for various hardware items, and secondly to chase my grandson around the house using the installed heat sensor. FRED uses a PIXAXE for drive logic, with a Pololu TReX Jr dual motor controller to manage the drivetrain.

What made you decide on the TReX Jr motor controller over other controllers?

I started the project with a Pololu DRV8833 motor driver. This required four I/O lines to operate and two analogue inputs to read current from each motor. I found I ran out of I/O [on the main board]. I also tried to incorporate “soft start” into the coding but this became overly cumbersome, so I decided to search for a serial or I2C controller.

The TReX Jr could be serially controlled, had acceleration functionality, and current limiting built in. It was also small enough to fit in the space I had available. As a bonus, it has a high current third motor driver (should I ever need one), and motor current draws are also available via serial interface. All up, by using a TReX Jr, I increased the available drive current from 1.2A (DRV8833) to 2.5A and saved four I/O.

It certainly seems like serial simplified much of the I/O you were having to manage manually. How much autonomy does FRED have, and how has it evolved from the first time he came to life?

VERSION ONE: When he first began, he was fitted with a Devantech SRF08 ultrasonic sensor and a Devantech TPA81 thermopile array for heat sensing. Motor control was with a DRV8833 as noted above. Track motors were simply servos converted to continuous rotation. Pan/tilt servos were driven directly from the PICAXE chip. No water pistols were fitted. MP3 player was also fitted in this version.

A Devantech CMP09 compass module was used to keep him running straight and to measure turn angles. Compass module and code worked, except when I installed it into the robot, the slight magnetic field from the motors caused errors in the compass module.

Feedback for motor currents and other values is via a small OLED screen from "Digole". Front, rear and edge detection is performed by Pololu IR proximity sensors (Pololu 1134). These little IR prox sensors are fantastic, but benefit greatly from a small capacitor soldered across the power terminals on the board.

VERSION TWO: The next revision used a new main board. Hall sensors were added as rotation sensors for feedback during straight running and turns, rather than the compass module. The hall sensors were activated by magnets built into the tank drive sprocket. This meant resolution of rotation angle was very coarse. The head with attached water pistols was fitted to this version, and an eight-pin serial servo driver was used to drive all the servos (pan/tilt, water pistols).

Unfortunately, the servo driver was a dismal failure. I burnt out two servos due to the chip locking up and jamming the servos to full swing, which caused them to overheat and burn out.

VERSION THREE (CURRENT): The current version uses TReX Jr for motors, Pololu Micro Maestro for servo control, and motors are now Pololu micro metal motors with hall speed feedback built onto the rear of the motor (providing higher resolution). Temperature sensing uses a Melexis MLX90614ESF-DCI non-contact temperature sensor that’s mounted to a breakout board (purchased on eBay). I also included a PICAXE ERF remote download device to this version.

I had been using a LIDAR-Lite v1 for proximity sensing, but have recently replaced this with a MaxBotix I2CXL-MaxSonar-EZ4 sensor, because the LIDAR-Lite V1 was intermittently returning bad readings. The most recent additions are his eyes, made from two BlinkM I2C addressable RGB LEDs.

What's next?

There will be a further revision of the head board. I’m currently using the logic 5V supply to feed the pump motors. The motors are designed to run on 3.3V, so inject a lot of noise into the power rails. I’m going to try using PWM to reduce the voltage but there may still be an issue. The new board will use an N-channel MOSFET to drive pump motors, and they’ll be supplied from the servo supply through two diodes to drop the voltage to approximately 3.6V.

These things are an evolution, and they’re never complete! Your 3D printed tracks are amazing, but I’m sure they were tedious to do. How important were the tracks to your design, and how much work did it take to get it right?

The tracks are awesome, but I didn’t design them! Full credit for the design of the tracks, sprockets and idlers goes to Ktronics, Krux and DRH – a heartfelt thank you for sharing them on Thingiverse!

I did modify the sprockets to suit the new motors, and the chassis to suit some of my other modifications. The tracks have been modified so the 3mm bolts don’t require a nut to hold them in. I’ve also used different idlers with bearings, all installed from Thingiverse.

I’ve always liked tracked machines, so any robot I made needed to be tracked. I guess you could say that was important to me. The only other modification I’d like to make is to the tracks themselves; they need to have some rubber added, for extra grip.

That’s so impressive, and it’s the amazing world of creative commons at work! What degree of pan/tilt did you achieve with FRED?

The tilt probably won’t go any further than about 60 degrees. The ratio between pinion and main gear is 2.7:1 (from memory). Sixty degrees assumes the servo can be driven to 162 degrees. The rotation is directly driven by a servo, but I’d suggest it would be hard pressed to rotate more than 160 degrees.

Awesome. What conditions does the MP3 operate on? Does it play specific tracks when it detects or is about to fire, or is it just playing music to keep itself entertained?

MP3 player is a DFplayer Mini. The device is serially addressable and can play individual tracks on demand. This little device also has a 3W audio amplifier built in, so is awesome for adding “voice” to projects. Currently, it plays tracks for detecting objects, detection of thermal signature, firing cannons (water pistols), initialisation of systems, low battery, “crazy Ivan” turns, and more.

That’s a really neat solution. Playing tracks on demand definitely gives FRED some life! How did you approach designing the superstructure and did you have any challenges along the way? 

Inspiration for the superstructure framework came from Krux’s design listed above. I knew I needed a pan/tilt for the head, but all the designs I found relied on the servo to support the weight of the head, so I decided to design my own.

The tilt portion of the mechanism is geared to increase the available torque from the small servo and the weight of the head is supported by bearings. The circular teeth used in the design were another Thingiverse design.

I downloaded a SCAD code [for OpenSCAD] and used that to create the gears I needed. The gears mesh well and are easily printed. Thanks to jsirogado for these. 

The rest of the frame was drawn up using Tinkercad, with the goal of supporting the pan/tilt while leaving as much room as possible for motors and electronics. I had a rough idea of what I wanted it to look like, so just ran with that. The design has been modified a few times to accommodate motor changes, water tanks and aesthetics. 

You’ll definitely gain some life out of the servo by using the bearings. Do the water pistols operate autonomously too, or do they simply expose?

If FRED detects an object that is three degrees higher than ambient temperature and closer than 90cm, he stops scanning his head and says “thermal signature detected, inundation commencing”.

The water pistols then pop out and the water pistol pumps are meant to start. When firing the water pistols, FRED moves his head up and down to spray water over the object. The proximity distance of 90cm was chosen because the water pistols are so small they struggle to shoot any further than this. It also means that the temperature sensor is only “seeing” a small circular area about 9cm in diameter.

Once the pumps stop, FRED rechecks the temperature and if it’s still high, he fires again. Once he’s fired twice, he gives up and carries on. I may change this behaviour and make him turn away 90 degrees after firing, because if it’s a stationary heat source, he has another go at it on the next scan.

I also need to add a maximum limit to the temperature that he will consider a “thermal signature”, as I’m concerned he might spray a wall adaptor by mistake.

Oh yeah – that’s probably not a good mix! How are you achieving the scanning and heat signature detection functions? 

As discussed above, I was using a LidarLite V1 for the ranging function, but have since changed to a Maxbotix ultrasonic sensor. I need to find more time to test the Maxbotix sensor thoroughly, so the jury is out on whether it’s better. The temperature sensor is a Melexis MLX90614ESF-DCI non-contact temperature sensor, which has been mounted to a regulator/interface board, courtesy of ebay. This sensor has a very narrow field of view and communicates via I2C. Both sensors are mounted centrally on the head in the position of FRED’s nose.

While FRED is “roaming”, his head scans back and forth. He takes a temperature and range reading at five distinct positions (sectors). At each sector the firmware checks if the temperature is higher than ambient, checks the range reading, and checks the IR proximity sensors for a change in state. If the temperature is high enough and the range is less than 90cm, FRED stops and enters the water pistol routine described above.

If the ranger detects an object closer than its minimum threshold and/or a proxy sensor has changed state FRED stops, completes the scan (left to right or right to left), and then takes appropriate evasive action based on the ranges collected in each sector. If an object is detected directly in front of FRED, he uses the scan data to identify the sector that has the greatest range reading and turns that way (clear path). At the end of each scan, if there is no detection event the motor speeds are checked, and their speed is adjusted to maintain a set speed and straight course.

If, after a time, FRED hasn’t detected anything interesting (object or thermal signature), he’ll do a couple of 360-degree turns (called “crazy Ivan”), and search for a heat signature.

That sounds like a fairly solid routine – simple, yet functional. Is there an achievement in this build that you’re particularly proud of?

I’d have to say I’m particularly chuffed with the pan/tilt design. It came together quite nicely.

It certainly looks great! Anything that was particularly challenging that you overcame?

The coding. I’m a self-taught PICAXE basic programmer but not a math wizz, so it took some thought. The coding for the scanning took me a long time to get right and it was very satisfying to finally get it working the way I wanted. The motor speed control code was also a challenge. I don’t know if I went about it the right way, but it works!

In a non-production environment, code doesn’t always have to be elegant. Sometimes functional is all you need! Are you focused on FRED at the moment, or do you have something else awesome in the works?

I have a lot of projects on the go, so I don’t devote all my time to FRED. To be honest, I don’t know if he will ever reach the point where I can say “that’s it, he’s done” because I always seem to come up with another cool feature to add. I’ve been spending a bit of time converting a drift trike to electric drive at the moment...

Oh how we’d love to try that! If only they made adult-sized versions – the kids get all the fun! How long have you been dabbling in electronics/maker space?

I’ve been an electronics hobbyist for 34 years. I’ve only jumped on the 3D printing / CAD design bandwagon about three years ago. Using Tinkercad primarily, because it’s simple and I know it well. I have been playing around with Fusion360 on and off in the last 12 months, mainly because it’s a much more versatile tool, and it’s free!

That always helps when you’re not sure you’ll use it long-term. Any shout-outs, thank yous, or other mentions you’d like to make?

I’d like to say a special thank you to my partner for her considerable tolerance and understanding.

I’d also like to thank the following people:

• All contributors to Thingiverse and other resource/file sharing websites.
• The PICAXE forum members for asking and answering questions.
• DIYODE magazine for their interest in FRED.

Finally, I’d like to congratulate DIYODE Magazine on their inaugural issue and I hope you have a successful future. 

Royce, thanks for introducing us to FRED. We look forward to hearing about your next project!