After the mechanical bits were assembled yesterday, I worked on the simple PIC program I’d need to drive it. This involved refining the exploratory code into something that resembles an usable device. Things like no longer running on a fixed program but read the potentiometer I wired into the circuit to dictate motor control. Fortunately most of the hard work is done by MPLAB X boilerplate code, I only had to weak a few things here and there to end up with the functionality I want.

(The MPLAB X project file is publicly available on Github.)

I also 3D-printed the remaining layers of the enclosure – the battery tray, a minimalist lid, and the little flexible clips that hold them all together. The layers are an extremely tight fit because the wiring plugs were longer than I expected. Right now they’re pressed against the bottom of the battery tray which is not good for connector health. I’ll increase the height for the next iteration to give everything more headroom.

The good news is that everything runs. The bad news is that it doesn’t run very well. I dug a digital camera with a built-in time-lapse mode, set it on top of the base, and shot a few clips. The jittery motion of this cheap DIY pan base is very clearly visible in the resulting video. There’s a reason professional photography pan heads cost a lot of money – they have much smoother bearings and better motors for fine control.

Since the conference kicks off tomorrow, I’m going keep forging ahead with what I have. No time to find better motors or bearings. There are a few issues that I might be able to fix in the PIC software, but the sticky jittery motion from the motor and bearing isn’t something I expect to be able to fix in code.

Well, I can hope the jittery motion is not visible in the default 128×96 resolution of the camera!

Hackaday Superconference 2017 kicks off tomorrow! Clock is ticking for me to complete my preparation work. My 3D printer is hard at work churning out iterations of my motorized base for panning photo/video. I had originally intended to drive the whole works with my three-cell lithium lion battery pack built from cells salvaged from a Dell laptop battery pack. The battery power will go straight to the power coils of the stepper motor and a voltage step-down converter will reduce the voltage for the ULN2003 chip driving the steppers and my PIC16F18345 running a program to run the works.

The stepper motor is designed for nominal operating voltage of 5 volts, but the actual limit on stepper motor operation is the amperage running through its coils. I thought I could drive the coils with pulse-width modulation and keep the power under control. The batteries power is about 12 volts, so a 40% duty cycle should be a good approximation.

But real life got in the way of my plan with these unipolar stepper motors. As the coils are energized and de-energized in the PWM cycle, magnetic field and electrical current were getting sent elsewhere in the motor in ways I didn’t understand. Causing the motor to behave erratically instead of just turning at a lower power.

If there wasn’t a looming deadline, I would hit the web searches to learn and understand what’s going on so I could fix the problem correctly. But I do have a deadline and needed a quick fix. “Just” running the motor at full power isn’t a solution. The motor could run at ~12V but it gets very hot. If I was only using the motor to turn infrequently, this might be OK. But a camera pan base is constantly turning slowly.

In order to keep the coils energized with a lower voltage, I changed the power supply to a 4-pack of NiMH AA batteries. Their nominal voltage of 4.8 is close enough for my purposes. It is smaller and lighter than the Li-Ion pack and also eliminates the need for the voltage regulator. The trade-off is a drop in power capacity… which may or may not be important. We don’t know yet. I guess I should pack a NiMH battery charger.

Once the stepper motor power was sorted out, I added a potentiometer to give manual control of rotation direction and speed. Once I finish 3D printing a case around this, I will have a minimal implementation of the mechanical base.

It’s Wednesday and a concrete plan is way overdue if I want to make a project for Supercon 2017 this coming weekend. The badge is a little digital camera so I started thinking about camera accessories that I could build. Since I won’t have the camera itself until Friday, ideally the accessory has some baseline functionality that I can build before I get the badge itself.

There are tons of accessories for photography, but when the goal is to find something both electronic and mechanical, that narrows down the list. Browsing through a photography catalog, I considered a few accessories and settled down on one thing: a pan base. Useful for taking panoramic photos or time-lapse videos, it boils down to a little mechanical platform to turn the camera at a controlled rate as it does its thing.

And most importantly: I can build something basic by this weekend and build upon it through the weekend as time and progress allows. This incremental development means if I don’t get to them all, I’ll still have something neat to show off. This minimizes the risk I’ll get to the end of the weekend and have absolutely nothing to show.

Phase 1: Base Mechnicals

Build the electrical and mechanical parts of the pan base. Digging through the boxes of parts on hand, I think I have everything I need to build the base itself: I have a small slow stepper motor, an associated controller board, a thrust bearing for everything to spin on, and batteries. A PIC with a simple program should be enough to drive the controller board for a slow photography panning motion.

Hopefully I can get it all put together by Friday, ideally with manual control so it can run by itself.

If this is all I could do, it should be enough to put the camera badge on top and turn on video recording mode for a video that pans across the field of view.

Phase 2: Camera Time-Lapse Mode

If I get the mechanical base working on its own before Friday, it’ll give me time to dive into writing the software for the camera. I’ll need to understand the sample code enough to know what pieces I need to copy/paste to build a time-lapse video app for the camera. Hopefully it’s as simple as taking the video recording application and slowing the frame-rate down.

Once I know the code necessary to gather images and put them in a sequence, I’ll worry about creating the UI to control things like time-lapse speed.

If this is all I could do, it’ll be enough to create cool time-lapse panning video clips to enter into the video contest.

Phase 3: Camera+Base Integration

This is the stretch goal in case everything above was easy and smooth (ha!): Integrate the camera and the base so the time-lapse application controls the panning base. The UI will allow control of not only the frame rate, but also the rotation speed as the time-lapse runs. The camera badge already has a simple API for I2C communication, so I’ll probably have to write code to talk to the PIC controlling the stepper motor via I2C. Either that, or have the PIC32 on board the camera talk to the stepper motor board directly. Whichever is easiest to get running by the end of the weekend.

If I can get this far, I can feel proud at what I have accomplished over Supercon 2017.

Let’s see how far I get. It’s time to get to work!

 

The calendar does not lie – it is now Tuesday and Superconference starts Friday. After a day of playing with mTouch on the Curiosity board, I’m no closer to a project that captures my fancy. Time to take off the curious explorer hat and put on the project manager hat. (Assuming that it’s not already too late to do so…)

The fact is that I won’t have the camera badge hardware in my hands until Friday. Despite all the help Microchip tries to give us with libraries for doing mTouch, capacitive touch is finicky and will require tuning. On top of having to get oriented with the rest of the hardware. On top of the rest of the conference going on over the weekend. I don’t want to be so consumed by the project that I miss out on interesting things happening.

I’m sure there are hardware hacker types who has accumulated enough skills and experience to put together something in a short time. I have ambition to build up to that skill level, but I have to accept the fact that I’m not there today. And I’m probably not going to get there by the end of the week. Time to change the focus to something more predictable and less risky for the sake of getting something up and running this weekend rather than risk having nothing at all by the end of the weekend.

The new ideals:

• External components interface with the camera badge in some way to add to the camera badge functionality.
• External components do not require the camera badge itself for its basic functions, so I can start building it and debugging it before I get the badge Friday.
• Integration with camera badge to be kept as simple as possible.
• Integration should not be “none” – it’d be pointless to build something that works just as well without the camera badge.
• Even if all integration efforts fail (at worst, integration is “none”) I want to have enough to demo the idea even if it doesn’t work.

The above ideas led me to think about building an electro-mechanical camera accessory. The gears in the brain continue turning…. but soon physical gears will turn, too.