I wanted to share this with the Ardupilot community. It’s been a fun project to work on!
We used a 3D printed drone with a Pixhawk running a modified version of Ardupilot, combined with ROS (Robot Operating System) and MavROS running in Docker containers.
For the gun we modified a big buck hunter gun and hooked it up to a Raspberry Pi placed IR LEDs in it. We then focused it through a lens and transmit a IR pulse (similar to how your TV remote works) to determine when a drone gets hit! If the drone gets hit it does a flip!
EDIT: And as I think about it a little, I can envision a means by which you could accomplish the IR detection and flip solely within ArduPilot via Lua scripting. But swarming still requires a little more fancy footwork on the GCS side.
Guided mode is likely the right choice for the entire flight regime.
We can hijack the same battery message using ArduPilot Lua and provide guided mode aerobatic commands onboard.
Even better, it’d be good to craft a simple microcontroller based IR sensing device that would connect to the autopilot’s I2C, serial, or CAN bus. A Seeduino XIAO + some simple IR detection circuitry and code would be an excellent, lightweight, fully featured candidate.
With a microcontroller onboard, we can implement IR detection algorithms in Lua (or on the microcontroler itself) to differentiate players (not unlike television remotes). The onboard script could keep the drone’s individual scores from each player and downlink them as gcs:send_named_float() values. The GCS would then total the scores from each drone to determine a win condition, and the GCS could send a game reset command to wipe the scores and start again.
Using ROS provides a powerful way to craft trajectories that would challenge the players while ensuring mid-air avoidance. I have less experience with ROS than with the onboard Lua side of things, but I know its potential for sure.
In fact, it would be interesting to have a near continuous IR code sent from each gun such that a drone would “know” that it’s being targeted and perhaps initiate some sort of avoidance maneuver that isn’t impossible to defeat but would provide further challenge…
I’ve been extremely impressed with the XIAO and have gravitated toward it for any non-networked microcontroller project of late. It’s easy to integrate into the Arduino IDE (ptooey!) or PlatformIO (much better!).
You should probably include LIDAR altitude sensing in your drones if you haven’t already. An absolute, accurate altitude reference will likely prove invaluable in swarm operations. You could determine threshold altitudes for flip/avoidance maneuvers for self-preservation.
However, if you have a serial port to spare (after LIDAR integration), it’s still the easiest one to code.
As another thought - the guns could have GPS tracking as well, and ROS could ensure that the drones always “face” the average of the headings toward each player, such that the sensor arrays are always oriented correctly (unless an avoidance maneuver is initiated). Alternatively, the GCS could emit its location, and the players would stand near it, to the same effect.
ROS seems overkill for now, a simple pymavlink watch for BATTERY2 message would be enough ! (unless you got something else running)
You could typically, put a fence on the drone, get it from your commander script, and then use GUIDED to move randomly the drone into the fence area ! That is pretty easy to do.
I don’t know if it is enabled, but I think we got a DO_FLIP message, that could be simpler than do a mode switch
I appreciate all your help!! I ordered some stuff to play around with. Will report back!
A few other thoughts:
Right now the GCS is the raspberry pi which mounted to the gun. So definitely might need to rethink that if using multiple guns.
I have a lot of experience and micro-services I have built with ROS which is why I chose it. It gave me a easy way to put Text to Speech (voice) into the game. I figured it would help with multiple drone control as well.
I’ll have to do a video with a more technical walk through video in the future. Again I really appreciate both of your suggestions on how we can take this to the next level! Keep them coming!
I think you’re simultaneously going in right and wrong directions.
For your present hardware config, it seems you’re on the right track for time syncing. If you’re messing with SCHED_LOOP_RATE, be sure to reboot between value changes. Seems a bit odd that the default loop rate isn’t fast enough on Copter firmware, and an RTT of nearly 1/2 a second may be indicative of another problem.
However, the GCS should likely be independent from the gun. I think the gun should just be a simple IR emitter, and the GCS should be contained on a dedicated computer on a reliable power supply.
The baud rate wouldn’t account for that amount of time lost.
I wonder if it’s something on the Pi side of things that’s slowing things down. To be perfectly honest, I’ve only barely scratched the surface of ROS, and I’ve never actually used the time sync feature.