One common questions I get asked about NE-Five is “is it open source” and I always give the answer “mostly…”, there’s a reason for that. The code has been available for a long while, along with a basic simulation that you can run in Gazebo, but the CAD model has never been shared. That’s becuase it’s a mess, to say the least! I hadn’t used Fusion 360 in anger until I started working on MacFeegle Prime, the v1 of NE-Five. As such, it’s an absolute mess of deadends, redundant designs, and terrible usage of the component system…

The Road to NE-Five Mk4

There have been various versions of NE-Five over the years, the biggest changes being from MacFeegle Prime to NE-Five, in the early days they had tank treads for the true Johnny Five aesthetic. Treads were a bit unreliable, at least the way I made them, so I switched to wheels for a later version rather than getting bogged down trying to make them work, all the while the rest of the robot being a mess. I think, bizarrely, that the first NE-Five was actually the Mk2, I guess I considered NE-Five the class of robot and MacFeegle Prime was just the name of the first one? Sound’s plausible, it’ll do as an explanation at least.

The Mk1 introduced an aesthetic which we’ve pretty much stuck with ever since, it also moved the motor and servo control from the head to an enclosure on his caboose. You can see the mess of cables coming out of the back of his head in the photo below. The bundle was that tight that if he tried to look up too far, his head would pop off as the servo couldn’t move the wires…

Mk2 still used a Stereo Pi board in his head, but the RedBoard was moved to the caboose and hosted on a PiZero connected over USB. This meant that there was only a USB cable and wire for the NeoPixels between head and the rest of the body which was much less stressful on the neck mechanism.

Both of these designs still used hobby servos for the arms and neck mechanisms, along with the Stereo Pi for control and vision, so the Mk3 was the biggest leap from a technology perspective.

NE-Five Mk3

Aesthetically the Mk2 and Mk3 look very similar, but there is an awful lot changed internally.

The overall form-factor has been retained but significant upgrades were made in the arms and vision system. The Stereo Pi was replaced with a Luxonis FFC-3P and the Pi Zero in the caboose replaced with a Raspberry Pi 4, the RedBoard is retained for power supply, NeoPixel, and motor control. The “hobby” servos were replaced with Robotis Dynamixels, the most obvious benefit of which is that they daisy chain together so the wiring is much tidier. More importantly though, they give position and status feedback so you can detect if they’ve stalled for example, they are more expensive but they’re worth it purely in savings compared to the number of servos I burned out without realising it!

The Luxonis FFC-3P vision board is also a game changer, where with the StereoPi I was able to generate a depthmap at 320×240 at around 18fps, the 3P can run at around 900x600px and 30 fps. This is as well as running neural networks for object recognition using it’s three cameras as well, it has dedicated hardware for the task, it also compresses images for preview on the Pi or over wifi to massively reduce bandwidth needed. This takes basically all the stress of computer vision away from the Pi and only sends over the data we need over USB, rather than swamping the Pi with frames that will mostly be discarded.

The 3P is configured with three cameras: Left and right are both AR0234 sensors with 110degree wide angle lenses, these also have global shutter sensors so ideal for reducing shutter effects when moving. The centre camera is an IMX378 with auto-focus, this has a 69 degree FOV so much narrower. It also has a rolling shutter so more for use to get closer views of objects when stationary. Imagery from all three can be used simultaneously, I’ve barely scratched the surface of what these can do.

NE-Five Mk4, and Future

So, with all those lessons learned and improvements in mind, I’m going to design the Mk4 from scratch in Fusion 360. The reason for this is to get rid of all the baggage from the last four years of designs in the files so that they will be much easier to maintain, and more importantly to share. There’s also some cool scripts for Fusion 360 that can generate URDF (universal robot definition files) but they only work if it’s laid out in a certain way.

Internally and externally it’ll look much like the Mk3 does now, but with what I hope to be a more “production” quality of finish. There will also be a new motor controller board I’m developing that will include reading encoders and IMU to generate odometry.

The future part is an aspiration, I’m planning on developing this in to an actual product and sell as kits or preassembled, I am going to be releasing the CAD models and BOM still though in case people want to build their own. For those in teaching or research who just want one that comes assembled and with a warranty though, buying one may be preferrable. It’s very early days on that at the minute but I’m hoping it’ll be ready for sale towards the end of 2024. I was always intending for this to be a portfolio peice for the company to help me get robotics work but that hasn’t worked out too well. A few folks have said it’s almost a product already so I figured I’d try and get it the rest of the way there.

Stay tuned for more info on this, this is the precursor to me documenting the build of the Mk4 so a lot more info will be coming soon.