Armortek

I’m building a computer-controlled system for my King Tiger and all the other Armortek models still in the boxes

Basically, it works by connecting all of the RC receiver outputs directly to a board that uses three microprocessors to perform the logic and output the signals to the MG, cannon, animatronics, sound card, heaters, lights, tracks, etc. The power source is 24V and regulators will supply the appropriate voltages (24v/12v/6v/5v) to the servos and other devices. The sound card is synched with all the functions.

I have two questions:
1) Would anyone be interested in an all-on-one computer controller for tanks?
2) Am I missing something, i.e., suggestions as to what it should perform?

I’m currently programming on a breadboard and have the cannon recoil servo moving at a variable rate (barrel will slow as it reaches the end of the recoil). I plan to use a high-torque 6V servo with the board providing the power. The machine gun fires a 1 second burst and then moves to a different random position between each firing so the gunner can sweep the area.

I’m also programming animation logic for the commander, loader, driver, and radio/gunner so that they move in random or pre-defined motions based on a transmitter switch. Tracks will recoil (momentarily reverse) when the cannon fires (sound card will not play the reverse), smoker fan speed will be controlled based on engine speed, turret traverse sound when the turret is moving (KT has that sound on the Benedini card), etc.

I’m at the point now where I need to decide on the final hardware design, so I thought I’d see if anyone else may be interested before I start building. You can email me at m1m14@comcast.net

I didn’t go into any details in order to keep the post short, but hopefully you can see where I’m going with the programmable microprocessors.

Hi Mark, So are you meaning that the board is an all in one system, it will require a receiver, the servos, the smoker, speakers and motors. Right?
It is a good idea, it have all is needed to run a complete model.
The few points regards the flashing, recoil, and sounds.
Sounds must be different for each tank, MG and recoil/reload time also.
Maybe useful some switches to deactivate sounds/smoke.
And a water smoker compatibility for who want to use it.
I've not a model that needs this board at the moment, but probably in the future I will.
Hope this help!

Sounds awesome!

Cheers,
/Chris

Mark - good to see someone else is looking into adding a brain or two to their tanks

> Would anyone be interested in an all-on-one computer controller for tanks?

Mark W ?

> Am I missing something, i.e., suggestions as to what it should perform?

One thing which bugs me but to which I don't yet have an answer is gear changes. All these models currently move as though they have fully automatic gearboxs. Seeing the tanks at TankFest just reinforced how false this is. All the old runners there have to go up through the gears, and depending on how good the driver is, lurch at each gear change. Apart from when they are stationary or at top speed, the engine note bears little relation to the vehicles speed. Even when moving slowly, if a low gear is being used, the engine will probably be running flat out as that generates the most power and minimises the likelyhood of stalling.

I have toyed with the idea of making the sound move quickly up from idle to full revs as the stick is moved forward, then play the engine rev noise to signify a gear change and start the engine sound from near idle again.

The trick will be keeping track of where the transmitter stick is positioned, to which gear that position coresponds and to which direction the stick is being moved at any given time.

Adrian.

Hi Andrea,

You are correct about the settings needed for different models. I currently set tank-specific parameters in the software to account for the different sound boards, reload time, etc. Trimpots are available to tweek the settings for specfic models since I'm sure everyone's model will run a little different.

What I'm not sure is if it's worth the effort to add DIP switches so that all the settings can be set via hardware, or just keep the switches in the software and flash the microcontroller with specific model settings. The latter is quite alot easier.

Mark

Hi Adrian,

You posted a very interesting comment about the shifting -- I hadn't thought of that before. Good idea. Fortunately, it should be fairly easy to do what you are describing


The blue lines entering the controllers are from the receiver and the blue lines leaving the controllers are pulsed signals (same as a servo signal).

Note that the motor speed controllers [Track (ESC)] and sound card [Track (sound)] each receive independent signals. The controller knows the exact position of all the sticks, switches, etc., and can determine the rate of change, etc. I am sending the outputs based on what is actually happening from the transmitter inputs.

For example, then the main gun fires, the engine sound does not change, but the signal to the motors will see a backwards bump, whether the tank is moving or stationary.

For the KT, I plan to have the turret traverse sound whenever the turret is turning and to also run the engine sound full speed, even if the tank is stationary. I assume the gunner would want full power to the turret hydraulics. The other sound cards don’t have the traversing sound, so they would only see the full power.

I will add the shift logic to the controller and see how it looks on the bench. Unfortunately, I don't have my KT running gear installed yet

Regards,

Mark

Blimey, that's quite a bit more involved than the circuits I've been putting together

> but the signal to the motors will see a backwards bump

Unfortunately, any short pulse to the motors designed to imitate the recoil will be defeated by the acceleration/deceleration ramps built into the motor control boards, unless you bypass them and drive the motors directly.
That then has consequences in greatly increased stresses on the drive system, tracks etc from the sudden shock of the motor bumping the system into motion. Having said that, I don't know that anyone has ever tried it and we may find out these tanks are more bullet proof than we give them credit - just as long as we keep them away from Phil

The closest I got to synchronised figures was having two turning heads in the front of the tank and introducing a random timeout, at which either figure could command the other to turn and look at it, rather like two people involved in a little gossip

Adrian.

Mark Bennett wrote:Hi Andrea,

You are correct about the settings needed for different models. I currently set tank-specific parameters in the software to account for the different sound boards, reload time, etc. Trimpots are available to tweek the settings for specfic models since I'm sure everyone's model will run a little different.

What I'm not sure is if it's worth the effort to add DIP switches so that all the settings can be set via hardware, or just keep the switches in the software and flash the microcontroller with specific model settings. The latter is quite alot easier.

Mark

If your problem is the possibility that someone uses your code, you can protect it, or, if you can, just create a user friendly interface software for PC that let us choose the options we like, then the program itself will write the parameters on the board.

Hi Mark,

This sounds a really worth while project which I would be very interested in.

I have only recently joined the queue for a panzer 1V so there is no rush but have you some idea of the cost?

thanks

Bob

Mark,

I've been working on a similar system for my King Tiger, including software that will enable someone to design a custom recoil... specifically recoil length and acceleration/velocity as a funtion of time. I can send you a link to it if you're interested.

I'm using a NetDuino because the .NET framework provides a complete debugging enviroement. In addition, it comes standard with a micro-USB so the plan is to have someone to tweak the parameters from a computer without any need for dip swithches, potentiometers, etc. It already models rates of fire for the MG including the number of bullets in the belt, belt change time, barrel change time if the rate of fire was high, etc.

I'm also considering controlling everything from a tablet way there is no confusion with respect to what controls what.I will use either a mounted joy stick or an Xbox or PS2 controller because they are a lot more comfortable for me than a standard transimitter. The concept of just 14 channels or so in today's world seems very limiting!

What embedded system are you using?

Scott Swartz wrote:I'm also considering controlling everything from a tablet way there is no confusion with respect to what controls what.I will use either a mounted joy stick or an Xbox or PS2 controller because they are a lot more comfortable for me than a standard transimitter. The concept of just 14 channels or so in today's world seems very limiting!

That's a very inspiring thought! With two netbooks/tablets, you would not need one of those very limited radios... You could set up an ad-hoc network between the two and attach servo controllers and any usb accessories of preference to the netbook in the tank, like cams, any number of Arduinos, servo controllers etc. And you would have a very nice display in your hands...

Cheers,
/Chris

Scott,

I started using the Pololu Baby-O due to its very small size & low cost. However, after reading Adrian and Andrea's excellent comments & suggestions, I decided to change to a larger controller with a built-in programmer and to also add a LCD display for ease of use. I just bought a Arduino Mega 2560 since it has 54 digital channels with enough extra digital IO to support a LCD display.

I do like the NetDuino C# programming since that is what I also use at work. Does the .NET overhead cause any issues with program size or execution speed? I'm planning on using the Atmel AVR Studio 5 since it also uses the Visual Studio 2010 IDE. I may try a NetDuino next for comparison.

With the power of these embedded controllers, the possibilities are really unlimited. You idea to use tablet is really interesting

Hi Mark,

Overhere in Holland I watched a guy at our tankclub who had done this. There are realy no limits to what you can do. I'm still struggling with servo controllers and Y-cables to get all the action I want and still don't have enough empty channels.
Using LCD or tablet also brings camera's into perspective. Using mini cam's on the periscopes add's more realism. Probably easy to integrate. Cost and easy to use will be the magic words I guess. I'm interested.

Piloting the tank also over the viewfield is possible, it is called FPV (first person view) and is used on airplanes for example. It is a camera mounted on the model, you will pilot the tank viewing at video goggles or LCD screen, PC or TV.
The beautiful thing is that you can also use head tracking to move the camera in each direction (I have 180° pan and tilt) so you can see what is around you.
I mounted a camera with head tracking pan and tilt movements. It is installed on the commander position, but could be installed at any position, switchers are also avaiable on the market thats allow to change from one camera to another, so you may install cameras at other locations.
Doing a board that digitally makes these things would be super!

How are these projects going?

We have a recoil unit that doesn't match our sound system and my Dad wants more animatronics than our Tx or thumbs can cope with.

Raspberry Pi etc are dirt cheap these days. Even with wifi so I was wondering about using a smart phone or tablet to turn all the bits and pieces on and off.

Anybody got any more experiences or even code to share?

Thanks

Sam