FTC: Designing a Drivetrain

In preparation for the next FTC season that will be revealed next month (which hopefully will be one that involves launching things into the air), my team decided we should begin planning out the most basic parts of our robot. Last year, our drive system was extremely cumbersome and not that easy to fix. Swapping out a burned out motor was difficult because they were wedged between all the compact electronics.

In an attempt to fix these issues, I began designing a modular drive train. This time I would also use CAD first, then begin build afterwards.

I had several designs in mind, each of which involved having the axis of the motor be in the same plane as the wheels. I didn't like having the motors stick into the robot, and having the motors closer to the outside would make swapping in new motors easier, in the event that they burn out (hopefully this system solves that problem too). To get this to work, I needed to either use bevel gears or a worm gear to change the axis of rotation from the motor to the wheel. Worm gears would create too much reduction, and were removed from consideration.

I thought about having the motors oriented vertically, but this would make the design wider again.

Eventually, I saw an image of the FRC RAW Box gearbox with two motors oriented towards each other, and perpendicular to the output shaft:

Dead source: https://www.chiefdelphi.com/media/img/bb2/bb21e809691ce201313d00aed3241f3d_l.jpg

Aha!

Barn Door Tracker

I don't think a barn door tracker works this way.

In an attempt to get longer exposures of deep space objects, I decided to build a barn door tracker. This would help track the stars so there is no trailing created by the rotation of the earth, The general concept behind the tracker is that the camera is mounted on a hinge, and the axis of the hinge is pointed toward the celestial pole (the apparent axis of rotation for the earth; it's near the star Polaris in the norther hemispehere). The hinge would rotate at the same rate as the earth, so to the camera the stars appear to be fixed in place. About a month ago I tried making a hand-cranked one, but there many severe problems with it. I didn't have a second ball head, so I couldn't aim the camera, and the setup lacked any rigidity, so any attempt to compensate for the rotation of the earth was negated by the wobble created by my hand. Not to mention I didn't have a real way to properly align with the celestial pole.

Nixie Clock: Programming

I was able to get some simple code running on the Nixie Clock that displays the time and flashes the separators once every two seconds. I initially tried to write my own code for interfacing with the DS32321, but I kept running into issues. The ATMega328 datasheet (for the I2C setup and status codes), the DS3231 datasheet (for register addresses), and this website were all indispensable when writing the code. In the interest of time, I decided to just use a library. It worked perfectly, and I was able to set and retrieve the time.

I now need to add fancier animations and more modes for showing the date, temperature, and timers.

Nixie Clock: Finally Ready for Programming

After several pass with the toothbrush, isopropyl alcohol, and the occasional use of the soldering iron, I finally got all the issues ironed out. It tool quite a while to clean off all the flux, and every time I had to re-solder a pin, I made sure to clean the flux off.

Here is a video showing all segments operating independently:

Nixie Clock: Debugging

Well, as soon as I began programming, I ran into issues everywhere. Along with all the issue I listed yesterday, I realized that the flux I used, Kester SP-30, (which my dad for me a got for me a long time ago, but I never used it) was plumbing flux. And according to the data sheet, it is "too corrosive for electrical or electronics soldering applications." More searches turn up that not before long this flux will probably corrode all the SMD joints.

I decided to test my hypothesis that the flux residue was conductive and causing the numbers to light up randomly. I wrote up a simple program to cycle between all the digits one by one to see if there were any shorts between and pins. Interestingly, sometimes digits near the one that was actually powered would light up. As the number which was powered got closer to the numbers that weren't supposed to light, the ones no supposed to light up got brighter. There was definitely some sort of connection between multiple digits, and only thing I could think of was the residue.

I took out some isopropyl alcohol and cotton swaps to begin cleaning off the residue, hoping that the lighting up issues would go away and to see if I could minimize any future corrosion from the flux.I didn't have a brush handy so this took quite a long time, and in the end there were cotton fibers caught all over the place on pins and not all the flux in tight spaces were gone.

After cleaning up as much as I could, I tested the clock out again and it improved significantly. The last digit was no longer lighting up, and fewer digits were lighting up out of place. The reset line was now holding at 5V and didn't require the extra wire any more.

I will definitely need a brush to clean out all the flux residue. I hope this will solve all the issues so I can get back to programming.

Nixie Clock: Circuit Complete

I got the PCBs from OSHPark two days ago and finished assembling one board.

The assembled circuit.

Nixie Clock

I haven't done a project in while and decided I wanted to build another clock. I've always liked the look of Nixie tube clocks and decided to build one. This time I wanted to try using surface mount parts to keep the costs down.

For hardware, this clock uses six IN-14 Nixie tubes for the digits and two IN-3 tubes for the digit separators. An ATmega328 (I'm still not sure if I'm going to use an external crystal or not, but there is room for one on the PCB) is the main controller and a DS3231 RTC is used for time keeping.

Nixie tube with high voltage power supply in background.

Nixie tube testing.