Stop velocity pivot at specific angle or make PID work with robotic

[viridis]

I have a problem: I built a 360° tracking turret with a microcontroller (PID based), radar and velocity pivot. Now I want to make the turret reloadable so I need it to go to a specific location (looking straight and up) to make the belt connectors feed ammo.

Question: How do i either get the velocity pivots to go to that position or get the PIDs to work with robotic pivots so I can at least have 180° FoV?

Thanks for the help in advance I love this community <3

[Sampak]

I was thinking about the same problem with using velocity pivots, compact ones at least, which don't give you a reading of their current angle. I was thinking in that case (this may be overthinking the obvious) using a compass sensor on the base platform and also on the gun, oriented for yaw, of course. Also a tilt sensor for the vertical angle.

Looking up should be easy as you can PID your vel. pivot until it reaches whatever turn value you need for the "look up."

Yaw wise (returning to center/forward I suppose), I was thinking of comparing the base and gun's compass sensor and adding or subtracting rotation using a PID until the gun's compass sensor matches the base sensor.

I feel like I'm missing an obvious method but that's one theory.

[viridis]

Originally posted by Sampak:

I was thinking about the same problem with using velocity pivots, compact ones at least, which don't give you a reading of their current angle. I was thinking in that case (this may be overthinking the obvious) using a compass sensor on the base platform and also on the gun, oriented for yaw, of course. Also a tilt sensor for the vertical angle.

Looking up should be easy as you can PID your vel. pivot until it reaches whatever turn value you need for the "look up."

Yaw wise (returning to center/forward I suppose), I was thinking of comparing the base and gun's compass sensor and adding or subtracting rotation using a PID until the gun's compass sensor matches the base sensor.

I feel like I'm missing an obvious method but that's one theory.

That's exactly what I needed thank you!

[Sampak]

You're welcome! Let me know if it works (even if kinda') so I know if I shouldn't waste my time tonight on it haha.

[ElfBossHogg]

One complication I found with two compasses is that if you convert your turn data degrees you run in to issues when you try to orient near 0'/360'. A PID doesn't know 360 is the same as zero. Therefore if you want to go from 350 to 0 it's a large decreasing number, not a small increase, which will most like throw your pivot past 0 and you get the repeating problem.

[viridis]

Originally posted by ElfBossHogg:

One complication I found with two compasses is that if you convert your turn data degrees you run in to issues when you try to orient near 0'/360'. A PID doesn't know 360 is the same as zero. Therefore if you want to go from 350 to 0 it's a large decreasing number, not a small increase, which will most like throw your pivot past 0 and you get the repeating problem.

I didn't think about that but yea thats a problem...

Originally posted by Betty's Honor guard:

I fixed that by (cracking my brain here, it's late); IF x<180 AND y>x+180 THEN y=y-360 for passing 0 counterclockwise and IF x>180 AND y<x-180 THEN y=y+360

I use this for heading hold for example. If applied to both compasses this should give a good reading for the turret position. Don't know what it would do if turned upside-down though..

I guess I have to applie that in Lua? or can a function work with this too? Good idea though!

Regarding your first message: I will try it with tilt sensors first because I think it's the easier variant and I dont want to rebuild my turrets to be hard-lockable to be honest. Worst case a laser beacon and sensor would be an option but I would like to avoid that due to compliaction aswell. I'll report if I did my testing!

[ElfBossHogg]

Originally posted by Betty's Honor guard:

Originally posted by ElfBossHogg:

One complication I found with two compasses is that if you convert your turn data degrees you run in to issues when you try to orient near 0'/360'. A PID doesn't know 360 is the same as zero. Therefore if you want to go from 350 to 0 it's a large decreasing number, not a small increase, which will most like throw your pivot past 0 and you get the repeating problem.

I fixed that by (cracking my brain here, it's late); IF x<180 AND y>x+180 THEN y=y-360 for passing 0 counterclockwise and IF x>180 AND y<x-180 THEN y=y+360

I use this for heading hold for example. If applied to both compasses this should give a good reading for the turret position. Don't know what it would do if turned upside-down though..

The only thing is that using a PID properly for this two compass setup requires that the setpoint and variable need to be in a proper and ruled relationship always. A PID doesn't know what your numbers mean. It just cares about deriving a response value to get you to the setpoint. If you apply your logic you are changing the definition of what is the setpoint so the PID can't work properly to derive the response that is required. Additionally If the direction keeps crossing back and forth over the 0 line it's going to reek havoc on what the setpoint actually is.

[viridis]

Originally posted by Betty's Honor guard:

Originally posted by ElfBossHogg:

The only thing is that using a PID properly for this two compass setup requires that the setpoint and variable need to be in a proper and ruled relationship always. A PID doesn't know what your numbers mean. It just cares about deriving a response value to get you to the setpoint. If you apply your logic you are changing the definition of what is the setpoint so the PID can't work properly to derive the response that is required. Additionally If the direction keeps crossing back and forth over the 0 line it's going to reek havoc on what the setpoint actually is.

Well, I didn't mean I theoretically solved this, I applied this already and it hasn't given me any bad results as of yet. Your conclusion about the crossing back and forth is false as the PID simply calculates the difference between the current variable input and the setpoint.

This is what happens;
-As you said; the PID doesn't understand that if x==0 then x=360, thus it always goes the longest way around when x<180 AND y>x+180 or x>180 AND y<x-180. These are the precise moments that the PID has the wrong conclusion.
-I then simply replace its conclusion for a number that exactly matches what it would calculate if it would have been on one continuing scale towards the shorter route to the setpoint. Which is y-360 or y+360 respectively.
-That is why, when it crosses, the PID jumps from, for example, -4 to exactly -4 in the same tick.

As an example, consider the case where x=40 and y=350.
-PID says HURRR; +310. This is wrong, of course.
-If it would have been on one scale counter-clockwise, the PID would have gotten; -40-360+350=-50. My formula gives us y-360=350-360 =-10. It then feeds this to the PID which simply calculates from the current variable, which is still 40; y-x=-10-40=-50.
-When the PID now comes to 0 degrees its calculated output will be based on the exact same number as when it is on 360 degrees, which, in effect, seamlessly loops the PID over that point.

Knowing that, I would expect to not run into any issues using two compasses, as one compass will accurately display the rotation of the vessel/vehicle in relation to North and the other will accurately display the same for the turret.

I am missing one thing here: What is Y?
also: Yea I just redesigned the turret to have the large pivots as vertical mounts. Would do the same for gorizontal but I dont have the space doe to my reload system.

[viridis]

Or better: How would you set it up in the microcontroller with the two compass sensors as inputs and the PID setpoint and prossess variable as outputs?

[viridis]

Originally posted by Betty's Honor guard:

Sorry, I thought I had that in there; x is the variable, y is the setpoint for the PID.
As to your other question; Have one compass (A) on the base vehicle, the other (B) on the turret. Then when you want the turret to return to center you feed the turret PID the value of compass (A) as a setpoint. The PID can then use the output of compass (B) as a variable. That should align the turret compass, and thus the turret itself, to the compass on the main vehicle. Granted; the math and logic I am very certain about, as I have tested and used it many times, the actual building of a new concept is always subject to stormworks randomness. I'm curious what your end solution will look like. I like this game exactly for these kind of challenges.

I know how to do the basic setup. I am adding the turrets to a very well working vtol quad jet with all kinds of features so I know my way arround basic logic and microcontroller setups. My question was regarding your formula for the 0/360 problem. I have the turrets now set up fully working but thats the last thing thats missing from the microcontrollers. (took me a while to figure out what numbers to invert to get my upside down turret tracking correctly but I got it now)

[Thulram]

Jumping in, what would need to be done to incorporate dynamic bearing information? i.e., I input desired turret azimuth via a keypad for it to rotate to (because maybe I've lost my radar so no active control).

Also, how do I instruct turrets to stop rotating at a certain angle then if I have the desired angle say at 10 degrees but the turret on the back naturally can't aim for it (think old world war naval ships).

[Ra-Ra-Rasputin]

Now that you've done the easy part, you can try and do this.[i.imgur.com]

It only took several hours of headache across 2 days. It's just trigonometry, the lasers are entirely a visual representation, though i need one laser to calculate distance so i can calculate everything else.

[LoSboccacc]

remember to put *two* tilt sensor, one on the moveable arm, and one on the vehicle, because the real angle is between these two, and not between the arm and the horizon

[Sampak]

Originally posted by LoSboccacc:

remember to put *two* tilt sensor, one on the moveable arm, and one on the vehicle, because the real angle is between these two, and not between the arm and the horizon

Why two? As far as I have seen, a tilt sensor gives you the absolute tilt angle regardless of what any sub-grids/blocks are tilting toward. As long as the tilt sensor is oriented for vertical angles, and attached directly somewhere on the "gun" portion where all the movements happen, the angle reported will be relative to the horizon. You don't need a second one on the main turret body to find "the difference" between them for calculating the "real angle." :)

[viridis]

Originally posted by Betty's Honor guard:

Ok, so here goes;

Firstly, I was right about the different application thing, which meant ElfBossHogg was right about the 0-360 thing in this specific application. Apologies @ElfBossHogg!

This really broke my brain, because I never had it before in my applications. Now, I trust in science and the math HAS to be correct, I checked it multiple times. So I started thinking; "what is the difference in the application?". I noticed that my personal ways I applied this were slower; heading hold for boats, station keeping for helicopters etc. Then I realized; every logic block takes one tick! I never had trouble with it before so this is the first time I ran into it.

I then tried to delay the variable input into the PID so they would arrive at the same time, this made the problem far less obvious, but still noticeable. Then I realized; the function on Tick in lua is exactly that; on tick. it calculates and outputs each tick. So then I used lua and, low and behold; as the variable and setpoint are in perfect synch the application works perfectly.

I also added the connectors, just so you can see what I mean. I really like that setup, because a lot of things happen in stormworks and the connectors make sure that what you want to happen, actually does. ie; wind doesn't blow the turret out of position. The PID doesn't get the turret to the exact position because vehicle is moving/pivot bugs out etc. You can choose to use it or not of course.

Below are the two versions so you can see the effect of the tick synch. you can mess around with the mc. It is a bit messy as I tried to keep all the systems separate so you can more easily see what's what. PID settings can be changed from the editor, if you want the connectors to connect sooner or later adjust the epsilon of the equals block at the top to include more or less degrees in the margin.

Finally; thanks to both of you for causing me to gain new knowledge!

Workshop links;


https://steamcommunity.com/sharedfiles/filedetails/?id=2624684583

https://steamcommunity.com/sharedfiles/filedetails/?id=2624685133

Nice thank you! I'll defenitely take a look at that and try to learn something from it aswell xD

Originally posted by Ra-Ra-Rasputin:

Now that you've done the easy part, you can try and do this.[i.imgur.com]

It only took several hours of headache across 2 days. It's just trigonometry, the lasers are entirely a visual representation, though i need one laser to calculate distance so i can calculate everything else.

I think I'm to stupid for that but very impressive!

[viridis]

I noticed that turrets on a jet craft are not as efficient as I hoped (at least on the techincal level I can build them. Once I figure out stuff like target lead that might change) so now I'll focus on targeting assistance for forward facing guns and maybe player controlled turrets... (does someone want to shoot some bad guys in multiplayer?)