This is a work in progress as it has turned out to be far more complicated than I thought it would be! I’ve learned a lot about how to design parts for my 3d printer and how to use the laser cutter at Reading Hackspace too though so already winning!
The size of the backboard and targets with a can of coke, potato and pennies for scale.
To test the cutter, a nameplate!
Left to right, prototype hinges. The final design was the fourth!
My workstation in the staff tent at the Beer Festival
The mess of wires before it was simplified and the old hinges.
Over the passed few years my friends in the Reading Beer Festival Games Team have been talking about building a shooting gallery using Nerf guns to keep things nice and safe. This year I offered to give it a go and the spec quickly escalated/became more fun!
As I’m building this more for the team than the players it needs to be easy for them to use while dealing with the festival punters who are typically moderately inebriated… Resetting the board easily, keeping track of the score and setting up for the next game seems like the three things to concentrate on.
The game works, or will work, as follows:
Press the start button, the counter should reset along with the targets
Give the player a Nerf gun and a clip with 12 darts
The player shoots the targets, which reset once hit, and the score is tallied
Having a bunch of clips that have 12 darts and a button that resets the game means resetting should be a lot easier than having to do it manually so that’s easy win, enter the Arduino!
I bought a bunch of hobby servos of eBay to use to reset the targets and designed a hinge with a magnet to hold up the target and a switch of some kind to track when a target is hit.
I’ve got a design working for the hinge but need to replicate it for all five targets. More details once it’s complete but here’s an incredibly satisfying video of the mechanism in action!
Bumblebee is my Roomba, so named as long ago he lost his voice. About a year ago his logic board started playing up and though he was still able to clean, at the end of each cleaning cycle he wouldn’t go into standby and his battery would drain in no time. At that point he stopped actively gathering dust and started doing it passively as he sat behind my sofa.
Since a kid I’ve always wanted to build a robot and figured I’d kill two birds with one stone and use Bumblebee as a chassis for a mobile robot, he already is one after all, but also have the aim of returning his base functionality of being a robot hoover.
Bumblebee is an original model Roomba from 2002, he was a gift from a friend who knew I loved to tinker and gave me him broken. If I could fix him I could keep him, thankfully an easy fix as the battery was dead. This model is very simple in it’s function and behaviour, it has no mapping capability, no dock or wireless control. It apparently can be controlled using IR but I’ve never had a remote. It also lacks the diagnostics port that the newer models have that make hacking a Roomba really easy now so this is going to be a bit trickier, a lot more education and most importantly more fun!
The parts I’ve used to partially resurrect him are a Arduino Leonardo and an Adafruit Motor Controller Shield. I’ve also a Raspberry Pi 3 to add into the mix, for Wifi control and more processor intensive tasks. The idea is to use the two to thier strengths; the Arduino will control the motors and read the sensors allowing for real time override in case of collision and the Pi will be able to sit back and give out the orders. It’s a classic split for mobile robots but thankfully very cheap to implement now.
As I said I’ve been working on this for a while, I’ve a load of notes to type up and a loads of “learning experiences” to share. Mostly when I made a rookie error and burnt out one of the motor controllers… I’ve now got the motors under control over serial, I’ve also a simple console application that lets me drive him around and toggling the sweeper/vacuum fans on, here’s a video of him in action:
My next item to look at is getting sensor data into the Arduino, first up the encoders. Encoders are devices that allow you to measure the movement of a wheel, you’ve likely used a rotary encoder on a hifi to control the volume, and the Roomba has one is each wheel. Right now I can control how much power goes to each wheel but because of differences in the state of the gearboxes, carpet and who knows what other factors, the wheels spin at different speeds. By measuring the speed from the encoders we can compensate for this, we can also use them to calculate the distance we’ve travelled.
After that is the rest of the sensors, those I’ve found so far are;
Cliff sensors – these are under the bumper and detect drops to prevent him falling down stairs, I think there are four of them and they appear to be IR distance sensors
Bumper sensors – these detect collisions, I think there is one at either end of the bumper so I’ll know if I’ve hit something to the left or right
Wall sensor – another IR distance sensor mounted on the right of the bumper, this allows for wall following behaviour
Wheel up/down switches – One on each of the drive wheels and one on the caster at the front. They detect if the wheels are up or down and can be handy for detecting when we’ve beached ourselves.
Wheel encoders – these were IR LEDs and a light dependant resistor. I blew one of the LEDs by accident so replaced them both with red LEDs.
Beacon IR Reicever – Not sure how this works yet, it’s a 360 lens on the top that receives a beam from the virtual wall, a device you place by your door to stop him escaping, I’m hoping to add more sensors to make this redundant.
Buttons – there are three buttons for room size to start different cleaning cycles. They could be useful though I may not bother with them.
Once I’ve all the sensors connected I’ll be able to hook up the Raspberry Pi to start working on reproducing his original behaviour. After that I’ll be able to build up his capabilities over time and add a load of new ones too. I’m not intending this just to be a hoover but a mobile robot platform that happens to be able to hoover.
If you’ve got this far, kudos! That’s it for now, more posts will trickle out as i write up my old notes. I’m going to carry on having fun building things and write posts in the order they happened. Hopefully I’ll catch up fairly quickly!
All my previous jobs were based in the town I live in so I used to be able to cycle to work, with my current job it’s far enough away I can’t reasonably cycle to work. As such, and as the company is jokingly referred to as the “Cake-apult” for the amount of cake we seem to go through, my weight has inevitably increased. To try and remedy this I’ve recently purchased a DeskCycle. I would like to give a walking desk a go at some point but this seems a far easier solution and as sitting down for extended periods is linked to many problems I figured it worth a go.
It arrived earlier this week and I managed to cycle while sat at my desk for over two hours each day, I felt knackered by the end of it so it was certainly having an effect! The only issue for me is the speedo. The creators of DeskCycle designed the device such that the speedo is accurate when the resistance is set to maximum, this results in the speed and calories calculated too high if you have the resistance set lower. They provide a calorie calculator to provide a more accurate set of results once you’ve punched in the values your speedo provides.
On to the how;
Looking at the bike it looked like the speedo works in the same way to the speedo on my road bike, a switch is closed once per revolution of the flywheel. I connected my multimeter to it in continuity tester mode and it confirmed my theory. As the bike uses a 3.5mm headphone jack for a cable it was simple enough to make a cable to connect to the header on my Arduino.
The cable has a 3.5mm headphone jack at one end, tip and ground in use, and a pair of header pins at the other. Connected to the Arduino via a bit of breadboard, I’ve connected using pin 7 in pullup mode with the other end of the switch connected to ground.
Once connected I’ve followed the timer tutorial provided by Amanda Ghassaei to calculate the RPM by counting the interval between revolutions. One thing I learned is that the millis() function uses timer0 internally so if you want to use that function and a timer interrupt then use timer1 or timer2.
Next up is a simple application that reads the RPM and calculates speed and distance to display it on my PC to start with. I’m intending to add some cool functions like map integration to do virtual challenges such as Lands End to John O’Groats and similar which should be good for a laugh.
Also, this same code will be the basis of the digital speedo adapter for my Mini so two birds with one stone! As practice for my Mini speedo, and more practice for stuff for work, I’m going to write it using C# and Unity 5.
Update: The Unity part is done, more information here.