Not a member yet? Why not Sign up today
Create an account  

  • 13 Vote(s) - 4.15 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
Hover AI: differential yaw/pitch, attack runs, pitch for altitude

#31
You can set the medic vehicles to go to different heights, the active altitude is the alt it tries to stay above the target.
Reply

#32
(2016-02-07, 11:24 PM)SynthTwo Wrote: You can set the medic vehicles to go to different heights, the active altitude is the alt it tries to stay above the target.

Yeah that's what I was thinking, ill give it a try
Reply

#33
Could you help my friend and I sort out the code for our gunship? The main problem we're having is that when we spawn our aircraft far away while facing away from its enemy, its movement becomes weird. Sometimes it'll permanently be at a 45 degree angle from its target and other times it'll get stuck going in diagonal loops. We tried changing a bunch of settings but can't seem to get it to consistently get to its target. When it does get within range, though, it works just about perfectly.


Attached Files
.blueprint   FSU_PelicanV7.blueprint (Size: 107.61 KB / Downloads: 84)
Reply

#34
(2016-02-07, 06:13 PM)SynthTwo Wrote: With that being said, could you give a brief explanation on your logic behind how you go from measuring the moment/impulse from every piece of propulsion to actually generating a numerical value to output to the thruster?

I do not measure the propulsion output, the checks in SetPropulsionImpulses are just there to determine what'll happen if I send a positive input to the component.
For example: if an upwards facing jet is in front of the center of mass to the right then it'll pitch down and roll right on +.

The needed output strengths come from some generic PIDs(1 for pitch, yaw, roll, altitude, distance to target and side speed each).
The SetStatus call calculates them and passes the result to SetPropulsionImpulses, that one determines the final outputs.
It uses a simple sum, doesn't even assign different weight to components based on how far from the CoM we are along each axis.

For example, if the craft is at a critical height of 10 with a desired 100 and heavily pitching up(target being level),
then upwards facing front thrusters will probably go at max strength while upwards facing ones at the back will
have a lower thrust or if the pitch is heavy enough they could even have a negative output(heliblades).
Actual values vary wildly depending on config.

This approach works very well for the purpose so I'm not planning any upgrades to it.


(2016-02-07, 08:50 PM)OMGaGOPHER Wrote: I've been testing this out for a few hours now and it seems very cool. One problem I've come across is when you have multiple medic vehicles repairing something they ironically end up crashing into each other. I'm not sure if there's a very obvious way of configuring this that I'm missing but if someone could help me out that would be great.

As SynthTwo already said changing the activeAltitude will help, if you go that route you could consider reducing verticalEvasiveAltitudeChange.
Setting optimalDistance(how far will they circle, measured on the ground) will also prevent collisions.


(2016-02-09, 08:24 AM)thermodonut Wrote: Could you help my friend and I sort out the code for our gunship? The main problem we're having is that when we spawn our aircraft far away while facing away from its enemy, its movement becomes weird. Sometimes it'll permanently be at a 45 degree angle from its target and other times it'll get stuck going in diagonal loops. We tried changing a bunch of settings but can't seem to get it to consistently get to its target. When it does get within range, though, it works just about perfectly.

Sounds like a yaw/pitch PID config problem, I'll check it out in the evening.
Reply

#35
(2016-02-09, 09:15 AM)draba Wrote: Sounds like a yaw/pitch PID config problem, I'll check it out in the evening.
I guess I'll keep fiddling with those in the meantime.
Reply

#36
Re: medics crashing into each other: One option would be to use the Friendlies interface to find nearby friendlies, filter them based on some configurable blueprint name list, and then do flocking in one dimension to distribute them across heights.
Reply

#37
(2016-02-09, 02:32 PM)thermodonut Wrote:
(2016-02-09, 09:15 AM)draba Wrote: Sounds like a yaw/pitch PID config problem, I'll check it out in the evening.
I guess I'll keep fiddling with those in the meantime.

Tried out your craft, found some issues:
- 60° max roll is pretty extreme for the amount of roll control it has. It consistently goes over it, then can't correct well because the roll thrusters are not strong enough. I'd recommend adding some downwards facing jets or dediblades at the end of the wings, if it would mess with the aesthetics too much reduce max roll and up roll pid a bit/add integral.
- pitch control is weak, the craft is consistently well over the configured max pitch(>50° instead of 20). I've actually seen it doing loops and corkscrews, I had no idea that could be achieved with this script so pretty Lamb impressive if intentional Smile Also, altitude pid is way stronger than the pure PD pitch so it'll often muscle it out. I'd recommend adding a downwards facing jet at the end of the tail and upping pitch pid(maybe adding a medium integral).
- it has no way of reducing speed/going backwards so will always end up on top of the target. In an earlier version I've used pitch/altitude propulsion combo to control forward speed but it didn't add much value and interfered with the other functions too often. I recommend adding any kind of backwards propulsion(a small dediblade spinner with 4 blades, 1-2 small jets facing backwards).

In general you've used too low pitch/roll/yaw values(relative to the strength of the propulsion components) without an integral.
That means the craft can't handle extreme cases too well and has a hard time recovering from errors.

I've slapped on 2-2 jets at the ends of the wings, 2 jets on the nose and 1 on the tail + reconfigured it a bit so it's much more stable.
It looks ridiculously cool so I felt quite bad for mucking it up, the additions are just there to provide an example Smile

Couldn't test it too much but destroyed some riverhomes/sea vipers without a hitch,
let me know if it still does something funny after your modifications.


(2016-02-09, 10:21 PM)Vebyast Wrote: Re: medics crashing into each other: One option would be to use the Friendlies interface to find nearby friendlies, filter them based on some configurable blueprint name list, and then do flocking in one dimension to distribute them across heights.

Dunno about that, I was already hesitant to add terrain avoidance. Of course I'd like the script to have useful features but not melting processors is a big plus Smile
I think a simple config change solves those problems most of the time but if it's a common request it could be implemented without too many problems.


Attached Files
.blueprint   FSU_PelicanV7_change.blueprint (Size: 108.27 KB / Downloads: 103)
Reply

#38
(2016-02-10, 02:14 AM)draba Wrote:
(2016-02-09, 02:32 PM)thermodonut Wrote:
(2016-02-09, 09:15 AM)draba Wrote: Sounds like a yaw/pitch PID config problem, I'll check it out in the evening.
I guess I'll keep fiddling with those in the meantime.

Tried out your craft, found some issues:
- 60° max roll is pretty extreme for the amount of roll control it has. It consistently goes over it, then can't correct well because the roll thrusters are not strong enough. I'd recommend adding some downwards facing jets or dediblades at the end of the wings, if it would mess with the aesthetics too much reduce max roll and up roll pid a bit/add integral.
- pitch control is weak, the craft is consistently well over the configured max pitch(>50° instead of 20). I've actually seen it doing loops and corkscrews, I had no idea that could be achieved with this script so pretty Lamb impressive if intentional Smile Also, altitude pid is way stronger than the pure PD pitch so it'll often muscle it out. I'd recommend adding a downwards facing jet at the end of the tail and upping pitch pid(maybe adding a medium integral).
- it has no way of reducing speed/going backwards so will always end up on top of the target. In an earlier version I've used pitch/altitude propulsion combo to control forward speed but it didn't add much value and interfered with the other functions too often. I recommend adding any kind of backwards propulsion(a small dediblade spinner with 4 blades, 1-2 small jets facing backwards).

In general you've used too low pitch/roll/yaw values(relative to the strength of the propulsion components) without an integral.
That means the craft can't handle extreme cases too well and has a hard time recovering from errors.

I've slapped on 2-2 jets at the ends of the wings, 2 jets on the nose and 1 on the tail + reconfigured it a bit so it's much more stable.
It looks ridiculously cool so I felt quite bad for mucking it up, the additions are just there to provide an example Smile

Couldn't test it too much but destroyed some riverhomes/sea vipers without a hitch,
let me know if it still does something funny after your modifications.

Heya, I worked with thermodonut on this craft. After reading your post and messing with the new blueprint a bit. Main changes we made were slapping on a bunch of yaw thrusters and pitch thursters on the tail. Now it works flawlessly, took out the plunderer and the ransack no problem. Thanks man for your code and fixes. Big Grin
Reply

#39
First and foremost you're a genius. I know there are other hover craft scripts but I have yet to lose a ship with yours. So cheers for that Big Grin

Second would it be possible to modify the script so that I could take control of my ship, but only with forwards/reverse/yaw controls?
Reply

#40
(2016-02-11, 06:46 PM)Maeltep Wrote: First and foremost you're a genius. I know there are other hover craft scripts but I have yet to lose a ship with yours. So cheers for that Big Grin

Second would it be possible to modify the script so that I could take control of my ship, but only with forwards/reverse/yaw controls?

Thanks!
Yep, it actually was in my backlog along with docking compatibility.
Shouldn't take too much time.

Edit:
After checking the API it won't have a nice automatic solution, I've remembered seeing something that detects manual control but it was just I:TellAiThatWeAreTakingControl().
Would need some manual setup with a hydrofoil tied to the complex controller yaw/speed inputs, on change only use vertical thrusters for ~0.1 seconds and restore the rest to 1 drive.
Will get around to it on the weekend.
Reply



Forum Jump:


Users browsing this thread:
4 Guest(s)