Arduino++
Stepper motors are great motors for position control and one of the least expensive options for makers to use is the 28BYJ series of motors. They usually come with a ULN2003 based driver board, making them super easy to use, and they have been used in countless hobby applications.
So what are the parameters for these motors and how hard can we push them?
There never seems to be enough pins on a microcontroller to do everything you want, especially with really small processors. So it can be difficult to dedicate two or more precious pins for serial comms interfaces. For simple messaging, it turns out that one pin and some signalling can do the job.
While experimenting Atmel’s 8-pin AVR processors ICs (specifically ATTiny85 and ATTiny13) I decided to create the equivalent of a ‘Sensor Shield’ that allows me to re-use my prototyping boards and easily program the ICs through an ICSP header.
28BYJ-48 Stepper motors are really inexpensive and I have had been experimenting with them for some time. As-supplied they only have two attachments lugs that seem to be inconveniently positioned for most of the applications in which I want to using them.
In the previous post about Sensors for the Rover Bot, I discussed some of the shortcomings of the whisker-type bump switches used. While they did an ‘ok’ job, they persistently got hooked on the edges of objects from which the rover was moving away.
This became frustrating enough that I decided to design and make a Better Bump Switch.
In keeping with the original aim of replicating the Rug Warrior, described in the first part of this series, in this final part we’ll use the MD_SmartCar library functions to implement a simple random roving robot with similar functionality to the vintage Rug Warrior bot.
The objectives for this robot are therefore fairly modest – the robot should cruise on its own while avoiding obstacles and escaping from inadvertent collisions. Additionally it should be able to just move around, track a light source or follow a wall as its primary objective.
There comes a point at which the hardware and controls need to be started ‘in anger’ and tuned for performance. There is a lot to set up, but the process for MD_SmartCar is made easier by following logical steps, building up from simple to more complex activities.
This article outlines these steps from beginning to end, at which point a full application can be built using the configured core code.
When designing a SmartCar application, the details of the application (ie, what the robot does) will be purpose-specific. The underlying support infrastructure, however, should be more generic and aimed at simplifying management of the core hardware from the application.
In the previous parts of this series we covered the hardware and sensors. The next thing is to work out the core controls needed for an application using the hardware.
The first part of this series was an introduction to the core hardware for the SmartCar platform. This article covers the power supply, controller and sensors.
Many years ago I purchased a Rug Warrior kit to go with the book Mobile Robots: Inspiration to Implementation. It was an expensive kit – in the hundreds of dollars in Australia – for what was an advanced entry level robot of the early 1990’s.
The technology to make such a bot vehicle has become considerably more accessible, so I thought it was time to build a roving bot from the ground up. The challenge for this version is to make it as cheaply as possible for functionality similar to Rug Warrior.
