Arduino++
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 the rover was moving away from
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.
PWM today is used in most forms of finite control in electronic devices. LED dimmers and DC motor speed control are two common applications for PWM.
An Arduino Uno has 14 digital I/O pins, of which just six specific pins are hardware PWM-enabled ,but in some situations it would be great to be able to use any I/O pin for PWM. This is possible using AVR timers and interrupts.
I was recently looking for a brushed DC motor controller for some small motors and came across four controllers that seem to account for the majority of those available from online stores. I had to compare them before making my decision, so here is my summary of their specifications and how they would be controlled from your software.
App Inventor (AI2) is an easy way to create Android apps. While originally designed for teaching, it still allows building advanced and complex apps, and was the tool I chose to build a software 2-axis joystick interface for wireless vehicle control.
This article describes the implementation of the joystick as a standalone component that can be integrated into other applications.
When you need to process an interrupt, there is nothing else you can do but process it. Most Arduino examples show how to do this in a ‘C’ context. Processing interrupts in a C++ class is a lot less trivial, as class scoping rules and constructs get in the way, and specific arrangements need to be taken to ensure data is processed correctly.
