VR gun recoil.

[mAchiNE]

All very good ideas, but the whole point I think for using a sound activated control circuit powering a solenoid is so you get the various power and frequency of the different weapons kick back while not needing any special drivers to make it work (making it console compatible too), but I guess how important this is depends on your setup.
I like the look of that electric air-soft gun as an easy option for a non solenoid (non variable force) based setup, all the hard work is done for you, having semi auto, burst fire and full auto modes on a selector means that you could wire micro switches to the selector and have it switch your weapons/weapon mode in game depending on game (i.e. in battelfield you could have the selector automatically change you machine gun between burst fire and full auto in game) I guess the harder part would be cramming the buttons and analogue sticks in there for the controls.

[mars3554]

I think you might be looking at "sound activation recoil" from a 30 thousand foot view. The devil is in the details, are you looking for a specific frequency (sound signature)? If so, you need to filter out all the other ones. If you use a hardware filter, you cannot change the pass-band frequencies after you build the circuit (easily) so a guns that has a different pitch will not trigger the recoil. You could run a digital filter but that is even more complex. If you use the amplitude to trigger the recoil (gun loudness) then you have to make sure that your own gun is much louder than all the other stuff going on in the game like explosions and other player's guns firing nearby.

It would be relatively much less complex to look at the trigger switch and run a relay to a I/O pin. You won't know which gun you are firing but you will know for sure that you are firing something.

It's also possible to scan the game's application memory space and figure out when you are firing and what gun, ammo, health and other things are going on in real time but that too is a bit hackish.

[bobv5]

"I think you might be looking at "sound activation recoil" from a 30 thousand foot view."

Not quite. Perhaps 5000.

"The devil is in the details, are you looking for a specific frequency (sound signature)? If so, you need to filter out all the other ones. If you use a hardware filter, you cannot change the pass-band frequencies after you build the circuit (easily) so a guns that has a different pitch will not trigger the recoil."

You most certainly can easily change the frequency. For example, if using a simple RC filter, a variable resistor can be used instead of a fixed one. Another option is a digitally controlled potentiometer. SOftware is not my strongest talent, but I can imagine some sneaky tricks can be pulled this way. Games generally dont include much audio at very low frequencies, so I feel only low pass filtering is needed. If this turns out to be wrong, high pass filtering can be dealt with in a similar way.

"If you use the amplitude to trigger the recoil (gun loudness) then you have to make sure that your own gun is much louder than all the other stuff going on in the game like explosions and other player's guns firing nearby."

The gun sounds are generally pretty much in the center of the stereo soundstage. MIxing the left and right channels gives virtual center at +3dB. Not a huge difference, but hopefully enough that to the digital section of the circuit, player gun sounds are usually the loudest thing. Even things at dead center in the virtual world will probably be further away than the player weapon, so make less noise.

"It would be relatively much less complex to look at the trigger switch and run a relay to a I/O pin. You won't know which gun you are firing but you will know for sure that you are firing something."

Absolutely. But I'm kind of a masochistic electronics nerd. It would iritate me that I knew it could be done better, and, well, the easy way is boring.

"It's also possible to scan the game's application memory space and figure out when you are firing and what gun, ammo, health and other things are going on in real time but that too is a bit hackish."

Every solution to this problem is going to be a bit hackish. I think this would provide far better results, but it is beyond my ability to provide the PC side software.

My circuit will use a combination of a hardware low pass filter, a hardware mixer to reduce the level of sounds not in the center, software to look at the amplitude, and a switch to see if the trigger is being pulled. I think this is about as good as it can get while still remaining compatible with most software.

[WiredEarp]

As another thought to throw out there, what about using noise recognition?
IE, pump the noise from the game through an algorithm that when you have pulled the trigger, only shoots when it hears the particular samples it has been 'trained' for.
IE, you could train it in all the different gunshot noises for a specific game, then it will only fire when it hears one of those noises.

Possible issues could be to do with other gunshots close by setting it off, but if you also matched on volume levels (you'd need careful control of volume levels) then it could still work.

[mars3554]

"I think you might be looking at "sound activation recoil" from a 30 thousand foot view."

Not quite. Perhaps 5000.

"The devil is in the details, are you looking for a specific frequency (sound signature)? If so, you need to filter out all the other ones. If you use a hardware filter, you cannot change the pass-band frequencies after you build the circuit (easily) so a guns that has a different pitch will not trigger the recoil."

You most certainly can easily change the frequency. For example, if using a simple RC filter, a variable resistor can be used instead of a fixed one. Another option is a digitally controlled potentiometer. SOftware is not my strongest talent, but I can imagine some sneaky tricks can be pulled this way. Games generally dont include much audio at very low frequencies, so I feel only low pass filtering is needed. If this turns out to be wrong, high pass filtering can be dealt with in a similar way.

"If you use the amplitude to trigger the recoil (gun loudness) then you have to make sure that your own gun is much louder than all the other stuff going on in the game like explosions and other player's guns firing nearby."

The gun sounds are generally pretty much in the center of the stereo soundstage. MIxing the left and right channels gives virtual center at +3dB. Not a huge difference, but hopefully enough that to the digital section of the circuit, player gun sounds are usually the loudest thing. Even things at dead center in the virtual world will probably be further away than the player weapon, so make less noise.

"It would be relatively much less complex to look at the trigger switch and run a relay to a I/O pin. You won't know which gun you are firing but you will know for sure that you are firing something."

Absolutely. But I'm kind of a masochistic electronics nerd. It would iritate me that I knew it could be done better, and, well, the easy way is boring.

"It's also possible to scan the game's application memory space and figure out when you are firing and what gun, ammo, health and other things are going on in real time but that too is a bit hackish."

Every solution to this problem is going to be a bit hackish. I think this would provide far better results, but it is beyond my ability to provide the PC side software.

My circuit will use a combination of a hardware low pass filter, a hardware mixer to reduce the level of sounds not in the center, software to look at the amplitude, and a switch to see if the trigger is being pulled. I think this is about as good as it can get while still remaining compatible with most software.

I see that I didn't need to be as detailed in my explanations!

Yes you can set a passband by changing R's and C's but once you set it, it is typically permanent. If you want a moving passband, you still have to write the software to do it. I suppose you could look at the frequency spectrum for a repeating amplitude spike which would correlate to repeated fire. Maybe I am over thinking things.

I should point out that assuming the gunshot signal is the loudest at the center channel is only true if your looking view vector is the same as your gun aiming vector. This is true for almost every game so you should be fine but VR setups should separate the two axis so you can look left while shooting right. If that is the case then the initial center channel assumption is no longer valid.

[mars3554]

As another thought to throw out there, what about using noise recognition?
IE, pump the noise from the game through an algorithm that when you have pulled the trigger, only shoots when it hears the particular samples it has been 'trained' for.
IE, you could train it in all the different gunshot noises for a specific game, then it will only fire when it hears one of those noises.

Possible issues could be to do with other gunshots close by setting it off, but if you also matched on volume levels (you'd need careful control of volume levels) then it could still work.

If you have the ability to write software that will inject a signal into your audio line, why not use a dedicated virtual com port instead of an audio jack?

easiest way (to me) is to take apart your mouse and find the microswitch for the left button and run a relay that will trigger your secondary circuit.
That way when you press the mouse button to fire, ingame will shoot as normal but the relay will also trigger your recoil mechanism to fire at the same time.
The two circuits are isolated so you don't have to worry to much about the electronics.

[bobv5]

I think he meant the software on the microcontroler. It is certainly a possibility, but I wouldn't have a clue how to program such an alogorithm.

[WiredEarp]

Actually, I was referring more to a windows 'driver' that would listen to the sounds outputted and try to match them with samples.

However, this could be trickier to do on Windows 7 etc since I believe 7 etc only allows you to output to one device at a time.

@ mars, I have a similar idea/setup. I have a PS1 gun that has recoil. When firing single shots, it gives recoils once (cos you only pull the trigger briefly). When you hold it down, it gives continuous.
Now, the recoil might not match up exactly with the firing, but it definitely aids immersion. Nice to feel the gun rock in your hands a little when firing full auto...

[mars3554]

I haven't seen one of those for a long time. I hear it's hard to find these days. Do you have a model number?

@ mars, I have a similar idea/setup. I have a PS1 gun that has recoil. When firing single shots, it gives recoils once (cos you only pull the trigger briefly). When you hold it down, it gives continuous.
Now, the recoil might not match up exactly with the firing, but it definitely aids immersion. Nice to feel the gun rock in your hands a little when firing full auto...

[WiredEarp]

I can't find a model number, but its an 'Avenger Pro'.

I just realised its also got a foot pedal you can use as well. Its decent for the $20 secondhand I paid for it years back. Uses a motor drive of some sort (rotating cam or lever I guess) to work the slide.

http://www.amazon.co.uk/Fire-Internatio ... B00004TNN7

video: http://www.youtube.com/watch?v=dVCy9XGct8A

[bobv5]

I see that I didn't need to be as detailed in my explanations!

Yes you can set a passband by changing R's and C's but once you set it, it is typically permanent. If you want a moving passband, you still have to write the software to do it. I suppose you could look at the frequency spectrum for a repeating amplitude spike which would correlate to repeated fire. Maybe I am over thinking things.

I should point out that assuming the gunshot signal is the loudest at the center channel is only true if your looking view vector is the same as your gun aiming vector. This is true for almost every game so you should be fine but VR setups should separate the two axis so you can look left while shooting right. If that is the case then the initial center channel assumption is no longer valid.

SOmehow I missed your post last time I looked at this thread.

The passband wouldn't have to be permenant, just pre selected. For example you might need 100-1000Hz for one game, but 500-2000 Hz for another. This could be adjusted with pots, or selected from a menu on a microcontroller.

As for you sugestion of using some sort of machine inteligence, (is that a good way to describe it? I don't know a better way), it is something I have considered. At the moment I want to get the hardware working with some basic version of the firmware. Software can be updated at anytime, hardware not so easily.

I have considred about software with seperate aiming and viewing. If someone is writing new software, they could provide a proper signal to a comport. If they can't or won't, the gun will still be relatively close and relatively central, and often still the loudest sound, so it shouldnt reduce performance too horribly. If somebody is pointing a gun behind them and firing, their disregard for the safety of their comrades precludes them from being rewarded with satisfying recoil effects.

I am not claiming the feedback will be perfect, but I hope to achive something that is pretty close when the player is more focused on what they are shooting.

[OscarJimenez]

Awesome! I have this gun on the way: http://www.amazon.com/STAR-Dragon-AEG-A ... B00547O6O0" onclick="window.open(this.href);return false;

Looking forward to building a nice tracked gun, hopefully with whatever you figure out.

Hi there. Palmertech, as you are an engineer working in VR and all, and seeing that you're looking for a nice gun to work with in this context, you may be interested in this link: http://www.virtual3dgun.com.

These guys are spaniards -just like me, incidentally, I don't know them personally nor did I know about them until just a couple of weeks ago- and seem to have been working on this project since 2006 no less, with what seems to be, at first sight, very nice results from both performance and ergonomic point of view.

They also claim that they don't use IR tech for their work. I copy and paste what one of the engineers had to say in response to some cynical user in one of their youtube video's comments: "No, it's not a trackir because it's not valid for the movement of the gun. Our system haven't point of reference in any site, for this reason it also function with a virtual reality googles without problems".

You may be interested in dropping them a line and share your thoughts about it, when/if they answer. I've been a silent reader of MTBS site and forums for a long time now and I'm curious about your opinion on this myself. I also happen to be a fierce enthusiast of VR -only platonically tho, for lack of resources, mostly- and everything that successfully increases immersion in gaming ine way or another. I once built myself, many years ago, a big, bulky Aliens-like machine gun out of a Sega Virtua Gun and a toy recoiled weapon, and the kick I got -no pun intended- from using it for playing Virtua Cop in my Saturn with the infinite machine gun cheat on was so amazingly enjoyable that fantasizing about a whole fleshed version of that using modern technology has always been a dream of mine.

Keep up the good work.

[cybereality]

Man, I used to love playing Virtua Cop on the Saturn. Those were the days...

[OscarJimenez]

Man, I used to love playing Virtua Cop on the Saturn. Those were the days...

Weren't they? I have to admit, however, that for me, 'It' all started with Operation Wolf. Everyday during lunch break in high school I went to the bar next to it and drop my spare quarter into that Magic Thing that made my spine tingle every single time my ears catch the familiar tune and the affected voice: 'OperAtionn InIciAtedd... rEscue ALLLL hOstagessss!!!!!!' . The rainy november day that my mom picked me up from school and handed me a copy of the C64 version that those devils at Ocean perpetrated -half my childhood lost between the four walls of my room because of those cunning basterds and their wonderful creation, DAMN them all, they are sorely missed- was one of the happiest ones of my teenage days that didn't involve girls in tight clothes and short skirts.

About Virtua Cop, I think I'm the guy who imported the concept of 'akimbo' to Spain, I swear it. People looked at me like they would a martian every time I started a game. 'Virtua Spaghetto', my friends and I used to call it. Amazing, amazing times.

[WiredEarp]

bout Virtua Cop, I think I'm the guy who imported the concept of 'akimbo' to Spain, I swear it. People looked at me like they would a martian every time I started a game

Virtua Cop playing with both guns is a lot more fun than playing with just one. Sometimes i'm glad I still have a PS2 and old TV...

[cybereality]

Virtua Cop playing with both guns is a lot more fun than playing with just one. Sometimes i'm glad I still have a PS2 and old TV...

Oh yeah, I forgot about the dual gun thing. Gangster.

[pierreye]

Operation Wolf does bring back childhood memory. Spend my few months pocket money on that machine and manage to finish all 6 missions with one credit after months of training. Luckily my dad didn't find out where I spend my time.

[WiredEarp]

@ OscarJimenez: I suspect that VRGun stuff is using gyros, gyro mice have been around for a long time and that tech would match that description you provided.

As Pierreye has shown, gyro controllers work fine. Until games get designed to use real (absolute) weapon/view control, then gyro setups will be just as good as anything absolute like optical, magnetic, etc, for playing current games, simply because the main point of drift is the mouse emulation. An easy way to realign the view (reset/hold button, auto align scripts, etc) is the important thing.

I definitely agree, any sort of tactile feedback when playing shooting games greatly helps immersion!

[bobv5]

Been very busy but still working on this. Managed to get someone to commit to giving me time with the equipment, rather than saying "maybe, one day..." That has to be good.

[WiredEarp]

I've been thinking about the issue again from the software side. Rather than trying to figure out the mem values of the variables we want to monitor, it should be possible to capture a certain graphical area and perform simple tests on it, to detect what mode guns are in (most games have a visual indicator of gun mode). This sounds intensive, but really you'd only have to do it a small time after the user has pressed a change mode or change weapon key. This would mean that it could potentially be much lower impact on the system. Kludgy, but when you consider that it will only need to be configured once, we could build a database of different games and their 'markers' without too much hassle. The big advantage of this method would be it could be close to 100% accurate and would work with new games with the same accuracy once we had added them to the DB. One disadvantage would be it would not work with games without a visual indicator. This is sounding familiar so forgive my memory if we already talked about this 2 pages back...

Of course, this is all theoretical, because I have high hopes for your project bobv5! It would save a significant amount of work, and we may well be able to get away with < 100% accuracy without breaking immersion.

[brantlew]

@WiredEarp: If you're going that route, you might consider an equally "kludgy" but vastly simpler solution of just trapping key (or controller) events. Certainly not perfect and would require some customization per user, but you could keep track of weapon switching the same way the game does. Just monitor the weapon toggle keys/buttons and maintain a weapon list that is customized per game.

[WiredEarp]

@WiredEarp: If you're going that route, you might consider an equally "kludgy" but vastly simpler solution of just trapping key (or controller) events. Certainly not perfect and would require some customization per user, but you could keep track of weapon switching the same way the game does. Just monitor the weapon toggle keys/buttons and maintain a weapon list that is customized per game.

You can run into all sorts of edge cases if you do it without checking the display. For example, you have to trap when the user also presses the keys to get to the menu, text chat, console, etc, otherwise, if he presses the weapon change key while in those modes, your system will mistakenly change modes. I rejected that method a while back as just being too unreliable, however, I guess if you put enough effort into customizing it for each game, it could work. It would not be as reliable however.

Thinking about it, I guess its not worth us putting HEAPS of effort into perfectly accurate recoil. Maybe I'll just stick with my current system (let go for single shot, hold down for auto). In the future, games designed for VR can output the correct signals to trigger things when the guns are fired.

Hey, saying that *lightbulb*, heres another avenue. I know nothing about force feedback, but if any of these games support that, you could intercept that. For example, a game may make the joystick pulse when fired, or a vibration function. We could trap that...

[brantlew]

Hey, saying that *lightbulb*, heres another avenue. I know nothing about force feedback, but if any of these games support that, you could intercept that. For example, a game may make the joystick pulse when fired, or a vibration function. We could trap that...

That's a good idea since it really is the direct signal that you are looking for. You may need to filter out things like "falling damage" or other non-weapon rumbles but it seems like a simpler and more consistent solution.

[bobv5]

If all goes well I will be getting a couple of PCB's done on monday. (I have to wait in for a package to get delivered, but that should be well before PCB time)

As far as I am aware the hardware will work well. A guy I know who is far more experienced than me can see no problems with the circuit, that has to be a good sign.

Then it is just a case of writing the firmware. I have something already done that seems like it will work on the simulator, but virtual real world sounds are not the same as the perfect sine waves in the sim.

[bobv5]

Got a board made, turned out far nicer than I expected. In a last minute panic I switched a few of the chips to through hole, as I had heard bad things about the quality of the PCB making gear I was using. It seems that this was not justified, and the second revision should be easily small enough to fit in an M16 sized magazine.

The pics are turning out horrible, but here is one anyway.

[brantlew]

cool. where do you get your manufacturing done and how do you submit your board designs?

[bobv5]

I made it myself, managed to use the equipment at the local college for a couple of hours. Thats why it doesn't look as nice as some of the boards other people make. Just as good electrically though.

[bobv5]

It has taken far too long, but this project is still making progress. I will have a proper written report, and hopefully a functional prototype, in one week.

I don't know what the rules are about publishing it, but it will be up here as soon as I can. (I used this as my college project)

[WiredEarp]

Great to hear you are still working on this bobv5, looking forwards to reading your report!

[bobv5]

Prototype finished. It works. My brain said it would, the simulator said it would, but now I know for sure.

The hardware is great. A few silly mistakes in the PCB layout, und I should have used faster diodes. Was worried the mosfets I used were too small, but they dont even get warm, so no problem.

The software I have running on the microcontroller is less good. It syncs to multiple shot weapons better than I expected, but has a delay between the first shot, und switching on the solenoid. I can't figure out why.

I used this as part of my college work, so don't think I should show the code yet. The software waits in a loop for a number of cycles while storing the values reported by the analogue to digital converter. If more cycles are above a threshold value than below, the solenoid is switched on for a few ms in a wait loop, then held off for a few ms in a wait loop, then the program starts again. I don't think it is a bug in my code, rather I have just written the code wrong. If that sounds daft, what I mean is the code is doing what I intended it to do, but what I wanted it to do is wrong. Or maybe it is a bug, you can't tell without reading it I know..

If anybody has any better ideas on how the program should work I would love to hear them. The hardware does a good job of removing sounds that are not the player characters weapon, but like I have said on this board before, I suck at software.

[geekmaster]

... but has a delay between the first shot, and switching on the solenoid. I can't figure out why.
...
The software waits in a loop for a number of cycles while storing the values reported by the analogue to digital converter. If more cycles are above a threshold value than below, the solenoid is switched on for a few ms in a wait loop ...

How long is the buffer that you are storing the analog values in? How long is the delay between the time the oldest value in a sample group is stored and you determine the threshold? If too long, it can delay when your solenoid fires. In other words, what is the sample period, and how many samples are used for a threshold determination. And are you using a sliding window on a circular buffer, or sampling discrete groups?

I am assuming there is no R/C hardware delay when firing the solenoid, right? Is a few ms enough time to get current flowing through that large of an inductor enough to move the heavy ferrous metal plunger (which would depend on voltage and series resistance)? And I assume you have reverse voltage protection diodes on the solenoids too, right?

For software problems, look for boundary cases. Is there any special handing of the first shot? Does part of the buffer get discarded? I would need to see the software to know for sure.

[bobv5]

"How long is the buffer that you are storing the analog values in?"

100 samples currently, but I don't store the values, just if they are higher or lower than the threshold. I have tried more and fewer samples, this makes no noticeable difference. I can't tell you how much time that is without sitting and counting the instructions it compiles to, and how many CPU cycles those instructions take to run.

"How long is the delay between the time the oldest value in a sample group is stored and you determine the threshold?"

I don't know exactly, far smaller than the delay. I guess it would be measured in nano seconds.

"And are you using a sliding window on a circular buffer, or sampling discrete groups?"

Discreet groups.

"I am assuming there is no R/C hardware delay when firing the solenoid, right?"

Right.

"Is a few ms enough time to get current flowing through that large of an inductor enough to move the heavy ferrous metal plunger"

Yes. The delay is present even when I send the signal to an LED I included for debugging.

"And I assume you have reverse voltage protection diodes on the solenoids too, right?"

Right again.

"For software problems, look for boundary cases."

That is what I suspect the problem to be. While typing this, I realized how fast the CPU is running compared to the input signal, and realized that I had assumed 100 samples was too big, so tried many smaller values, but only slightly bigger ones. I now think it might actually be far too small.

"Is there any special handing of the first shot?"

Not at the moment.

"Does part of the buffer get discarded?"

No.

"I would need to see the software to know for sure."

I know that, but if I post the code here, then you help me fix it, I might get a bad grade because of it. Unlikely, but not impossible.

[geekmaster]

Is your trigger switch properly debounced? If so, hardware or software debounce?

[bobv5]

Is your trigger switch properly debounced? If so, hardware or software debounce?

The trigger switch is not currently connected, so not debounced at all.