Posted on Leave a comment

Laser Cut Nerf Ball Shooting Lego EV3 Tank

For the final project of my 1A term in Mechatronics Engineering, we created a laser cut tank with the Lego EV3 kit (this was required) that shot Nerf balls, all to achieve a very special purpose: to remove the geese from the University of Waterloo campus.

There are lots of pictures of the tank below, and our design reports are attached as well, but I would like to highlight something here as well. Before going further, I would also like to give credit to my amazing groupmates Caleb Dueck and Lukas Wormald. This project was truly a group effort, and I could not have asked for better groupmates.

The treads are made out of laser cut 3mm MDF board. Using cutting a flexible pattern in to the wood, we were able to create a fully functioning tread. We attached both ends of the tread using 18AWG wire loops soldered through holes in the ends of the treads. The gears were made from This may not have been the best option for the treads, but it worked fairly well and was easy to do. The treads were not durable in the wet weather outside and one of them broke as it got wet and soggy.

The ball hopper mechanism was inspired by the design of paintball hoppers, and laser cut out of 3mm MDF. It worked very well at slow speeds, and was very repeatable. The top cover is attached with magnets and is removable in order to reload the hopper.

If we were given more time and resources, we would like to have made the balls fire faster and further using compressed air instead of a spring. However, the spring powered solution worked fairly well after some tuning, but would not fire as straight or as far as was originally planned for.

Using the Lego EV3 Robot kit was a requirement for this project, driven by the school, as these kits are easy to debug. If we were given more time and more freedom, we would have used an Arduino based platform instead, as this gives more expandability, power, and features.

The design report that we produced covering all the design decisions that were made is available here.

Videos of the robot in action can be found here.

Project By: Micah Black, Caleb Dueck, Lukas Wormald
Written By: Micah Black

Posted on Leave a comment

Touch Sensor Piano PCB Kits

Again, a long overdue project article, but I am slowly getting through them.
This project originally started when I made a mini piano on a 400 point breadboard with screws as the touch sensitive keys. I was looking for an easier way to make keys that are secure, but extremely easy to make and assemble. The ideal solution would have been a tool-less, solder-less version that costs almost nothing, but I have yet to find such a solution. So, I designed a PCB to the 3 components of the piano, and used very large, circular SMD pads as the touch sensitive inputs.
Making a PCB allowed for a much smaller footprint, as well as easier assembly although there is soldering involved now – for me it is easy, but for others possibly not.
I may get to the point where I offer this kit as a beginner’s electronics kit, or as soldering practice like many kits I have seen on eBay.
After a year or so of using it and watching other people use it, I would have made the touch pads bigger, and would love to figure out a way to play more than one tone at once to create a harmonic.

Project By: Micah Black
Wirtten By: Micah Black

Posted on Leave a comment

Backlit Display Boxes for Decoration

This article is long overdue – it is for a project that I completed while still in the early years of high school.
The same goes for many of the next articles and projects I will be posting.

One day, I decided it would be cool to mount the boxes of computer parts on the walls and backlight them with LED strips. The next weekend, that is exactly what I did.
I used some 1cm x 1cm wooden strips to create a square slightly smaller than the sizes of the boxes that I will be mounting. To those squares, I attached the LED strips which were different colors to match the main color of the boxes. Once mounted, this created an effect somewhat like a floating box, with the light coming from behind, and no visible shelving to hold the box up.
To mount all this to the wall I chose the non-permanent method of double sided tape in the form of 3M command strips. I did not want to damage the boxes either, in case I ever needed to return any of the parts that they originally contained, so I used adhesive backed velcro to them to the wooden frames.
Now for the power, these LED strips need 12V which is perfect, as I have a computer power supply that provides 12V for the overhead lighting as well. I stuck an extra connector and switch on the end of a pair of wires and connected that to the closest box. To attach the rest of the boxes, I soldered wires between the 12V and GND traces of the LED strips, at the closest points between the boxes.
Fast forward a few years to when I am now writing the article, I am somewhat surprised that these held up so long. The 3M command strips are just now starting to lose their stickiness. As for the lighting, it still works perfectly, but I did not use it as much as I had expected. The LEDs were too bright to wire in to the main light switch, so I left them on a separate switch and only really ever used them as a showpiece.
If I were to do this again, I would make the LEDs dimmer by driving them from 9 or 10V instead of 12, and wire them in to the main light switch so that they are not too bright.

Project By: Micah Black
Written By: Micah Black

Posted on Leave a comment

iPhone 4S Phone Battery Failure (Chinese Replacement) and some Project Thoughts

I have always been a fan of fixing my own stuff. So when my iPhone battery died, I bought a cheap Chinese replacement and a screwdriver kit from eBay to replace it myself following an iFixit guide. The process was super easy, and I had everything working again in less than 10 minutes. However, this did not come without its consequences.

A few days ago (months now), while charging my iPhone 4S – yes, its old but it works – , I heard a ‘pop’ and felt the phone expand.
I took the case off as quickly as I could, and saw that the back of the phone had popped open because the li-ion battery had swelled up – never a good sign.
Surprisingly, the phone was still on at this point, so I shut it off and tried to get the back panel off. I took out the 2 screws, but before continuing to remove the battery, decided to turn it back on and get the pictures off of it.
I wasn’t sure if the battery was going to continue expanding when I plugged it in to my computer to take this pictures off, as this would also continue charging it. In the few minutes that it would take me to get the pictures off, it would not transfer too much energy to the battery, so I decided to take the chance.
I was able to successfully remove all the important data, then unplugged the phone and removed the battery without further problems.
Let me be clear that this battery was NOT the original iPhone battery. I had replaced it about a year and a half ago, with a cheap replacement battery from eBay. I wasn’t expecting the replacement battery to last a long time, but it managed over 500 charge cycles, which is not bad for a cheap chinese battery. It is definitely much better than those ‘UltraFire’ 18650 cells out there.

I have been buying Chinese parts for years, and have never had any problems with them, when treated correctly. Batteries are one thing that I will avoid buying from China in the future.

This also speaks to a project philosophy that I have been thinking about and working on recently – If its worth doing, then its worth doing well. Chinese batteries are one of those shortcuts to completing a project, but not doing it well. Sometimes, it is worth the money to just get the right components. All the Arduinos that I use are Chinese clones of the original open source Arduino boards. They are cheaper, but they function just the same. None of the 50+ that I have personally used have ever caused any problems or dangerous situations to arise, so until the day comes when one dramatically fails (more than magic smoke), I feel completely safe using them as long as I treat them well according to the manufacturer’s specifications.

Posted on Leave a comment

3D Printer from old DVD Drives

Again, another project that I completed (I tried at least) long ago and never wrote an article for.
After seeing some projects on instructables and hackaday that used DVD stepper motors to make 3D printers and laser engravers, I decided that I would try my hand at making one.
I had lots of old DVD drives on hand from electronics recycling centers, and the electronics I purchased for under $50 from aliexpress.
I used a RAMPS 1.4 board, an Arduino Mega, and the A4988 stepper drivers for this, as they are extremely cheap, and I didn’t want to spend a fortune on this.
For the extruder, I bought one of the E3D clones, a PTFE tube for the bowden adapter, and the cheapest NEMA style stepper motor I could find – which turned out to be a bad idea, and there were no designs for filament feeders that fit this motor, and I didn’t want to spend the time to design one.
The frame was built out of MDF cut by hand, and 3D printed right angle brackets and M3 bolts and nuts. I was surprised how well the 3D printed bolts and nuts stood up, and the frame was very rigid.
As for the Y axis, I attached one DVD drive slider to the bottom of the frame. On top of the DVD reader sled, I attached a raised flat surface held up with springs and bolts (to allow for levelling). This surface was a 50x50mm piece of steel from one of the DVD drive casings. As a print bed, I think this would have worked fine, but I never got a chance to test it actually printing.
The X axis motion was again a DVD drive mounted to the vertical part of the frame. The DVD drive sled slides horizontally like a Prusa i3 would. To this drive sled, I attached the cover of a 2.5″ hard drive to give me more surface area to attach the Z-axis to.
Up and down motion for the Z-axis was achieved with another DVD drive mounted to the X-axis.
Connecting the stepper motors to the drivers required some prodding with a multimeter to figure out which pairs of wires were connected inside the 4 wire stepper from the DVD drives. Once the two pairs were figured out, they were attached to the RAMPS board, and were ready to test.
To the Z-axis, I attached the E3D clone extruder with a fan mounted on it. This choice of extruder (or maybe this would have happened with any extruder) proved to be the wrong one, as the DVD drive on the Z-axis was not powerful enough to raise the extruder.
The next part to mount was the endstops, and as I was mounting them, I realized I should have thought about this earlier. Some disassembly and custom 3D printed pieces were required to mount them, as well as a fair bit of hot glue, which I was trying to avoid.
Then the software – I opened up the Marlin configuration file and started modifying the values that I knew had to change. This was mainly the travel limits for all axes.
Once everything was mounted and wired up, the testing started. I connected the Mega to my computer, and opened up Pronterface to control the printer. Through this, I was able to determine the correct steps/mm values to plug in the Marlin. The other thing that this testing showed was that the stepper motor for the Y axis worked really well. However, the same cannot be said for the X and Z axes. The X-axis moved very slowly, and did not have smooth motion. The Z-axis, without help, did not move at all while the stepper was getting very hot. To try and fix this, I tried to add a counterweight (an 18650 cell) for the Z-axis, but that did not help at all.

One of the big mistakes I made while designing this was thinking of it in terms of separate items, and not worrying about attaching them until I got to that step. This caused some problems where parts would not attach together properly, and after a few hours of rigging something up, I had found a way to make it work but it was never elegant, repeatable, or sturdy enough.

Project By: Micah Black
Written By: Micah Black

Posted on Leave a comment

Simple Arduino Pong Game

Another one of those long overdue articles. I originally created this pong game 3 or 4 years ago, but it has gone through several great iterations since them.
This portable pong game has been a work in progress for many years. The components have stayed the same, but the enclosures and format have changed a fair bit.
The first version was created on a breadboard and was mostly just a proof of concept and a platform to figure out the code.
The second version was built inside a 3D printed enclosure and was a mess of wires inside.
Next version (number 3), I created on a 7x9cm perfboard and managed to keep the wiring a little bit neater, but it looked much better than previous versions with the added benefit of being more compact.
For the final version (number 4), I designed my own PCB to hold all of the components, with an easily replaceable battery holder.
As mentioned earlier, the circuit stayed the same throughout all versions (with the exception of a power LED on some). So let’s take a look at what that circuit consists of. I used an Arduino nano to control everything, a 1.8″ LCD display, 2 10K potentiometers, a switch, a TP4056 charge and protection module, an 18650 cell, and a 5V boost converter. These were wired up in logical fashion so that the 18650 cell was protected and the voltage would be stepped up to 5V for the system, and the Arduino communicated with the LCD over SPI while using the potentiometers as analog inputs to control the paddles.
For programming this, and part of the original inspiration for this project, I found an example on the Arduino website that showed 1-player pong, where the paddle could move anywhere as the ball would bounce off of it and the edges. I modified the code for this to make a 2-player version.

By far, the custom PCB version is the best because it is compact, neat, durable, and easy to wire everything up. If designing the PCB again, I would definitely use a different software than EasyEDA, as the one thing that was especially annoying was the UI. I could not figure out how to create rounded corners on the PCB, and their guides were not much help either. Since designing this board, I have figured out how to do that, but I still don’t enjoy the interface.
As for improvements on the code, there are plenty of things I would change – the main ones being a better menu, text facing the right way, and the ball not removing parts of a dividing line. When programming this, I just programmed it up to the point that it worked, and then stopped making improvements, which I somewhat regret now, but is not something I am going to go back and fix, as I have too many other projects that I am working on now.

Project By: Micah Black
Written By: Micah Black

Posted on Leave a comment

My Vision for A2D Electronics

After spending 4 months away from Ottawa (and my business) at university, I wanted to figure out where I want A2D Electronics to be in the future.
I have spent a fair bit of time figuring out how to make this less work for me and potential future employees, but I also need some direction on where this business will be going in the future.

A2D Electronics exists to provide electronics at a reasonable and affordable price so that anyone and everyone can start making things. It does not exist to make me money. When this started almost 3 years ago now, I realized that the Ottawa maker community had a need for quick access to parts, and I could do something to help that. It was an idea that filled a need and one that I thought could make me some money.
Don’t get me wrong it does make money, but only enough to cover the projects that I make and post and some extra to reinvest in inventory and pay a little towards university. The most valuable things that this company has given me are first and foremost the connections that I have made, but also a feel for how business works on a small scale.

So where is this going in the future?
I want A2D Electronics to continue serving the community. From here on out, that is the main goal.
Before we take a look at how that will happen – let’s take a look at the current situation first.
The most time consuming tasks are restocking and re-ordering inventory, packing orders, scheduling local pickups, and adding new products. The biggest problem here is that I don’t have much time – between working full time on co-op, managing my own projects, other project, involvements in makerspaces and the Midnight Sun student design team leaves me with very little time. If only I could make myself an army of robot minions…
To continue serving the community, my focus will have to shift from being an order-packing robot to a community servant.
Making those tasks easier, more efficient, and streamlined has been on the back of my mind for the last month or so, and I have come up with several solutions that will be implemented in the near future. However, these changes alone are not enough to better serve the community.
One idea that I would like to flush out is to have ‘vending machines’ for electronic components in Makerspaces around the city. These would be amazing, but how would you keep track of everything and accept payments? Those are the questions that I have been dealing with.

So how does A2D Electronics better serve the community of makers?
By making access to components easier, faster, and more affordable. Doing this will mean flexible pickup times, possibly multiple locations, more products, and increased efficiency.
For the next few months, those items will be my focus.

Written By: Micah Black

Posted on Leave a comment

LiitoKalaa Engineer Lii500 Reliability, Accuracy, and Repeatability Test

Accurately testing 18650 li-ion cells is a very important step in the process of re-using cells from laptop battery packs, or designing a new battery pack in order to create matched modules and maintain a minimum amount of balancing current to keep the modules balanced.
During my first term at the University of Waterloo, I joined Midnight Sun, the solar car student design team and am working on designing a new battery pack for the next car, MSXIV (Midnight Sun 14). During this process, we are looking to accurately test every single cells that we putting in to the car in order to determine their capacity and internal resistance. This will allow us to create perfectly matched packs if the testing is completed accurately.
New cells are being used in this car, and the tests must be able to distinguish cells that fall within the manufacturer’s specified tolerance ranges for the cells. That means that the testing method that is chosen must be accurate to 10mAh for the capacity and ideally less than 1mOhm for the internal resistance.
And so started my journey of figuring out how to test all the cells in a timely manner while not spending tens of thousands of dollars on proper commercial testing equipment.
Starting with, one of the cheapest and most popular cell testers on the market, the LiitoKalaa Engineer Lii500.
I have 9 such testers, part of my cell testing station, and used 9 different cells to test each one, one slot at a time.
Each module was tested with one cell in the same slot multiple times to determine the repeatability of a measurement in the same slot, then the cell was moved to a different slot to see how the measurements compared.
The results can be seen on this spreadsheet, and were somewhat surprising. For tests of the same cell in the same slot, the values did not vary too much, within a range of 20mAh. However, when the cell was moved to test different slots, results were changed to a spread of almost 100mAh for some testers, with the average spread between the 4 slots around 50mAh.
Given these results, these testers are unsuitable for determining small differences in capacity between a batch of new cells, but for testing cells from laptop pulls they are perfectly acceptable. Keep in mind though, that the results will be within a range of around 50mAh from the value that they show.

Test Conducted By: Micah Black
Written By: Micah Black

Posted on Leave a comment

Series and Parallel Cell Configurations

I do not claim to know everything there is to know about battery packs, but from building my fair share of packs, I am hoping to pass on a bit of knowledge.

In order to build a battery pack, individual cells must be configured in series and parallel configurations to achieve greater capacity and voltage.
Each cell has a certain capacity, voltage, and max current that can be determined from the cell’s datasheet. If a datasheet cannot be found, a general safe rule for 18650 style cells is a 1C (1 times the cell’s capacity) discharge rate.
There are a few basic rules to remember.


Parallel Connections:

Achieved by directly connecting the positive ends together and the negative ends together (+ to +, – to -).
Capacity of the cells are added together to achieve a higher capacity battery.
Voltage of the cells remain the same.
Before connecting all the cells together, be sure that all cells are at the same voltage (within 0.05V). If there is a large voltage difference between the cells, when you connect them in parallel with a wire (0 ohm resistance) then when connected together, the cells will try to balance out the voltage. With a larger voltage difference, the current flowing between the cells to balance them out will be large – and charging li-ion cells quickly will create heat.
Cells connected in parallel act as a single, larger capacity cell.
Another common question with parallel cell connections is if connecting cells with different capacities will be problematic. This in fact is not a problem. When discharging the cells with different capacities in parallel, the cell with higher capacity will discharge at a higher current in order to keep the voltage between the cells the same. If both cells discharged at the same rate, the cell with lower capacity would drop voltage quicker. Since the cells are parallel the voltage on each cell must be the same, so discharging cells at the same rate does not work. Both cells must maintain the same voltage, so the cells must discharge at different rates relative to their capacities.


Series Connections:

Achieved by connecting the positive end of one cell to the negative end of the next (+ of Cell 1 to – of Cell 2).
Capacity of the cells remain the same.
Voltage of the cells is added together.
Before connecting cells in series, it is advised but not necessary to balance the cells. The main drawback to connecting cells in series is that the cells must always be monitored to keep avoid over-discharging or over-charging individual cells.
The cells that are chosen to connect in parallel must ideally have the same capacity, age, and internal resistance (capacity is the most important) so that when charging the pack, the cells do not become unbalanced. When charging the pack, if one cell has a lower capacity than the rest, that cell will reach full charge before the others, but the battery will not be at a full charge voltage yet, so it will keep charging. The cell with a lower capacity will now be overcharged and risk heating up and going into thermal runaway. A similar thing will happen when discharging – the cells with a lower capacity will be discharged to a lower voltage than the rest and could be over-discharged if not properly monitored.
Because of this, it is strongly advised to have a Battery Management System (BMS) that is able to monitor the voltage of the pack and prevent over-discharging or over-charging cells. Higher end BMS systems will also include cell balancing – they will keep all the cells at the same voltage level either by bleeding off the extra energy in the high capacity cells through discharge resistors as heat (passive balancing), or by transferring charge of the high capacity cells to the low capacity cells through transformers or other methods (active balancing). Active balancing is generally the better option, as it does not waste excess energy, but it is more expensive to implement.



A battery with X cells in parallel and Y cells in series is referred to as XPYS.
So a battery with 3 cells in parallel and 2 cells in series is referred to as 3P2S.
This battery has 6 cells in it with 3 in paralled, and 2 of those parallel groups in series. It has 2x the voltage and 3x the capacity of a single cell.



The order of the P and S designations in the battery can mean different things. I have heard differing opinions on about whether this 2S3P battery is the same as a 3P2S battery. Both batteries will contain 6 cells, but the order of how they are connected will differ slightly. A 2S3P battery will have 3 series strings of 2 batteries connected in parallel, while a 3P2S battery will have 2 series sets of 3 cells in parallel. The main difference with the 2S3P battery would be that there is no parallel connection across the first set of 3 cells. Each series string of cells should have its own BMS, as all 6 cells could be at different potentials (voltage). It is advised to go with a large parallel group of cells, and put those large parallel groups in series if possible, unless there are problems implementing such a system. When connecting multiple LiPo batteries in parallel through their power connectors, each individual cell should be monitored, as this is a 2S3P style system. A modular battery pack might also make use of this design so that some cells can be removed, while still maintaining the correct voltage to operate whatever device it is powering. The naming and the advice here are not strict rules, but just some of what I have come across on my extensive battery building journeys.

If interested in more information on lithium batteries, here is a great article.
It leans more towards information on charging and storage safety for LiPo batteries, but has tons of great information.

Posted on Leave a comment

Block Sorting Robotic Arm

For the past few years through the robotics club at my school, I have participated in the IEEE Arduino Challenges. These are complex design and programming challenges that will test the skills of the participants – high school students. In previous years, I have done the IBM LRT Detour challenge which involves line following, obstacle avoidance, and maze solving algorithms, as well as the Green Arm Challenge to detect, identify, and sort colored blocks.
This was my second year of the Green Arm Challenge, and through the last few competitions, I have learned so much – an introduction to graph theory with maze solving algorithms, fusion 360 assemblies, and especially time management (it helps to have a working robot on competition day!).
Now on to the competition. The goal of the competition is to detect, identify, and sort 3D printed coloured blocks, picking them up from one area, and placing them in other areas based on their color. The complete rules are available here. The recommended hardware (according to IEEE) is on that page as well, but of course I made some of my own adjustments.
As with most open-source hardware, there are always some modifications required. So let’s go over what I did:

Arm and Servos: The base platform is a MeArm – an open-source 4DOF robotic arm made by phenoptix. All the instructions and the laser cutting files are available on their instructables page here. The original one was purchased from robotshop as a complete kit for way more than what I would be willing to spend. After assembling it according to their instructable, the acrylic on acrylic rotation points were sticking a fair bit, so we tried putting nylon washers between the joints. Unfortunately, that did not solve the problem. It could have been because the bolts were too tight and threading directly into the acrylic, but if loosened, the robot would be too unstable. To fix all those problems, I downloaded the dxf files from their instructables page, removed the self-threading screw holes (as bolts and nylock nuts will be used), strengthened a few of the parts, and used the laser cutter at the Imagine Space in the Nepean Centrepointe Library to cut everything out of 3mm MDF. This arm was used in the first year of the Green Arm Challenge, but the next year I redesigned it again because it was still pretty flimsy. This time it used bigger servos (MG995) for the main rotation points (shoulder and elbow) because the smaller SG90 servos were a little too slow and not precise enough to make the new laser time of flight sensor worth it. I also modified the base of the robot to include a teflon rod in a circle around the base rotation to eliminate wobble of the whole robot by providing extra support at the front and back of the robot, while not sacrificing any speed or accuracy. In fact, it actually increased the accuracy of the height and distance of the robot because the wobbling was eliminated.

Claw Modifications: As for the claw, some modifications were required for this as well. The original acrylic and MG90S servo claws had the same rotation problems as earlier – they would get stuck. With the laser cut MDF wood version, it would not grip hard enough (this would also have been a problem with the acrylic version, had it not been getting stuck). Blocks would often swing out of the claw because there were only 2 points of contact on the block, and blocks would also often be dropped because it was not gripping hard enough.The way that this claw works is also not the best – the servo gets sent to a specific position, and in order to grip hard enough, the servo has the be trying to reach a position that it cannot reach because of the block it is gripping, and ends up grinding the servo gears and heats it up – obviously not ideal. So, I added some current limiting to the servo in order to avoid grinding the gears and heating up, but with this method the servo does not grip as hard. So, I also redesigned the claw to have 6 points of contact on the blocks rather than the original 2. I also put elastics between the contact points, in order to provide some extra grip on the block. Once the servo angles for opening and closing the claw were properly calibrated, a block was never dropped or swung out again.

Ultrasonic Distance sensor: To find the blocks, we had to use some sort of distance sensor. The first year, that sensor was an HC-SR04 ultrasonic sensor. Obviously not ideal, but that’s what we had to work with. Ultrasonic sensors are not ideal to be detecting the blocks the 45 degree ‘loading dock’ area, as their detection cone is around 30 degrees wide. So, any blocks it sees could be anywhere within a 30 degree angle. To try and fiw this, we ‘swept’ across the area, measuring the distance at each degree and found the lowest distance. Then we went to the angle that the lowest distance was found at and took off a loosely guessed 5 degrees to account for sensor error as it is sweeping across (it will see the block before it is actually in front of it). However, this method proved to be unreliable. Some other methods that we tried were desoldering the ultrasonic transducers from the board, and mounting the transmitter under the claw, pointing at a 45 degree angle upwards, and the receiver above the claw, so that the sound from the transmitter will reflect off the block only when it is in front of the claw. With this, we would have to sweep across the area, but also move the claw further from the base to detect the blocks that are further away. Unfortunately, mounting the ultrasonic transducers in this location made it so that the claw could not be lowered enough to grab the blocks. The transmitter would hit the platform before the claw was low enough to grab the block. Another method we tried was attaching circular cylinders to the front of the transducers in the original location (at the base of the robot), in order to direct the sound waves coming out of the sensor. While this method worked very well for objects further away (greater than 30cm probably), it does not work for close objects, as the reflected sound waves must be coming back parallel and a few cm displaced in order to be detected, but instead come back almost right into the first transducer. Long story short, the HC-SR04 ultrasonic sensor is not suitable for this application.

VL6180X and VL53L0X ToF distance sensors: A much better suited sensor to detecting blocks at smaller distances is the VL53L0X or VL6180X Time of Flight laser distance sensor. These are ideal mainly because they use light beams instead of ultrasonic sound waves to detect objects. As a result, these have a very small detection cone (it is just a beam of light), and will only detect an object when it is actually in front of it. These sensors are also made for the range that we are using them in. The VL53L0X has a distance of 3-200mm with an accuracy of 1mm so at first, this is the sensor that we went with as the maximum distance was perfect, and we were looking for the highest accuracy possible. When testing it however, this sensor was wildly inaccurate (off by 1-2cm) at distances longer than about 13 or 14 cm, getting worse as the distance grew closer to 200mm. After paying an outrageous amount for a VL6180X from amazon (instead of my usual Aliexpress orders – this one had a deadline), we were much more satisfied with the results. The VL6180X is made for distances from 30-2000mm, with a slightly coarser accuracy than the VL53L0X. This sensor matched exactly what we needed, and worked perfectly during testing.

TCS3200 TCS230 Color Sensor and mounts: These color sensors are the bog-standard color sensors in the Arduino community because they are so cheap. The one main problem with them is that they are very sensitive to external light. If any of the lighting conditions in the room change, they likely have to be recalibrated. The other problem that this creates is a very limited and precise range. I was able to get mine working in a roughly 0.5 – 1.5cm range. On the pcb they are mounted on, come 4 5mm white LEDs to illuminate the object. As the sensor gets closer to the object the accuracy increases, and these LEDs were getting in the way. So, they were removed from the board and mounted above the sensor. To get the most accuracy and consistency as possible, the sensor was mounted as close as possible to the blocks – in the crevice where the claw closes, using a custom 3D printed mount. This took a few revisions in order to get the optimal distance, and light positions. In the first revisions, the 4x5mm LEDs were mounted above the claw servo, but in the final version, a 1W LED with constant current driver made from 10W power resistors (what I had on hand) and some transistors to allow the Arduino to control it. This higher power LED was chosen to provide more light in general, as well as more directed light. This way, the small deviances in the distance from the sensor will matter less, because there is still enough light getting to the sensor.

Power Considerations (especially with sensor shield): To power all this, and keep the wiring manageable, a Sensor Shield for the Arduino Uno was used. In order to run the servos at the maximum possible speed, they were driven from 6V. Unfortunately, this created some complications with the Servo Shield. The external power terminal block was connected directly to 5V, and was routed around the board as 5V, including into the Arduino’s 5V pin. Driving this external block with 6V would clearly create some problems. So, some PCB traces were cut and re-attached with jumper wires in other places in order to route the terminal block input to the Arduino’s VIN pin, as this pin is regulated. From the terminal block, the 6V goes to the servo/sensor headers on the shield. The 5V pin on the Arduino was connected to all other devices on the shield – I2C, SPI, and other breakout pins. Now that the servos, and only the servos, were powered with 6V, we also have to take into account the current draw. With the larger MG995 servos having a max current draw of 2 or 3A, this robot can draw up to 8A under full load. However, that will never happen as the movement, claw grabbing, and light pulsing never never happen all at once. Also, the large servos will never draw their max current as moving a small robotic arm is not problem for them. As a power source, we went with a Li-ion battery custom-made from recycled laptop batteries (either 2S2P or 3S2P depending on which one was used) because there were tons readily available. To get the voltage down to 6V, a 5A 75W buck converter was used. We could have gone with a much beefier 9A module, but given that the large current draws for this robot are never sustained, and 5A buck converter is adequate. The 6V was fed directly in to the sensor shield’s external power terminal, and the Arduino was powered through the VIN pin.

Control Library: The last main part of the build was programming – which was a fairly interesting problem. We needed to figure out a way to translate a given height, distance and angle of the claw in order to travel to a specific point and grab a block. There is an arduino library called mearm IK by yorkhackerspace on Github that works very well to control the meArm in 3D space, however I did not really like the way that you had to use it and the calibration instructions were not well documented. So I decided to make my own algorithm to control the height, distance and angle of the claw. This height, distance, angle option was chosen because block distance is a distance, height off the ground is also a distance, and the field was a semi-circle – so an angle for that makes sense. The angle of the base is controlled via a servo, which makes that part real easy. A bit of calibration to determine the maximum and minimum angles for each 45 degree area (which is not really 45 degrees on the servo) was everything required. Now for the height and distance, this was a little more complicated. After drawing out a large scale version of the robot, and some careful analysis, I noticed that the angles of the servo arms can be computed based on a cosine law. The 2 links having the same angle made this calculation a little easier as well, because we have an isosceles triangle. If I can find the messy drawings I made, I will include them here. Converting this to the servo angles proved to be a little more difficult. We had to map the angle based off of an imaginary bar parallel to the ground at the height of rotation of the servos. Slowing down the servos was also a major consideration. If the servos have too much jerk, then the block is more likely to fall out of the claw while it is moving. To limit the jerk while still maintaining maximum speed, an algorithm that found the distance to the start and end points of the servos, then slowed the movement of the servo down as it was just starting to move and as it approaches the end of its movement was implemented. In theory, this would have worked, but it seemed that the movement commands were getting ahead of the servo and as a result the decelaration as it approached the end point never happened. In the end, all the servo movements were slowed down because that was fast enough for our purposes. The first year, I put all this code to calculate the angles in the main program, and suffered through the endless amounts of scrolling. The second time around, I was a little smarter about it. I created my own library to with all the control code in it, which made the main program much neater and easier to understand.

Final Results: When the day of the competition came, we were fairly confident, having a functional robot that worked most of the time. We had even had extra time to program it to not place blocks down on top of each other if multiple blocks of the same color were gathered. After a bit of tuning to the proper layout of the field (different places to put the green and blue colored blocks), the robot was able to reliably find, retrieve, and sort the colored blocks.