Animatronic Predator cannon

That's seriously impressive. A little smoother movement from the cannon and it'll be perfect.
 
I like the jerkiness of the cannon movement. Makes it feel more "mechanical" if you know what I mean. Hate the smooth movement mechanics, always makes my skin crawl.

Pretty cool idea! :thumbsup
 
Thanks guys! It has been a ton of work to figure out, especially since outputs for the animatronic mask and gauntlet blades have been integrated into the controller. I have all the Predator sounds integrated as well. There's been multiple revisions to the cannon mechanism and controller setup as I've figured out all the functions- I'm now working on the third generation configuration. There's a big thread on it here:
http://www.thehunterslair.com/index.php?showtopic=3781

user_online.gif
progress.gif
 
I'm curious, from an electronics standpoint, what are the limiting factors causing its motion to be jerky? For example, what's the difference, technically, between this system, and the butter-smooth helmet-based targeting systems in military airships? Is it sensitivity/number of sensors in the helmet? The nature of the servos on the gun? The processor/app handling the translation?

It's great - I couldn't do it. I'm just curious what you'd do, if you wanted to take it to the "next level?" Would it be prohibitively expensive/not worth it?


_Mike
 
It could be a number of issues...typically, the servos are underpowered, needing more torque then it's capable of. Additionally, low end servos have gear backlash issues, and inexpensive controllers are susceptible to interference. R/C servos have controllers that monitor it's position relative to fixed point; under load, these controllers "fight" the servo motor, constantly trying to home them. Higher end components and some engineering "tweaking" can resolve those issues.

However, I'll echo everyone's comments--awesome job.

--Don

I'm curious, from an electronics standpoint, what are the limiting factors causing its motion to be jerky? For example, what's the difference, technically, between this system, and the butter-smooth helmet-based targeting systems in military airships? Is it sensitivity/number of sensors in the helmet? The nature of the servos on the gun? The processor/app handling the translation?

It's great - I couldn't do it. I'm just curious what you'd do, if you wanted to take it to the "next level?" Would it be prohibitively expensive/not worth it?


_Mike
 
Actually the jerky movement has to do with two things- microcontroller input resolution and sensor noise. Both can be overcome to a certain degree by modifying the code.
 
I'm curious, from an electronics standpoint, what are the limiting factors causing its motion to be jerky? For example, what's the difference, technically, between this system, and the butter-smooth helmet-based targeting systems in military airships? Is it sensitivity/number of sensors in the helmet? The nature of the servos on the gun? The processor/app handling the translation?

It's great - I couldn't do it. I'm just curious what you'd do, if you wanted to take it to the "next level?" Would it be prohibitively expensive/not worth it?


_Mike

I would imagine Military type targeting systems more than likely use some type of multiple degree of freedom IMU (Inertial Measurement Unit.) Most sensor boards offer up to six degrees of freedom and they're commonly used for control systems for drone aircraft. These can get pretty expensive and require some fairly complex code to work properly as you have to take readings from both multiple axis accelerometers and gyroscopes and then apply an algorithm to get a proper heading as you have to account for things like gyroscopic drift. The cost of IMU's are dropping all the time and you can now buy at least one sensor board that has a combination accelerometer/gyroscope with its own on board processor for around $300 or so.

What I'm looking forward to is the new Wii Motion Plus. It's an inexpensive gyroscope module that plugs into the back of a WiiMote and uses the same I2C interface as the rest of the Wii hardware, which is a standardized interface. You basically have four wires- power, ground, data and clock. It'll be interesting to see if I can interface it with my system. There are problems with trying to get readings from more than one sensor at a time on a common I2C data bus- I'll just have to wait and see how Nintendo integrates it within their own system and see if it can be reverse engineered. It would be much less expensive than any currently available IMU system and be much easier to write code for.
 
Nice job. I would assume much of the jerkiness has to do with the way he is processing the accelerometer input as well. The servo torque could also be an issue, as Don pointed out already.

I see in the video you have to turn your head horizontal and vertically for the cannon to track. Does it not track if you just move your head in the horizontal plane? If so, I would gather you are only using the tilt angle (or static acceleration) from each accel axis and not actually producing position/velocity by integrating acceleration. Of course, there are problems with doing this over a long time (as in dead reckoning applications), but for short time apps like this you could most likely get away with it. One caveat is you can still get jerky behavior and random walk from ill-processed accel data.

When I designed one of these cannon trackers (never finished it), I was going to use a digital compass for the horizontal motion and an accel for the vertical motion. Much cheaper than a gyro-based IMU, and sensor fusing is very common in IMUs and other tracking applications. It would make it very smooth and the cannon would also track head speed as well as position very easily. In your case with just an accelerometer, you can do this but you pay for it in the algorithm dept. Plus your micro might not be running fast enough to do all this extra processing.

At any rate, if you want any more pointers let me know.
 
Nice job. I would assume much of the jerkiness has to do with the way he is processing the accelerometer input as well. The servo torque could also be an issue, as Don pointed out already.

I see in the video you have to turn your head horizontal and vertically for the cannon to track. Does it not track if you just move your head in the horizontal plane? If so, I would gather you are only using the tilt angle (or static acceleration) from each accel axis and not actually producing position/velocity by integrating acceleration. Of course, there are problems with doing this over a long time (as in dead reckoning applications), but for short time apps like this you could most likely get away with it. One caveat is you can still get jerky behavior and random walk from ill-processed accel data.

When I designed one of these cannon trackers (never finished it), I was going to use a digital compass for the horizontal motion and an accel for the vertical motion. Much cheaper than a gyro-based IMU, and sensor fusing is very common in IMUs and other tracking applications. It would make it very smooth and the cannon would also track head speed as well as position very easily. In your case with just an accelerometer, you can do this but you pay for it in the algorithm dept. Plus your micro might not be running fast enough to do all this extra processing.

At any rate, if you want any more pointers let me know.

Jim, you more or less hit the nail on the head. :lolI looked at using a compass (and spoke with many electronics designers/data aquisition people) but came to the conclusion that without some complex code/electronics or dual compasses the cannon could also rotate when you rotate your whole body, which made it a no go. That's why I'll be interested in combining the Wii gyroscope with the accelerometer as it should allow me to get a true horizontal turn without tilting your head like a bird. The tilt is a bit off now due to the sensor placement in the helmet- I'm currently working on dual sensors. I'm also writing some smoothing code to average out the sensor readings to see if I can eliminate the sensor noise and hence the jerky motion.

Are you in Superior? I'm in Lafayette so I'd be happy to show it to you some time.

Jerome
 
See, already looking forward to v2 :) Jerome, how long did this take you? Did you already have an electronics background?


_Mike
 
See, already looking forward to v2 :) Jerome, how long did this take you? Did you already have an electronics background?


_Mike

I'm actually on the third generation already! And that's the third generation of the CURRENT system.....:lol

I started this project about a year ago and have been working on it off and on since then. The last time I studied any electronics was over 20 years ago, so I had to learn all about microcontrollers and writing code/physical computing.

When I first started looking at this I had just envisioned a simple system that was controlled using bend sensors on your fingers and it wouldn't be able to look up and down. That really was a bit cumbersome to operate and wasn't very natural.

Next I looked at keeping the bend sensor that would raise the cannon, but I figured out a system that had a cable mounted under the mask that turned a pulley/spring loaded potentiometer (mounted under the cannon mechanism) that would allow the cannon to follow your head rotation. It still wasn't able to look up/down. Now I got a natural (and smooth) rotation but fixing/routing the cable was difficult and cumbersome. Mask removal could also be a real problem.

Then I started looking at different kind of sensors. Gyroscopic, compass and accelerometers. Combo boards, IMU's, etc. I have a friend that is a data acquisition engineer that works for Learjet so I picked his brain as well as a friend that is a programmer and the brains of the engineers at Sparkfun. Compasses are affected by tilt, so you have to compensate for that and then they don't work when you rotate your whole body vs. just your head, so dual compasses could be necessary. A gyroscope could work, but it still has to be integrated with an accelerometer to a get an accurate angle of rotation. Most of the solutions I found were pretty complex in terms of programming and/or really expensive on the hardware side. There are also pretty severe space restrictions for fitting sensors inside the Predator Bio helmet as some of the IMU's available are pretty large physically. But I would get the look up/down function.......

Then I found that I could modify the sensor board out of a Wii Nunchuck controller and interface it with a microcontroller over its I2C bus. This provided me with an inexpensive and reliable multi axis accelerometer and two finger pushbuttons with an easy to use interface. I ended up writing code that would allow me to access all of the Nunchuck's functions- three accelerometer outputs, the joystick and the two pushbuttons. When it was all said and done the rotation was still a bit of a problem as the accelerometer only really gives you a stable output with respect to gravity so you have to tilt it to get the rotation. What I found was that if I mounted it in the forehead area of the Predator helmet it really didn't need much tilt at all to get a stable rotation. The beauty of this system is that there are only only two finger buttons to control everything- it's also pretty easy for me to modify the code.

Now the problem is that I need the sensor to be as level as possible in the fore/aft direction for the look up/down function to work properly (this is what you see in the video) so the rotation is off and requires more tilt motion than I would normally like. Hence, I'll probably end up using a dual sensor system. I was able to successfully integrate a programmable sound board for all the Predator sounds as well as add functions for both an animatronic helmet and gauntlet blades.

My goal in this project was to create the most realistic appearing system that was easy to use for the least amount of money. Since this is also an open source project it had to be able to be built by people that weren't electronics engineers. My plan all along has been to have a complete tutorial online on how to build this.

In the end, there may be better sensor systems that come along, but given the nature of the interface to the system and how easy it is to upload code to the controllers I should be able to add improvements over time without re engineering the entire system. I'm sure a real electronics designer would be able to come up with a better/more accurate system if they put their mind to it so I definitely welcome any input.

One newer device I've been looking at is this one:
http://www.sparkfun.com/commerce/product_info.php?products_id=8656

It meets all the requirements in terms of size, interfacing and power but it's pretty expensive and you would need two of them. The nice thing about it is that it has its own on board processor and it looks to be very accurate.


Jerome
 
Last edited:
Back
Top