Posts

Showing posts with the label AI

A "Proper" Robot

Image
It seems to be that this time each year I introduce a new project, and 2019 not going to be any exception. My projects have become increasingly complex in recent years, and whilst I am still spending a lot of time on autonomous vehicles, according to feedback I have received, it is time to launch something that most enthusiasts could build if they wish. So, what does the list of requirements look like this time?  I am still drawing this one up, so as usual, you can follow the build and watch it evolve.  For now, here is what I have decided: The finished cost needs to be less that $A300.  Before you groan and say that it's way too expensive, Auric cost about eight times that amount, and is still not done.  I'm going to use off-the-shelf parts, especially from those low-cost marketplaces.  You can use upscale parts if you want, but you don't need to. Use a Raspberry Pi as the controller, and integrate all motion control.  The code for the autonomou...

Auric: Learning from testing

Image
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...

Auric: All about batteries

Image
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...

Auric: An update

Image
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...

Deep Racer - A first look

Image
Today, Amazon Web Services (AWS) announced the AWS "Deep Racer" at it's annual re:Invent conference in Las Vegas.  I was fortunate enough to get hold of one of the first batch of production units, and since most of you will not yet have seen one I thought I would give you a run down, as well as my first impressions. What is it? Deep Racer is a 1/18th scale AWD buggy with a cute body shape finished in back and silver-grey.  The body shape is quite interesting, but we'll come back to that later.  The chassis appears similar in design and components to many other low-cost remote control buggies You're no doubt interested in what's inside.  There is a single-board controller carrying an Intel Atom processor, 4GB RAM, 32GB Storage 802.11ac WiFi, a 1080p camera and battery packs.  It can also be used as a remote control vehicle through an app. (updated November 29) The controller board looks a lot like an Up Board, but I can't confirm this witho...

Auric - The Software Side

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...

My new favourite tool

Image
Life is much easier when you can see what's going on Sometimes I think these machines are getting a little too autonomous for my liking... Right now, Auric is being a downright pain the in the rear.  It just seems to be uncooperative. It all started when I observed that the directional control was erratic.  Given that the steering process is a stream of adjustments based on image processing, it is normal that there will usually be a mismatch in the speeds of the motors on each side.  But when the camera is shown a static image of a receding path I would expect it to steer more or less straight, or to make only small adjustments.  This however, was not the case. More digging hinted that not all of the commands sent from the main controller to the motor controller were being processed.  This boiled down to one of three possibilities: The main controller was not sending the commands; The motor controller was not receiving all the commands being se...

Introducing Auric

Image
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 ...

DIY Self-Driving - Part 9 - New Imaging

Image
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. We have a lot of work to do in pretty short space of time now, with new competitive opportunities in the very near future. To be honest, the line detection has simply not been good enough, and this is leading to some of the poor performance I have been experiencing with the car.  Whilst it really does work, it is not accurate enough.  There are a couple of issues here which need to be dealt with: The core processor is just not powerful enough; and The optics aren't good enough Processing As I noted in my "Next Iteration" article I am looki...