Now why would you do THAT?

It's amazing what you learn when testing in the real world... Auric went out for a long drive last weekend, while things went pretty well, there are always things to learn: 1.  Solving a performance problem Halfway through the long test I noticed that Auric was pulling to the left, and I suspected a motor drive problem.  After putting the machine up on a bench for a closer look I noticed something, well, "green" Upon closer inspection, Auric had decided to become an autonomous lawn mower and managed to wrap a 60cm grass runner around the front left drive.  Side effect was that the motor was loaded down and that caused thermal protection in the driver board to kick in. The final insult was when the imaging detected off-course behaviour and resulted in the motion controller trying to drive the jammed motor even harder, resulting in a vicious cycle. The end result of all of this is twofold.  Firstly, removing said grass solved the problem, and I wish t...

Batteries are really important if you're living off them OK, so this is going to be pretty boring, but it is important so bear with me. I learned from my experiments with the self-driving car that battery performance is critical, and to be honest last time I didn't pay enough attention.  I am making up for that oversight this time around. The Lovbio car used a 6V lead-acid battery to run it's motor.  Because that didn't give me too much headroom for my 5V powered electronics I had to run a separate 7.4V LiPo pack (commonly known as a "2S" pack) to run the electronics.  While it worked in the short term and helped the car to meet it's goals, it was not a viable solution . Because Auric is a ground-up design I had the opportunity to address a lot of the shortcomings from the last car and one of those was the power supply.  This time, it's a single battery and it's a big one, a 6200mAh 2S LiPo pack.  Basically it was the highest capacity...

I've been rather busy of late, and have not had as much time to spend on Auric as it has needed. The motor control has been a problem on this model right from the beginning, and I put some of it down to the L289 controller that is on the NodeMCU carrier.  I realise that this sounds like a poor workman blaming his tools, but early on, back-to-back testing showed the more common L298N-based drivers could drive the motors harder.  Packaging issues got in the way last time, and so I went with the NodeMCU and its carrier.  I paid the price in terms of performance. Unfortunately, there is still the packaging issue.  There are very few options for shields or carriers for a NodeMCU (to be honest, I can't find any other options), and there is simply not the space on Auric's deck for a separate driver module.  This may well mean changing out the controller altogether.  If I go to an Arduino UNO, such as I used the Self-Driving car, then I have a few more choices...

Auric is a combination of hardware and software. Last time we looked at the hardware required, and in this installment we will consider the software components. Like my previous self-driving car, there are two controllers in Auric.  The main processor and the motion control processor. Let's start with Motion Control because it is much simpler.   Motion Control is based on a NodeMCU (v1.0) and an associated L293D H-Bridge driver.  The software loop monitors the incoming serial port for a character stream from the main controller. This character stream is in the form of 'channel:value' .  These channel IDs are a single ASCII character (case-insensitive), and the value data is dependent on the channel.  For example R:512 is interpreted as Right Motor with a value of 512. It is the responsibility of the channel code to act and generate a response to the main processor. The main processor, a FriendlyARM NanoPC-T4 is primarily tasked with navigatio...

Looks like something an evil genius should have, right? In my last update, I mentioned that the "Auric"* chassis was being used as part of my self-driving experiment.  Now it's time to unveil it properly. Auric is a T-900 tank chassis made by SZ-Doit .  It's not cheap, but you get a lot for your money: The chassis itself, in a choice of anodising colours Twenty (20) idler wheels Four driven wheels Plastic track Bearings Motors (9V with Hall-Effect sensors, or 12V without) 16550 Battery Holder (no batteries) Screws, Nuts. Washers Allen keys The only problem is that there are no instructions supplied.  SZ-Doit have a Wiki on GitHub, but for the most part you are referring to photographs of the finished product in order to assemble the machine. Also available is a motor shield which is used with a NodeMCU module.  Since this was featured in the company's build I added one of those as well. Auric is on YouTube now.  Click here to view ...

Please Note:   Unlike most of my projects which are fully complete before they are published, this project is as much a build diary as anything else.  Whilst I am attempting to clearly document the processes, this is not a step-by-step guide, and later articles may well contradict earlier instructions. If you decide you want to duplicate my build, please read through all the relevant articles before you start. Things have been a little quiet on the self-driving front for the last month, but the project is still moving ahead. Mechanical Issues I guess it had to happen.  Prolonged running of this old car has taken it's toll on the drivetrain and the gearbox has stripped.  As you can imagine, this makes it rather hard to move anywhere.  It's not the end of the world, because these units are pretty common.  I am going to try and get a pair of them and convert the car to 2 wheel drive into the bargain.  All the cutouts are already there, so in...