Close

Phase 15: Fish Or Cut Bait

A project log for SWD-40: a 40% scale Special Weapons Dalek

Yes, I'm a sci-fi geek.

Jorj BauerJorj Bauer 11/12/2016 at 23:510 Comments

So, with this year's deadline approaching... what can I realistically finish? I think the answer is this:

I'm not going to get to the gun motor or the smoke generator. But everything else! A good set of upgrades. Let's see, how does it all go?

The 10A fuse, inline, is very compact compared to the circuit breakers. The relay and switch are done, up to the 12v and 5v buck converters. A1, the receiver moteino, is good - now with a voltage divider to monitor the voltage of the battery, and alert when it's getting low (by flashing the light on the power button). The two main motor controllers are stable, and - with a bit of fiddling - are now stable.

A word about that. The controllers won't switch to reverse easily. I thought they required that the motors be quiescent - sitting near zero - for a while before switching to reverse, or they'd ignore all input. Well, that's not exactly right; it looks more like "when switching in to reverse, you must ramp up (down) from zero to -0.97v, slowly."

Right. So remember for a moment that the controllers' speed input is analog. At 1v, it starts moving the motors. At 4v, it's running full out. (It appears to be 5v tolerant.) So I'd written the code to ignore the range from [-1v .. 1v] and treat them all as 0v, because they are effectively 0v (the motors aren't moving at all). Which is all fine an good - until you want to go in to reverse. If you don't "ramp up" (down) from 0v to -0.97v over some (yet unknown, but longer-than-instant) period of time, then it hates on you for the next forever-until-you-go-back-to-zero and ignores whatever input you send at it.

With the controllers being sent voltage through the range from 0 to -1v, it does what I want. I've tuned the code to (more or less) do the right thing. At least it goes in to reverse when I tell it to. Finally. Grudgingly. Might as well be a teenager or something.

ANYWAY.

The serial protocol conversion for A2 looks great on paper, but of course has an unintended consequence. The Moteino, like most of the Arduino series, have only one hardware serial port - which means that, to talk with two different serial devices at the same time, we have to do it by Bit Banging. Which takes time. Which means we're not processing RF input. Which comes at regular intervals while driving. Which leads to a truly unexpected consequence: the remote is sending, willy-nilly, commands to play music, engage brakes, move the Dalek, whatever - whenever it gets to that bit of code. And now the receiver is dumping basically every other packet because it takes too long to get through the handling code.

Okay, a quick RingBuffer to queue what's going out or coming in, and then deal with the sending/receiving processing after - and now the sending happens in one packet, and the receiving processes the bytes after they've been received in a safer way. So I can, for example, swivel the shoulders at the same time that I'm driving forward. Or have it play sounds while moving the shoulder. Or whatever.

So that's A2 sorted! A3: the teensy is doing a great job. Mostly. The WAV files are a bit loud, compared to the audio input from the wireless mic. A little input level fixing in the mixer code, and we're good there.

The fog machine, on the other hand... well, I bought three different e-cigarettes and we wind up with nothing. The first worked, but didn't seal well. The next two were identical - the battery has too damn much intelligence. "Give me the stupidest one you have; that's less for me to undo." And even that wasn't dumb enough. It has this silly "five button presses to disable the battery" which is fine, and some "three button presses to set some value or other" which I don't really understand (and doesn't match its documentation), and if that had been all, ti would have been okay.

It wasn't okay.

Apparently the embedded battery controllers hate - HATE - to have the batteries actually removed. They go in to some undocumented mode to not allow you do anything until... well, I don't know what. Yet.

This was the time to fish or cut bait. I wanted everything else done; this thing was sucking up all my time, with no obvious solution; well, it's gotta go. On to the "future" pile for you.

Which leads to the good news: everything else did get done!

Tuning the drive controllers took some time, and I finished it in the hotel with some help from a volunteer Dalek and Adipose:

Driving control still needs some improvement; I need to add trim pots to the two D-to-A lines in order to calibrate the two motors. As it is, one drives stronger than the other; by adding two trim pots, I should be able to even them out a bit which will make driving straight a little easier.

Over the weekend Bob ran in to a couple of walls (whoops) without sustaining any major damage (but will need some repainting next year!).

The only real casualty of the weekend was on the way in to the hotel from the car:

... this is a view of the bottom of Bob's carrying case; the missing wheel ripped completely off in the parking lot, making it a little difficult to pilot. But the case did its job and projected Bob through the calamity just fine.

The new power system worked much better than expected. I *never* had to recharge the battery in Bob. The remote never ran out of power, but I did plug it in to recharge it regularly.

And that concludes the 2016 rebuild for "just the drive motors". Recapping:

* new drive motor, wheel, and controller rebuild

* new removable base that easily separates from the model

* new audio system with live voice changer

* electrical system replacement (12v -> 36v)

* new remote and RF engine

* repainting

* rebuilding the interior of the carrying case due to new height of model + wheel base

Phew! 'Till next year...

Discussions