Arduino++
I find high speed photography fascinating because it captures and preserves an instant that is not usually visible to the naked eye.
Liquid drop photography is the most popular kind of low budget high-speed photography. It is often the first high-speed technique for beginners as it’s easy to shoot with minimal equipment and setup – even I had success, and I am far from proficient as a photographer.
Lately I have been scanning a lot of Quick Response (QR) codes required because of government check-in/out during the COVID pandemic. I was curious to understand what this barcode was and whether it was feasible to generate one using simple MCU hardware and display it on an ePaper display.
It turns out to be quite straightforward as others have already done all the hard work.
In the previous part I described the changes to the original SmartCar project related to hardware and sensors.
In this post I’ll continue with the changes made to the software and control software, and the resulting improvement in the behaviors of the rover example application.
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.
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.
Arduino++ 