Posts

Showing posts from 2019

WiFi Tank Robot in about an hour

Image
 (Left to Right, Auric and Oddjob) If you've been reading here for a while, you will probably remember Auric my large quad-track robot.  If not, you can read all about it here . Auric is still developing and getting smarter, but it's also really an expensive project.  I wanted something fun for the kids.  It had to be easy to build and able to handle indoor and outdoor conditions well. The solution came in the form of a "Black Gladiator" chassis from DF Robot .  Mine came from Little Bird Electronics in Hornsby New South Wales, for the princely sum of $A50. What I really like about this chassis is that unlike quite a few "budget" tracked chassis I have seen, this has an aluminum base plate which makes it not only stronger, but it shouldn't flex so much and cause damage to PCBs attached to it. It's a kit so you will need a small phillips-head screwdriver, soldering iron, cutters and medium duty hook-up wire.  When I received mi

Seriously, WHY would you do that?

Image
Chapter I  A New (Old Stock) Hope The first computer I got to use was a PDP-11 owned by a time-sharing bureau in Wollongong in the 1970's.  From memory they ran services for car dealers or some such thing.  The operating system was RSTS/11. When I finished high school I was able to get access to a VAX/VMS system owned by the Department of Education.  Security wasn't a big thing, and my lecturer even gave me the phone number for a dial-in port so I could get access on the weekends.  I discovered the machine I had access to was part of a larger network of VAXes and with a few simple commands, I could jump from one to another.  Just looking around mind you, nothing even remotely interesting was attempted. VAX/VMS, and later OpenVMS on Alpha have played a moderate part in my career, and I still enjoy tinkering because of the generous way that Digital,then Compaq and now HP/E have supported the hobbyist community. Emulators are one thing, but getting your hands on

Make your Raspberry Pi faster

I have heard many people (including yours truly) say that the Raspberry Pi should be faster than it is.  In it's Mk 3 form, with all cores firing it ought to be a lot of performance for the price, but many of us are strangling the performance, often without even realising what we are doing. Here's some simple tips to getting the best performance: Power it properly Just because the Pi has a micro-USB connector for power doesn't mean you should use some ancient phone charger to power it.  This board needs a stable five volts at around two amps to operate properly, and even more under heavy compute loads.  Most small plug pack supplies will struggle to sustain one amp.  Try to draw a higher current and the output voltage will almost certainly droop (drop slightly). When this happens, you might see a "lightning bolt" on the monitor (if you have one connected") or notice "undervoltage" messages on the console.  Then the Pi detects an undervoltage

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 autonomous vehicles was in

Life with Deep Racer - Part 2

Image
 An Update on AWS Deep Racer OK, so AWS Summit Sydney has been run and won.  Not by us however, but there are few interesting tidbits to report: The console is now widely available This is actually pretty big news, because: The console ties together Robomaker, SageMaker and everything else you need in a convenient package There are actual examples of functions included It seems to stay running now There is new firmware for the car Also important; this includes a rolling update for the Ubuntu base as well as the Deep Racer specific bits.  WiFi connection seems more reliable now as well. Our car has a new look Since my employer (Versent) was generous enough to send me to Re:Invent last year (where I got the Deep Racer), I thought it appropriate to deck it out in the company colours, and it was well-received at Summit last week.

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 to add

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: ADAFruit Mo