Laser Tag Combat - Community Suggestions

Duck

Active member
A few years back my friends and I really got into laser tag and played quite a bit using the Phoenix LTX guns. I wound up doing deeper research into laser tag overall and started a project reversing engineering the Phoenix LTX IR prototcol to build my own guns/base station. That project was forked eventually and Riley McArdle created a very nice product for hosting games with those guns. I learned alot along the way. If people are interested in laser tag planes, I would suggest reading up on MILES tag and looking through my blog posts on the subject as a way to get started.

Commercial efforts have different issues then non-commercial. Like everything, alot of patents dictate what you can and cannot do. The Phoenix LTX system does have a patent over the protocol itself. At least parts of MILES tag are covered as well.

There are four big parts of a laser tag system, physical signals, protocols, software and hardware.

== Physical Signal ==

First you have the physical signaling mechanism. Most systems use IR which is cheap, safe and invisible (more on that later). You can run into issues with the sun in some situations and you have choose frequency, power, filters and beam focus around this. Many varients of laser tag have a 'blast' function which really just reduces beam focus so you send the same signal to many players at once at reduces range.

Some systems use actual lasers in IR or other frequencies. Those are fantastic for range and noise cancelation but high cost and generally really finicky for picking out hits. A friend from the UW Electrical Engineering department built a laser based system and determined that while range was not an issue, the beam was so focused and the sensor so small that it would not be a good system for fast moving targets. The accuracy required to hit a sensor < 1cm was just too high. To contrast, the Phoneix guns with fresh batteries work up to 200 feet with a target size of a few feet in either direction at that range. Closer to the center of the beam, hits become more reliable. Aiming is critial but easier then handgun shooting.

One additional note on IR is that while IR is invisible to the naked eye, basically ANY camera has to actually fight to avoid picking it up. The FPV cameras we use come with or without IR filters for better night vision. They will ALSO pick up IR transmissions. When debugging my project I used a cheap webcam to actually watch packets get sent and ensure everything was what I expected. In the video they actually talked about not being sure where the beam was aimed. To calibrate laser tag guns, you mount them at a fixed point, draw a dot on the wall where your 'sight' points, then turn the IR beam on and look through a camera to see the beam on the wall. You can see the alignment and the intensity verus angular displacement with your own eyes. This should roughly match what you expect from the IR LED spec sheet:
https://cdn-shop.adafruit.com/datasheets/IR333_A_datasheet.pdf

In my github project I designed a simple arduino build that could power an IR LED. Almost all of the protocol was on the computer attached to the board and the board was just a passthrough to the LED. Not being an electrical engineer my board was really underpowered and there are better ways to power an IR led using a mosfet.

-- For Planes --

The big things to consider here are going to be:
1) Sun rejection - Planes hit all sorts of interesting angles that typical laser tag guns can ignore.
2) Enagement range, focus - What makes a good game?
3) Focus chamber size - For LED systems, you need both an LED and a lense to focus the beam. For laser tag guns, this can actually take quite a bit of volume. The choices above influce this but honestly I forget the relationships :)

== Protocol ==

This is the most important part! All of the physical signaling characteristics are important but the protocol defines what you can do with the system. Here, we ONLY care about the protocol between players. We DO NOT care about the protocol for joining games, reporting scores etc. The reason is that if two guns use the same protocol to interact, what the guns do in terms of software for responding to hits, etc, doesn't matter. The system will work.

There are a number of protocols here. The two that I recall are the system used by Phoenix LTX, LTTO, etc and MILES tag. Most professional systems like the military or laser tag areans use a varient of MILES tag. Both are covered by patents to some extent.

If a particular vendor chooses to not open source their equipment, fine. The protocol being open enough that people can make equipment is critical.

The protocol is usually completely independant of the phsysical signaling mechanism. The only typical issue is a limit on packet size. The longer your packet, the longer it takes to send. For fast signals like you can do with lasers at high frequency, it matters less then slow IR signals which take a substanital fraction of a second to send. A long packet means you literally have to point at the target for longer.

The two aspects the protocol usually need to cover are:
-- Who am I - Identify the sender. Toy systems usually skip this part and can't do meaningful scores in any way.
-- What did I do - Identify the action. This could be a 'shot' or an action like heal. It might contain extra data like 'damage' for a bomb or high impact function (sniper, rocket launcher). You want to explain what the sender did here. The receivers software gets to determine what to do with it. For example, the receiver can handicap themselves and take half damage. The sender can't know and laser tag protocols are one way!

Below my github repo (the C# part) covers the protocol and the blog explains how I reverse engineered it. The patent for LTX covers some aspects as well. Riley's work also found at least one bug in my reverse engineering and uncovered a few additional features.

-- For Planes --

The protocol choice determines interoperability and can make the difference between finding people to play with and not. The best part of the Pheonix guns was their low cost (25$ each when in stock) and the fact that they were made over a very long time frame by different manufacturers with the same protocol. All those guns work together because they use the same protocol. If two groups are making systems for planes but they don't share protocols, the only way to really get games going would be for clubs to buy sets of systems that everyone at the club can use.

== Software ==

While the protocol is the most important part, software makes up the rest of what makes it a game. It can make or break the experience. The nice part is that software doesn't have to be the same between systems for them to be compatible enough for a game.

The hosting system I made used features that were only available on some models of guns. But because those features were in the protocol, guns that couldn't 'start' a game in the same way could join and play.

The software gets to set all the rules for the game and can determine how each client acts. It enables new components to be built and participate in the game itself. Nerf came out with a new laser tag set a few years ago that had lots of new features for hosting games, adding pick ups etc.

The rules that make the most difference are:
1) What sort of damange can I do
2) When can I fire, ammo count, reload time, etc.
3) How much damage can I take, what changes that like Sheilds.
4) Who can do damage to me, is friendly fire on.

Some of the features that really make the whole system work well are not obvious. This came up as a limit in my hosting system. The software in the guns could join a game but the gun would pick a random identity for itself each time. That means once you finished a game, you didn't know what score was yours without looking at your gun itself. My hosting station could actually collect scores from each player but it didn't know who was who.

The features that are important are:
1) How does each player identify themselves? Is that identity persistant?
2) How do scores get communicated back. Some systems use IR to communicate scores back which means guns need to all point at the score keeping system and try to perform a complex system of commands for everyone to report who hit them, then get a score update of who they hit. It can be unreliable. The nice thing is, nothing requires this all to use the same system. The newer nerf kits use a different non-LOS wireless protocol for reporting scores.
3) What game modes are available.

Open source makes a big difference here in managing game modes and making sure everything plays by the same rules.

The other side of the software is the game management software that lets everyone setup, see scores, get stats, etc. This is usually easiest to do outside of the guns themselves. The LTTO guns have a tiny LED screen for this but the newer Nerf guns just use an Xbox to host and a custom peripheral to talk to all the guns.

-- For Planes --

It makes the most sense to set the player identity on the system that lives with a plane.

Game modes might give even more variety here then in regular laser tag. I could see things like:
* Shoot stationary targets
* Tag
* Team elimination
* Bombing runs
* Healing via low pass (ground based TX of 'heal' bullets in wide area)
* Follow me - How many hits can you get in 60 seconds?

== Hardware ==

There are four parts to think about here:
1) The TX light chamber
2) The RX receiver
3) The controller and any additional backchannel equipment
4) The player feedback mechanisms - buzzers, sound, lights

Some laser tag systems come completely self contained and some are very modular. The MILES tag system is very modular. You get to plug in different RX domes to ensure you can be hit from all angles. Those are usally just 3 IR RXs, one in each direction just soldered to a PCB.

The light chamber controls beam width for LED systems and fancy ones are adjustable. This determines beam focus and the amplifier cirut & focus determine range.

-- For Planes --

I could see flight controllers or OSDs taking over this long term but likely the easiest path forward is something like arduino which uses a single channel from the RX to determine when to fire. The rest of the game could exist on the laser tag hardware and use visual or other indicators of progress. A backchannel would be nice but I don't know what is possible with the existing data backchannels on telemetry systems. Otherwise you could use alternate backchannels via anything supported by arduino like zigbee or WIFI. Seems silly given the amount of TX/RX gear you are carrying otherwise but without integratino there it might still be the best option.

In game feedback could be as simple as two 'level' LEDs for Ammo/Life. The Phoenix guns do exactly this. Put those in front of the FPV system and you have a HUD :) For LOS systems, plane mounted LED strips make the most sense to just indicate 'hit'.

Honestly, don't touch the flight controls. That sounds like a bad idea. This hobby is hard enough :)

The light chamber is a good canidate for 3d printing. I couldn't get a good look at the system in the flite test video but it looks like they managed to make it pretty small. I would aim for short ranges and wide beam for good dogfights.

Existing laser tag equipment is heavy because you sometimes fall on it. 150lb person running full speed into a concrete wall with the equipment first means you need to be reasonably sturdy. Nothing requires it to be so though.

Receiver domes are usually carefully placed. The self-contained systems put them on the gun itself with the reasoning that if you can shoot, you should be able to get shot. While the intuition might be to place them on all sides of the player, it isn't needed! This is usually good enough.


== Resources ==

All my posts about it:
https://executedata.blogspot.com/search/label/lazertag

Open Source code & arduino wiring diagram for building your own game host:
https://github.com/afaucher/LazerTagHost

Fork created by Riley McArdle with a very nice hosting station:
http://www.lazerswarm.com/
https://github.com/astrospark/LazerTagHost

A friend created this for laser tag games. It has no lasers! You can incorporate objectives into the game without making the system more complicated.
https://github.com/Raptor007/PiBomb
 

BillH

New member
A few years back my friends and I really got into laser tag and played quite a bit using the Phoenix LTX guns. I wound up doing deeper research into laser tag overall and started a project reversing engineering the Phoenix LTX IR prototcol to build my own guns/base station. That project was forked eventually and Riley McArdle created a very nice product for hosting games with those guns. I learned alot along the way. If people are interested in laser tag planes, I would suggest reading up on MILES tag and looking through my blog posts on the subject as a way to get started.

Commercial efforts have different issues then non-commercial. Like everything, alot of patents dictate what you can and cannot do. The Phoenix LTX system does have a patent over the protocol itself. At least parts of MILES tag are covered as well.

There are four big parts of a laser tag system, physical signals, protocols, software and hardware.

== Physical Signal ==

First you have the physical signaling mechanism. Most systems use IR which is cheap, safe and invisible (more on that later). You can run into issues with the sun in some situations and you have choose frequency, power, filters and beam focus around this. Many varients of laser tag have a 'blast' function which really just reduces beam focus so you send the same signal to many players at once at reduces range.

Some systems use actual lasers in IR or other frequencies. Those are fantastic for range and noise cancelation but high cost and generally really finicky for picking out hits. A friend from the UW Electrical Engineering department built a laser based system and determined that while range was not an issue, the beam was so focused and the sensor so small that it would not be a good system for fast moving targets. The accuracy required to hit a sensor < 1cm was just too high. To contrast, the Phoneix guns with fresh batteries work up to 200 feet with a target size of a few feet in either direction at that range. Closer to the center of the beam, hits become more reliable. Aiming is critial but easier then handgun shooting.

One additional note on IR is that while IR is invisible to the naked eye, basically ANY camera has to actually fight to avoid picking it up. The FPV cameras we use come with or without IR filters for better night vision. They will ALSO pick up IR transmissions. When debugging my project I used a cheap webcam to actually watch packets get sent and ensure everything was what I expected. In the video they actually talked about not being sure where the beam was aimed. To calibrate laser tag guns, you mount them at a fixed point, draw a dot on the wall where your 'sight' points, then turn the IR beam on and look through a camera to see the beam on the wall. You can see the alignment and the intensity verus angular displacement with your own eyes. This should roughly match what you expect from the IR LED spec sheet:
https://cdn-shop.adafruit.com/datasheets/IR333_A_datasheet.pdf

In my github project I designed a simple arduino build that could power an IR LED. Almost all of the protocol was on the computer attached to the board and the board was just a passthrough to the LED. Not being an electrical engineer my board was really underpowered and there are better ways to power an IR led using a mosfet.

-- For Planes --

The big things to consider here are going to be:
1) Sun rejection - Planes hit all sorts of interesting angles that typical laser tag guns can ignore.
2) Enagement range, focus - What makes a good game?
3) Focus chamber size - For LED systems, you need both an LED and a lense to focus the beam. For laser tag guns, this can actually take quite a bit of volume. The choices above influce this but honestly I forget the relationships :)

== Protocol ==

This is the most important part! All of the physical signaling characteristics are important but the protocol defines what you can do with the system. Here, we ONLY care about the protocol between players. We DO NOT care about the protocol for joining games, reporting scores etc. The reason is that if two guns use the same protocol to interact, what the guns do in terms of software for responding to hits, etc, doesn't matter. The system will work.

There are a number of protocols here. The two that I recall are the system used by Phoenix LTX, LTTO, etc and MILES tag. Most professional systems like the military or laser tag areans use a varient of MILES tag. Both are covered by patents to some extent.

If a particular vendor chooses to not open source their equipment, fine. The protocol being open enough that people can make equipment is critical.

The protocol is usually completely independant of the phsysical signaling mechanism. The only typical issue is a limit on packet size. The longer your packet, the longer it takes to send. For fast signals like you can do with lasers at high frequency, it matters less then slow IR signals which take a substanital fraction of a second to send. A long packet means you literally have to point at the target for longer.

The two aspects the protocol usually need to cover are:
-- Who am I - Identify the sender. Toy systems usually skip this part and can't do meaningful scores in any way.
-- What did I do - Identify the action. This could be a 'shot' or an action like heal. It might contain extra data like 'damage' for a bomb or high impact function (sniper, rocket launcher). You want to explain what the sender did here. The receivers software gets to determine what to do with it. For example, the receiver can handicap themselves and take half damage. The sender can't know and laser tag protocols are one way!

Below my github repo (the C# part) covers the protocol and the blog explains how I reverse engineered it. The patent for LTX covers some aspects as well. Riley's work also found at least one bug in my reverse engineering and uncovered a few additional features.

-- For Planes --

The protocol choice determines interoperability and can make the difference between finding people to play with and not. The best part of the Pheonix guns was their low cost (25$ each when in stock) and the fact that they were made over a very long time frame by different manufacturers with the same protocol. All those guns work together because they use the same protocol. If two groups are making systems for planes but they don't share protocols, the only way to really get games going would be for clubs to buy sets of systems that everyone at the club can use.

== Software ==

While the protocol is the most important part, software makes up the rest of what makes it a game. It can make or break the experience. The nice part is that software doesn't have to be the same between systems for them to be compatible enough for a game.

The hosting system I made used features that were only available on some models of guns. But because those features were in the protocol, guns that couldn't 'start' a game in the same way could join and play.

The software gets to set all the rules for the game and can determine how each client acts. It enables new components to be built and participate in the game itself. Nerf came out with a new laser tag set a few years ago that had lots of new features for hosting games, adding pick ups etc.

The rules that make the most difference are:
1) What sort of damange can I do
2) When can I fire, ammo count, reload time, etc.
3) How much damage can I take, what changes that like Sheilds.
4) Who can do damage to me, is friendly fire on.

Some of the features that really make the whole system work well are not obvious. This came up as a limit in my hosting system. The software in the guns could join a game but the gun would pick a random identity for itself each time. That means once you finished a game, you didn't know what score was yours without looking at your gun itself. My hosting station could actually collect scores from each player but it didn't know who was who.

The features that are important are:
1) How does each player identify themselves? Is that identity persistant?
2) How do scores get communicated back. Some systems use IR to communicate scores back which means guns need to all point at the score keeping system and try to perform a complex system of commands for everyone to report who hit them, then get a score update of who they hit. It can be unreliable. The nice thing is, nothing requires this all to use the same system. The newer nerf kits use a different non-LOS wireless protocol for reporting scores.
3) What game modes are available.

Open source makes a big difference here in managing game modes and making sure everything plays by the same rules.

The other side of the software is the game management software that lets everyone setup, see scores, get stats, etc. This is usually easiest to do outside of the guns themselves. The LTTO guns have a tiny LED screen for this but the newer Nerf guns just use an Xbox to host and a custom peripheral to talk to all the guns.

-- For Planes --

It makes the most sense to set the player identity on the system that lives with a plane.

Game modes might give even more variety here then in regular laser tag. I could see things like:
* Shoot stationary targets
* Tag
* Team elimination
* Bombing runs
* Healing via low pass (ground based TX of 'heal' bullets in wide area)
* Follow me - How many hits can you get in 60 seconds?

== Hardware ==

There are four parts to think about here:
1) The TX light chamber
2) The RX receiver
3) The controller and any additional backchannel equipment
4) The player feedback mechanisms - buzzers, sound, lights

Some laser tag systems come completely self contained and some are very modular. The MILES tag system is very modular. You get to plug in different RX domes to ensure you can be hit from all angles. Those are usally just 3 IR RXs, one in each direction just soldered to a PCB.

The light chamber controls beam width for LED systems and fancy ones are adjustable. This determines beam focus and the amplifier cirut & focus determine range.

-- For Planes --

I could see flight controllers or OSDs taking over this long term but likely the easiest path forward is something like arduino which uses a single channel from the RX to determine when to fire. The rest of the game could exist on the laser tag hardware and use visual or other indicators of progress. A backchannel would be nice but I don't know what is possible with the existing data backchannels on telemetry systems. Otherwise you could use alternate backchannels via anything supported by arduino like zigbee or WIFI. Seems silly given the amount of TX/RX gear you are carrying otherwise but without integratino there it might still be the best option.

In game feedback could be as simple as two 'level' LEDs for Ammo/Life. The Phoenix guns do exactly this. Put those in front of the FPV system and you have a HUD :) For LOS systems, plane mounted LED strips make the most sense to just indicate 'hit'.

Honestly, don't touch the flight controls. That sounds like a bad idea. This hobby is hard enough :)

The light chamber is a good canidate for 3d printing. I couldn't get a good look at the system in the flite test video but it looks like they managed to make it pretty small. I would aim for short ranges and wide beam for good dogfights.

Existing laser tag equipment is heavy because you sometimes fall on it. 150lb person running full speed into a concrete wall with the equipment first means you need to be reasonably sturdy. Nothing requires it to be so though.

Receiver domes are usually carefully placed. The self-contained systems put them on the gun itself with the reasoning that if you can shoot, you should be able to get shot. While the intuition might be to place them on all sides of the player, it isn't needed! This is usually good enough.


== Resources ==

All my posts about it:
https://executedata.blogspot.com/search/label/lazertag

Open Source code & arduino wiring diagram for building your own game host:
https://github.com/afaucher/LazerTagHost

Fork created by Riley McArdle with a very nice hosting station:
http://www.lazerswarm.com/
https://github.com/astrospark/LazerTagHost

A friend created this for laser tag games. It has no lasers! You can incorporate objectives into the game without making the system more complicated.
https://github.com/Raptor007/PiBomb

Excellent post!!
 

FPVAirCombat

Well-known member
Excellent post on laser tag combat! A complementary gun sight would add great realism to the air combat experience when calibrated to aim at where the laser beam strikes. A simple drawn reticle in front of the FPV camera appears blurry because camera normally is focused at infinity. Therefor a fully functional reflector sight with reticle focused at inifity would be ideal for this application. It also has the benefit of staying aligned with the nose of aircraft regardless of where the camera is pointing (moving with head tracking).

Tim Noack built 1:7.5 scale reflector gunsight for 1400-1700mm wingspan Warbirds and it works perfectly.


 

FPVAirCombat

Well-known member
I had the previlidge of working with Tim to develop this (record setting- smallest reflector) gunsight. And this is how it looks in a scale Spitfire cockpit in mock dogfight!


I can really use the laser tag system to complete the ultimate FPV dogfight system!
 
Last edited:

Boberticus

Active member
Duck, amazing, what a endeavor, even to just collect all of this in one place takes know-hows, but to reverse engineer the protocol itself... You've forced me to do some learning, and I doubt this will be the last time i talk about building a laser tag rc plane...

I have to admit, I am a bit lost as I am a hobbyist logic wizard, and some of your terms are just a bit above my head, Ive read some of the blogs you've posted, and the git-hub on the game host... it just so happens i have literally all of that sitting around in my arduino toolbox of parts and odds and ends, so I'm gonna build a Lazer Tag Host, but i want to be sure of what I'm building here. I imagine when i code and tune it i should be able to parse out what each bit of code does, I'm typically OK with that, but before jumping in it seems a bit daunting and like i said my coding and electronics is self taught hobbyist grade at best so i guess I'm asking questions first...

so the host is a game setter and scorekeeper, so you are thinking the "dogfight" would be sign into a skirmish at the host, fly a batteries worth of shooting at each other, then bringing back the airplanes to this host so that it can collect all the data and spit back out a winner or a scoreboard? this would leave a way huger variety in types of planes that could join, without having to be too centralized or adhere to any set build, with just a emitter, a receiver, a brain, and a trigger needed to join, but could be left open enough to have things like PWM filtering,led explosions, or servo wildness on the Arduino if wanted.

granted, a flying around followed by a spit-out from a computer is not as satisfying as shooting someone out of the sky, but that could be done on the blaster/plane still, if your into that. I want to have the thrill of putting weeks into a build and having someone on my tail, but i can understand how someone would not want to deal with that whatsoever... perhaps classes or "pink slip" skirmishes with willing combatants is the answer.

Do lazer tag systems still have issues with sunlight? the packet communications protocols you talked about pretty much eliminates that dont they?

Have you seen this? https://www.instructables.com/id/Duino-Tagger/ this is a modified toy, but the parts of that toy gun they keep is minimal and simple to recreate. the maker claims to be attempting to replicate the MILES protocol, how hard would it be to get something like this to talk to your system, or to fork it to be able to talk to this? Could I just change it to use the Phoenix protocol? other than Existing code for the Phoenix protocol in a game host, is there a reason to keep it? if i am going to end up modifying one or the other, which do you think would be the easier one to get working in the other protocol, most likely the blaster, right? it already has a section for lights and sound outputs, it may be simple to modify for a output for a OSD, and PWM filtering.

So a logical Series of steps would be:
build the host
build two tabletop blasters with a RC trigger
get them to talk to/shoot each other and the host station
put them in planes
dogfight
Talley the score and distribute bragging rights

This Honestly doesn't seem too terribly hard to pull off...
 

Boberticus

Active member
i actually signed up for discord last night because of that link, is there a space where they are talking about this? ive never really been on it before, but it seems like a bunch of chatroom feeds, and there really wasn't one on this.
 

Fluburtur

Cardboard Boy
We havent really made any progress on that for a while, I have been talking with some of the Inav devs about that and perhaps making a compatible board you plug into a flight controller to do it and it would be feasible but we have nothing solid yet.
 

Boberticus

Active member
So, Ive been reading for a bit, and today I made a few purchases, Im giving this a try...

https://www.ibm.com/developerworks/views/opensource/libraryview.jsp?search_by=Arduino+laser

this is a old but pretty through beginner level tutorial on building a lazer tag system. it doesn't seem as sophisticated as what Duck is talking about, i like the idea of a scoring system afterwards, but it isnt necessary to get this running, just a good idea to get large battles organized, or for bragging rights. i do think that it needs to identify itself, the led and sound outputs are simple and are gonna be easy to change/add a PWM or serial sbus output, it lists some weird functions, i dont want the limited number of shots or the self destruct, and it'll need to implement a more widely accepted communication protocol, but between this, the Duino-tagger code, and Duck's much more incorporated and fleshed out game host controller, i think like 95 percent of the code exists already and just needs to be organized. It'll have to be modified a bit, but the bare bones components are out there, along with solid theory and a decent start from scratch tutorial.

I think i've seen a sbus-out signal done on arduino, I haven't read too much into inav but its a beta-flight fork, I'm somewhat familiar with that from multirotors, surely there is a way to limit a channel based on a serial input, keeping any weird or new programming on the uno instead.

ive got a couple Unos and just bought 5 bucks worth of super bight IR LEDs and 38Khts Receivers, so now im gonna be going through that build, once i get them working on the bench,
  • ill start to modify it to get the code to also output a serial communication Inav can understand, and also to use the phoenix or miles protocol for communications,
  • then ill build a couple aircraft that can handle a bit of weight and get them flying nicely and get a proof of concept
  • then get a base or a host working, (optional i think but necessary for mass appeal/adoption)
  • then get the tutorial edited and collected together to be more streamlined to air combat so that anybody can build one if they want to.
Ive never been one for closed proprietary systems, its a bit of a scarcity mindset. Once its working, it could be made into a shield pretty easily, and then could be a thing that could be bought in a plug and play kit, or built from scratch. the tutorial i linked to is a pretty good starting point to get into arduino, and a modified version built around a flight fighting system would be a very compelling reason to get into robotics, and RC, this could potentially be a awesome FT STEM topic if we get the basics all set up to be open source, and work on education and tutorials rather than profits.
 

Duck

Active member
So, Ive been reading for a bit, and today I made a few purchases, Im giving this a try...

https://www.ibm.com/developerworks/views/opensource/libraryview.jsp?search_by=Arduino+laser

this is a old but pretty through beginner level tutorial on building a lazer tag system. it doesn't seem as sophisticated as what Duck is talking about, i like the idea of a scoring system afterwards, but it isnt necessary to get this running, just a good idea to get large battles organized, or for bragging rights. i do think that it needs to identify itself, the led and sound outputs are simple and are gonna be easy to change/add a PWM or serial sbus output, it lists some weird functions, i dont want the limited number of shots or the self destruct, and it'll need to implement a more widely accepted communication protocol, but between this, the Duino-tagger code, and Duck's much more incorporated and fleshed out game host controller, i think like 95 percent of the code exists already and just needs to be organized. It'll have to be modified a bit, but the bare bones components are out there, along with solid theory and a decent start from scratch tutorial.

I think i've seen a sbus-out signal done on arduino, I haven't read too much into inav but its a beta-flight fork, I'm somewhat familiar with that from multirotors, surely there is a way to limit a channel based on a serial input, keeping any weird or new programming on the uno instead.

ive got a couple Unos and just bought 5 bucks worth of super bight IR LEDs and 38Khts Receivers, so now im gonna be going through that build, once i get them working on the bench,
  • ill start to modify it to get the code to also output a serial communication Inav can understand, and also to use the phoenix or miles protocol for communications,
  • then ill build a couple aircraft that can handle a bit of weight and get them flying nicely and get a proof of concept
  • then get a base or a host working, (optional i think but necessary for mass appeal/adoption)
  • then get the tutorial edited and collected together to be more streamlined to air combat so that anybody can build one if they want to.
Ive never been one for closed proprietary systems, its a bit of a scarcity mindset. Once its working, it could be made into a shield pretty easily, and then could be a thing that could be bought in a plug and play kit, or built from scratch. the tutorial i linked to is a pretty good starting point to get into arduino, and a modified version built around a flight fighting system would be a very compelling reason to get into robotics, and RC, this could potentially be a awesome FT STEM topic if we get the basics all set up to be open source, and work on education and tutorials rather than profits.

You asked about Miles Tag and the link you pointed at is another custom protocol. They all work. Miles Tag and the Phoenix both use different wavelengths so you need to swap your actual transmitter/receivers if you want to use the 'right' wavelength which would only really matter if you need to interoperate. I picked the Phoenix protocol because I had the guns, my friends had the guns and they were 25$ a piece. Miles Tag guns run 200$+. They can do alot more! If you wanted to play some serious laser tag, go Miles Tag. But it increases the complexity and the chance you will burn yourself out before you get to the fun part of your hobby.

You are right that building the hosting station isn't necessary. I was actually extending an existing system with really good guns. The hosting station was the issue so the software I built was designed to replace only that. The guns can play without it but you only know your own health at the end of the match. The hosting station was meant to give a little more. Start simple! Just being able to shoot and register a hit is a huge step. In terms of steps I would take it as:
  1. Build a basic amplified TX/RX with arduino board and verify it can send and receive from some known source.
  2. Build enough in the system to record hits with LED flashes and stay on after a couple of hits
  3. Build tube with LED & lens to extend the range & add an amplifier to the LED TX to further extend the range
  4. Mount to a plane and fly, trying to set off the others
  5. Extend the system to give better feedback when dogfighting- Addressible LED strip? Just more LEDs? The whole plane lighting up would be really cool.
  6. Extend the system to register hits reliably (once you can confirm hits visually while flying)
  7. Then think about other mechanics / cross operation and all sorts of complexity.
Note that my system really only does the first step. Everything else is in software that runs on the PC. I am a software engineer by trade so I played to my strengths.

For sunlight rejection, the data packet is checksumed to avoid false positives. The sun is never going to look like a valid shot. But in bright sun you might not register hits in a few cases. Usually this is fine but you can always swap in different hardware later in the process to improve this. Remember the LEDs, the receivers, the amplifiers and any filters over the receivers are all swap-able later with no software changes.

In terms of open source, I did open source all my work for the laser tag host. But I don't own any of the patents on the underlying technology. I don't sell any products related to this and beyond github I don't distribute it. You could invent your own protocol that does an identical thing if you really want. My blog has the links to their patent that lists what you need to avoid. I wouldn't start there. I honestly would not have been able to do the project if I didn't have a fully working system in front of me.
 

Duck

Active member
It seem that I’m not the only one working on this project!
In the last two years I made pretty decent progress and some people around Europe are helping me testing the system...
https://www.facebook.com/FPV-Combat-847007632315438/

Can you give an explanation of how your system works? I can't quite figure it out from the facebook posts. Where is the OSD integration coming from? What components are included in your system? How did you manage the laser tag TX/RX? I don't see it in the pictures.
 

ioteo

Member
Can you give an explanation of how your system works? I can't quite figure it out from the facebook posts. Where is the OSD integration coming from? What components are included in your system? How did you manage the laser tag TX/RX? I don't see it in the pictures.

Sure I'm happy to give some more info!
The system is basically a PCB with an OSD and microcontroller... the uC make of course all the job, it drive an high power IR led (leally narrow) with a coded IR signal (38kHz). At the same board is/are connected the ir sensors that allow to be hit.
Ammo and life information are displayed i the integrated OSD (in addition with the voltage of the battery and the sight).
The system is configurable with almost any IR remote controller, there is a procedure that allow youto assign your custom buttons to the needed functions.
Different interaction mde are selectable, you can just use it as standalone combat platform or choose to let it interact with the control of your model...
Always on the board there are some output (powerup to 5A capable) to drive leds or any other electrical load! (the blinking leds on the back of the F22 are driven by the pcb after a simulated "received shot".

I just added a function in the last days that is even cooler!
 

Boberticus

Active member
this is freaking nifty, and i have a bunch of questons...

I certainly mean no offence by these, just curiosity(in something i might be enticed to buy to be honest), i saw that you were selling/getting reimbursed for a beta test kit, is there plans on releasing firmware for people to build to fit to? Or are you hoping that the intergrating any remote/tagger will allow you to work with most anything without having to be open source? it seems like you are working torwards a product to be sold, any ideas on what the product will look like or entail(hardware and software, free software with branded flashed hardware for sale, hobbyist open source, fully open source, ect.) Is the beta test kit still open to get?

how are these extra functions/settings accessed, are you connecting to some sort of physical configurator or Game host like what Duck was describing, or are you just flashing a new script every-time you make changes? maybe OSD tuning for that? is there some sort of scoring system for when its not interacting with the flight controller? Any suggestions for search terms for learning about OSD programming? is it literally just a off the shelf external OSD?
 

ioteo

Member
this is freaking nifty, and i have a bunch of questons...

I certainly mean no offence by these, just curiosity(in something i might be enticed to buy to be honest), i saw that you were selling/getting reimbursed for a beta test kit, is there plans on releasing firmware for people to build to fit to? Or are you hoping that the intergrating any remote/tagger will allow you to work with most anything without having to be open source? it seems like you are working torwards a product to be sold, any ideas on what the product will look like or entail(hardware and software, free software with branded flashed hardware for sale, hobbyist open source, fully open source, ect.) Is the beta test kit still open to get?

how are these extra functions/settings accessed, are you connecting to some sort of physical configurator or Game host like what Duck was describing, or are you just flashing a new script every-time you make changes? maybe OSD tuning for that? is there some sort of scoring system for when its not interacting with the flight controller? Any suggestions for search terms for learning about OSD programming? is it literally just a off the shelf external OSD?

Hello, I'm really happy to see people interested in the project! I'll try to answer to all the question as best as I can...
All the project was born only for fun and personal research, I always have been interested in RC models, combat and FPV so I decided to make some tests my myself... The results where surprisingly good so I continued developing the system. After months of research and coding I was able to drive also an analog OSD. My original goal was to start a kickstarter campaign (or similar) to start the very first production and hoping that someone noticed the project giving it a chance. I was also considering to release it as opensource if everything would end well.
Now I have some contacts so I can't really say anything for sure or make promises that I can't guarantee.
Before starting any kind of business (for me or others) I needed to test the system as much as possible in real life conditions but unfortunately my friends are not fully interested in it and I couldn't find any close tester so I decided to try the "beta tester program".
I couldn't afford investment for all the hardware to justify a minimum production so I had to ask people to trust me and contribute with at least the cost of the materials. I purchased of course some extra components so if some one is interested I can still assemble some kits.
About the integration with other remote lasertag system I didn't care a lot since it is mainly developed to be used with itself but it shouldn't be hard to implement almost any other existing protocol (more technical analysis and talks are needed for this).
The board is making all the "magic" included OSD and control of external outputs on dedicated pins this mean that you can install the same board on models or fixed object (
or
).
All the configurations are made using the configured remote controller (programmable as many time as needed with navigation buttons and other functions), you simply press the "MENU" button and you can access all the settings ( life, ammo, trigger mode, interaction mode, team and # member...) you don't need to flash any custom edited firmware to change any of the main features!
 

Attachments

  • FPV Combat V1.3 connection diagram.pdf
    594.3 KB · Views: 0
  • FPV Combat - F22 DVR frame.jpg
    FPV Combat - F22 DVR frame.jpg
    867.8 KB · Views: 0
  • IMG_E8974.JPG
    IMG_E8974.JPG
    1.9 MB · Views: 0
  • FPV Combat - MENU.jpg
    FPV Combat - MENU.jpg
    399.3 KB · Views: 0

Boberticus

Active member
Hello, I'm really happy to see people interested in the project! I'll try to answer to all the question as best as I can...
All the project was born only for fun and personal research, I always have been interested in RC models, combat and FPV so I decided to make some tests my myself... The results where surprisingly good so I continued developing the system. After months of research and coding I was able to drive also an analog OSD. My original goal was to start a kickstarter campaign (or similar) to start the very first production and hoping that someone noticed the project giving it a chance. I was also considering to release it as opensource if everything would end well.
Now I have some contacts so I can't really say anything for sure or make promises that I can't guarantee.
Before starting any kind of business (for me or others) I needed to test the system as much as possible in real life conditions but unfortunately my friends are not fully interested in it and I couldn't find any close tester so I decided to try the "beta tester program".
I couldn't afford investment for all the hardware to justify a minimum production so I had to ask people to trust me and contribute with at least the cost of the materials. I purchased of course some extra components so if some one is interested I can still assemble some kits.
About the integration with other remote lasertag system I didn't care a lot since it is mainly developed to be used with itself but it shouldn't be hard to implement almost any other existing protocol (more technical analysis and talks are needed for this).
The board is making all the "magic" included OSD and control of external outputs on dedicated pins this mean that you can install the same board on models or fixed object (
or
).
All the configurations are made using the configured remote controller (programmable as many time as needed with navigation buttons and other functions), you simply press the "MENU" button and you can access all the settings ( life, ammo, trigger mode, interaction mode, team and # member...) you don't need to flash any custom edited firmware to change any of the main features!


oh my gosh this is really flipping cool, thanks for these photos, I've now started combing through your Facebook page.

Duh, its a frigging IR receiver, a IR remote to re-program it is kinda simply brilliant. You also just took a pwm signial in for the shot, and a pwm in and out for the motor, you got around the need to talk to the receiver and flight controller al la SBUS/PPM with a clever little pwm filter and a extra channel on the receiver, this could be done, on a fixed wing, without a freaking flight controller!!!!!! THAT. IS. AMAZING!!!!! That code has to be insanely clean too, just a IR tagger with lights, sound, a extra Pwm filter and a function to affect when your "dead" and the analog OSD programming. Im even more certain this can be done even simpler than i first thought...

Do you have Weapon types, like slow firing heavy cannons or fast shooting light machine guns? a health bar? is that the lives, or is a life different? it is like max health is max motor rpm, and each hit ticks off of the total, limiting what you can put out? if you had recevers on sepreate inputs, you could have armored sections and vulnerable sections... ive gotta stop asking questions and just start building. :p

Its encouraging that youve gotten this all onto one board, now your just getting all sorts of cool things to talk to the system, it looks like they all works really well... What about a triggered packing peanut bucket dump? just a unbalanced bucket with a servo trigger and filled with whatever shot out of the nuke tower? id totally bring family in to shoot at each other somewhere i could also fly and shoot someone.

hopefully you can either make some money, get a decent resume boost, or at the very least get a bit of credit from this once this gets some steam behind it, you've done some very cool stuff here, and from the looks of it, you've got more in store for us :)

got the IR receivers in the mail today, gonna start trying to get the taggers built from that IBM tutorial, and see where i can get from there!
 

ioteo

Member
Well even if it sounds easy and simple, trust me if I tell that conflict with the different functions, timers, interrupt and so on are not so easy to put all together!
I'm happy to ear such enthusiasm from you!
I wanted that the system was standalone so it can be mounted on basically anything! from big scale reproductions to micro models that's why I stopped developing the integration of receivers protocols...
The possibility to influence some controls of the plane took me a big part because it has to be as safe as possible!
I didn't integrated yet the weapons selection type and damage level but it could be done in the future.
For the damage now there are basically 3 working mode (plus the unconnected one):
- ESC: the motor/servo switch off (or set to a specific value) for a programmable time every time a hit is detected and stays at the value if lifes are finished;
- AUX: the output goes to different levels (programmable) one for normal state, second when hit is detected and the third when life are finished;
- SHAKE: the output is disturbed by a programmable level and frequency, so you still have control of the surface but it simulate a turbulence or physical damage of the aircraft...

PS: yesterday I received some smoke pills... we'll see if I can get some cool footage in the next weeks!
 

Duck

Active member
ioteo
What chip are you using for the processor and video overlay? Also, is the code open source so we can take a look? This is pretty cool!
 

ioteo

Member
The uC is atmega 328 and ic is the widely used 7456.
I’d like to share the code but right now I can’t do it yet...
 

Duck

Active member
I looked up the Max7456 chip. Very interesting! It looks like it is 'deprecated' and hard to buy by itself but it is the chip on most stand alone OSD boards including https://www.readymaderc.com/products/details/rmrc-micro-minim-osd . There is VERY little documentation that I could find in my first pass about this. But it looks like the board is actually just a programmable OSD. Betaflight/etc just have the right protocols for controlling it. It appears like Arduino might as well. I saw one oblique reference that said you need some extra non-standard libraries for it.

I can see why @ioteo chose it.

I did a little looking and I can't find what is supposed to replace the Max7456 chip now that they don't make it. But it looks like lots of stand alone OSD boards are still in stock so maybe it isn't a problem. I might buy one and see if I can get something working. Not sure if I need another project for the winter though :)

@ioteo , if I may ask, what is preventing you from sharing the code? Is there a license restriction on something you included?
 

ioteo

Member
I’m just in contact with some companies and I don’t know where it will go...
I just need some time to figure out which direction will take the whole project!