For the up coming competition I wanted to provide some kits for sale that would help beginner competitors enter. But the code and connection for sensors requires a bit of knowledge. I wanted to lower the threshold further.
So I have been toying around with this idea forever, finally getting around to it. So many ‘arduino’ sensors use different connections, communications, and data handling. It’s annoying to code and connect especially when you are trying to join several sensors and you only have a couple of pins or you are using multiple sensor librarys and they conflict with each other (usually trying to use the same timer).
…anyway, if you could have all your sensors or components connect by i2c then you only need two wires for up to 128 nodes!
I’ll need to have an arduino brain and then plug in modules for
Line sensor
Motor driver
Ultrasonic sensors
Screen
Accelerometer
Encoders
etc
To test this idea I started with the Ultrasonic sensors. I still have A LOT to work on with the code, especially to make the communication more efficient but it works!
I strapped the US node to my crappy hacked toy car with a 600mA motor driver and a reclaimed battery
I have yet to update the code but I recently had a chance to upgrade the sensor node.
For this I used an arduino pro mini and some perf-board to create a more stable and version with far less sticky tape
This iteration is a bit cheaper than using and Uno. In several iterations I hope to use an AtTiny23 or a AtTiny85 with a multiplexer (whichever is cheaper) to create something close to the final product.
I couldn’t help myself, here’s a view from atop the robot. I think the speed and reactions are slightly too aggressive to say the least.
Wow its been a while I was busy with another project,
I noticed something interesting while testing the ping sensors (HC-SRO4). There are plenty of great tutorials on the modules available however few mention its sensitivities.
I found during voltage spikes and troughs, the reported distance would vary greatly and usually as a decreased distance. This explains why the robot would act erratically and not respond to change in distance appropriately. I found some FANTASTIC posts going into way too much detail on these sensors and their flaws. It was quite an enjoyable read.
The easy fix for this was to improve the power system on my prototype bot. I had been powering everything from a single lipo battery running through a 500mA 5V buck converter. YUCK!
So as the motors drew power and or changed directions, the voltage supplied to the arduino’s would fluctuate greatly. This was an obvious issue and it was pure laziness to power everything in this way. The motor power circuit should be separate from the electronics and nothing should be powered through such a noisy buck converter without voltage smoothing and dampening.
I would have never found this issue if I hadn’t been so curious and placed a oled screen on to display values from the sensors. I had previously attributed erratic behaviour to floppy construction, bad wiring, and poor coding. All of which are true but not the root cause of this particular issue.
On that note, the serial monitor is a great way to find these things but difficult on a moving project with high power demands. I would like to start experimenting with bluetooth serial link for programming and debugging but that a project that can wait for later.
Breadboard is great to prototype on. But at some stage you spend more time figuring out where that wire fell out of than improving the circuit. I was well overdue to move onto protoboard.
I’d recommend for small circuits that don’t need to fit into a box getting one of these proto-uno shields. It means you get get rid of most of the wires and worries.
My other tip for proto is to get the pinout of the chips or even the whole circuit as an image and flip it like so,
this allows you to solder the pins and run the connection wires on the bottom of the protoboard without having to remember the layout and transpose it in your head. Trust me this makes things much simpler and minimises mistakes.
Ahh much better. Now there is a separate power supply for the arduinos and the motors which has improved its performance considerably and stopped it driving away whenever I tried uploading code
I am still having issues with the US sensors while the motors are in use. I really need to hook this guy up to an oscilloscope to learn more. For now, I’ll add some pull up resistors to the i2c line and some capacitors to the Vsupply and see what difference that makes.
More work is needed to include speed changes in the code based on range to objects. The state machine needs a lot of work. It would be great to hear how other people approach coding something like this. Please PM with ideas suggestions and links
