In my fps shooter there is a drone enemy that flies around on a path and can detect you. Thats all done but once it detects you is the issue. I want it to fly around up down left and right, aim at you and shoot at you.
do you think it would even be possible to use the same mechanism as a real drone would. Would a rigid body force possibly allow the drone to push its self-up just enough to stay in the exactly perfect position in the air. Tilt itself to launch it left or right. Slightly alter the amount of force it has to move it up and down. If so, lets discuss it!
You would likely use a PID controller.
2 Likes
Yes, you’d use a lot of PID controllers, but the loop rate is pretty poor compared to a real drone which does their updates thousands of times per second.
This is a classic case of DON’T MODEL REALITY, MODEL SOMETHING THAT EMULATES REALITY. You want the verisimilitude of realism. You want to spend the least possible computation time doing something that gives the impression of realism. Draw textures instead of grains of sand or fibers of woodgrain. Draw something that will react to the player’s movements and bob and weave in a visually pleasing way, but don’t try to calculate all the possible things a drone would calculate. It won’t do as good a job and will waste CPU trying.
1 Like
As someone who has implemented a quadcopter in Unity long before connecting it to Simulink, it is definitely possible. I am not a fan of the PID controller approach due to how many you have to tune and how inconsistent it could be at times. You could try a LQR controller which multiplies the error by a matrix but from my experience, it only works really well for step times of 0.01 and lower. One I found that works consistently at higher step times is a sliding mode controller (SMC), which should be simple to code.
You need like 4 SMCs for altitude, roll, pitch, and yaw, and you could simply connect a PID controller which is used to control the horizontal position by determining the amount of roll and pitch needed to maintain that position.
I tried them very recently for controlling a quadcopter in a warehouse and the SMCs are very robust. You will almost never see the drone go unstable. I’d go for it, even if people say Unity wasn’t meant for that. First, break the problem down into pieces by starting with altitude control.
1 Like
The racing drone and acrobatics specific firmware like betaflight might run at thousands of times per second. But the ArduPilot/PX4 based stuff aimed more at experimentation/research, autonomous flight, and various less dynamic use cases like aerial photography and inspection often run at low hundreds hz , sometimes even down to 100 hz or 50hz. It won’t be the most pleasant experience to manually fly at 50hz but staying in air without crashing is possible. Main control loop running at 100hz doesn’t mean that all the systems are running that slow, stuff like IMU processing and pose estimation might still run at higher rate to deal with vibrations and reduce integration errors. But that shouldn’t be a problem for simple simulation where you can cheat and directly read clean values from physics engine without any noise or vibrations.
Although if you are not making a drone flight simulator, but FPS game where this is just one of enemies I wouldn’t waste my time implementing full drone flight control. You should be able to get decently looking results by doing it in reverse by having your AI just control floating baloon and animating pitch and tilt based on acceleration. Something like this:
- always add vertical up force to cancel out gravity.
- calculate tilt and pitch proportionally to linear acceleration vector in horizontal(x, z) plane and (maybe also add speed with much smaller coefficient to simulate sideway force required to overcome drag at fast speeds) clamp the final angle <45 degrees . Read the acceleration by filtering values from physics engines.
- change the sound intensity based k1speed+k2velocity.y. (flying fast requires more power to overcome air resistance, flying up requires more power, flying down requires less power)
The benefit of doing it this way is that you don’t have to get all the parameters and formulas exactly right just to prevent it from falling. It doesn’t matter if you assume that some stuff happens linear if even if it doesn’t in real world. If you tried to do proper simulation even if you had all the forumulas right, you would still have a to tweak a bunch of constants to keep it floating not even talking about keeping stable. Reverse approach also reduces problems with low physics update rate.
As for actual drone AI control just add the force in required movement direction. And start breaking early so that you reach ~0 speed on target point. Even if you overshoot a bit and sometimes bounce into walls it’s probably fine.
Previously I said tilting proportionally to acceleration. But you can’t tilt instantly, that looks bad. So you have two options. Simplest is to add some filtering either on acceleration used to calculate tilt or the output tilt itself. That way you can still control movement by instantly adding sideway force. Downside is that tilt will slightly lag behind actual acceleration unlike real world physics where acceleration is caused by tilting. More advanced approach would be to filter control force, that way cause and effect is in right order, but that is quickly getting closer to implementing more of the real drone control stack.
My point wasn’t that it’s impossible, as any Turing Complete programmable calculator can do the math. It’s that it’s a complete waste of time unless you (1) consider it the most important task of your game, and (2) accept the mediocre results you’ll get from cutting corners to meet the processing limitations of a C# script running at a low cycle rate on a game-physics-focused platform.
Good to know, I like what Halley said about not making it real life but based off of it. Because that just over complicates things for really no reason. Thank you for the help!