Photoshop Controller: Prototype

I decided to make a small controller for my sister so that she would have more intuitive controller over some functions of Photoshop when drawing. It's rather cumbersome to have to press keys to control canvas rotation or brush size, when they are best mapped to a rotational input.

The basic idea was that the controller would emulate a keyboard, and by rotating encoders the appropriate key from before would be "pressed." If I can figure out how to map inputs directly to specific commands in a program (e.g. a volume control knob can't emulate a keyboard, it needs to send the right HID codes to control volume up and down), that would be better. For now, I'll just stick with the key presses.

I began drafting up some possible designs, and many of them really looked like MIDI controllers. I keep thinking of more and more functions, each bound to sliders, knobs, and buttons. I was even thinking of adding a small screen to... I'm not sure what it would be really useful for, but it could describe each input's configuration and show a list of presets so the controller could be used for different programs.

In the end the most important factor is user-friendliness. Someone was going to use this, and it had better not be uncomfortable to use.

For a future project.

More realistic.

She needed control over four commands:

• Brush size
• Brush density
• Zoom
• Undo (Ctrl-z!)

I planned to have three rotary encoders, and two buttons to the right of them. The first three commands are mapped to the encoders, and undo to one button. The last button could be be free for whatever other command might be useful.

I'm using the Beetle controller from DFRobot since it has a Atmega32u4, which has native USB and can emulate HID devices. It's has just enough pins broken out from the controller for my project, and isn't that expensive. (It's also because it was the only suitable controller that was cheap enough from Jameco, where I got the knobs and buttons from.) It's also programmable with Arduino, which is nice because keyboard emulation is already built in and this is only supposed to be a quick project. (I'm not too concerned that this isn't pure C code. I'll learn how to use and setup USB with C and register fiddling later when I have more time.)

Source: https://www.dfrobot.com/index.php?route=product/product&product_id=1075

The encoders are 50 mm apart, and the button on the right is 40 mm from the last encoder. I forgot that the encoders that I had on hand also could be pushed in as buttons, and realized how much better it would to be able to use the press function to use as coarse/fine adjustment toggle. As a result, I only have one I/O pin left for use with the external button. The ICSP pads are also exposed, and I think I can use some as more I/O but I'll come back to that another time.

6-pin ICSP pads exposed on the right of the PCB.

I'm also using the Beetle controller from DFRobot since it has a Atmega32u4, which has native USB and can emulate HID devices. It's has just enough pins broken out from the controller for my project, and isn't that expensive. (It's also because it was the only suitable controller that was cheap enough from Jameco, where I got the knobs and buttons from.)

I planned out a prototype by first using a scrap piece of plywood as the front plate.

The hole on the right is for one button. The button isn't installed because I didn't have a big enough drill bit for the button to fit.

I also got some sample pieces of purpleheart and black walnut wood from Woodworkers Source. At six inches long, they are the perfect size for a small project. The purpleheart looks really, really, reaalllly, nice.

The wood piece is just long enough for the three knobs. I might just stick with only the knobs. Without the other buttons there are still more than enough functions and I can use the remaining I/O to control LEDs for backlighting the knobs.

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.