I've seen people have this brilliant idea: You put a compass on an aiming servo to detect where it's facing and use the compass' output to move a stronger regular servo that controls what you want to move.
6:08 - this is working like a PID controller, it needs to be balanced by situation. Unless you can controll dynamically the strength or speed of the motors you'll always be able to make it be unstable. There's a process that kinda tests and ajusts the values on the control automatically I just don't really remember how it works and would have to look it up, but it should be possible. Ideally the devs would program this process to happen automatically or let the variable available for us to ajust. 10:30 - yee, the internal values for the code that defines how much it's trying to correct, how does it tries to dampen movement, etc... those are the ones that need to be available for ajustment.
I feel like the simplest solution for usability would be to expose some kind of damping factor to the player, which tunes some of control loop variables. You want quick and snappy responses for guns, even if that means it overshoots a tiny bit when it gets to its destination, but on something like this, that same behaviour results in a wobbly mess
I think the biggest problem isn't that the aiming servo PID function isn't tuned properly, it's that it's not dynamic like you were saying. That thing is very finely tuned to handle one thing and one thing only; the prefab weapons. From the tiny cannon to the tank cannon and everything in between, those aiming servos have been tweaked to handle those to a meticulous level as well as the bare minimum of anything else required to make those weapons function, like frame blocks to place a tank cannon on to actually face in a direction the aiming servo effects instead of just rotating in place. I don't think the devs ever intended for entire tank turrets or mech torsos to be slapped onto those, and that's where the problem is. This is a creative game. Making something with a scoped view of "This will only be used for 1 scenario, only that scenario, and nothing else" is a bad development plan and eventually someone will find a scenario outside of the one intended that is very valid, but the thing doesn't work for it. I think the devs were just short sighted on this particular part in thinking that this could/would only be used to slap guns on and that'd be the end of it. So hopefully they can get a dynamic PID system on an aiming servo, but I'd also like this one to stick around. Slap some weights on an aiming servo and pack on the miniguns and you'll have spray'n and pray'n down pat.
6:32 At the edges, there's likely a constraint in the game engine with infinite force which simply prevents the servo from going past that point, as though there was a physical blockage in the mechanism itself Using an infinite force constraint to stop movement is typically fine, but using that same infinite force constraint to _cause_ movement can cause some serious bugs and unexpected behaviour. Basically, an immovable wall is significantly more stable than an unstoppable force. Imagine if your gun touched your vehicle by just a few degrees, and immediately blew up and put a dent into your creation, despite it moving extremely slowly. That's why it doesn't work. You have to put a limit on that movement force To me, this issue is not one of lack of strength, but rather an intentional compromise. The servos were tuned to turn quickly and responsively so that the moment you turn your camera, the servos follow suit and line up with your facing direction as soon as their speed value allows, even if they overshoot a little bit while doing so. For a lightweight gun, this works perfectly, but for a heavy creation, that kind of tuning results in a feedback loop. Realistically there should be a damping setting so you can tone down the internal control loop for a heavier creation to make it slow down as it approaches the set point, rather than having it speed up until the moment it reaches its target
Hey Scrap, your editor was right on! The measurement you wanted to describe was Moment of Inertia (I) Where I=mr², for a point mass (like a single 50kg block)
I had an idea while i was watching and immediately hopped on the game. I found that if you double up the aiming servos, set their individual speeds to 0.15 (which would add to a 0.3 speed total), there should be a period after turning them where the second servo needs time to catch up, which give you a few seconds of stability before needing to aim in a different direction to stabilise them again. This doesnt really fix the issue, its more of a bandaid but it worked for me, hopefully it works for u
You can tell his “dev” videos. I like them. He tackles a problem he encounters and breaks them down in a way to have the devs fix the problem. Plus, you can tell these give hime the advantage in the multiplayer videos
I found that out that by using the camera block, the oscillation is massively reduced if you center the camera block to the middle of the aiming servo with pistons on the horizontal line. For the vertical line, it seems to work best if the camera block is 3 to 4 blocks higher than the aiming servo. Imagine a void, now imagine a single point in that void, this point will be the point your camera spins around, if you want to reduce the wobble try to place the aiming servo 3 to 4 blocks in any direction away from that point.
I think at some point the wobble caused by one of the servos exagerated the wobble on the other servo, especially when it makes the whole creation shake, which makes your camera shake and thus a servo that would have otherwise been fine would have been wobbling to follow your aim.
I have built a lot of tanks and when the update came out I immediately tested replacing the servos on my tanks with the aiming servo. At first it is not stable but when I repair and not move my camera while the tank is spawning and drive forward for like 5 seconds it became very stable. And that's my solution to make the aiming servo stable.
@@onlinetL I also had that issue but I realized I have gyros in my turret because that's how you make realistic FCS before the update. So the gyro is turning your hull so if you have a gyro in your turret just delete it. If it still rotates the hull I don't know
@bocahexplorer9706 yeah, it looks like this feature was made possible by the gyroscopes I used to stabilize the aiming servo for my MBT. Another feature of this method is that when falling from a height, your tank starts spinning like a helicopter. It's very interesting how the aiming servo works with gyroscopes, it turns out to be something like a quantum runner but for air
You should do a tank battle with the new aiming servo at 0.1 speed, then you would have to strategize and make smart choices instead of rushing your enemies. It would essentially be almost a realistic tank battle.
It always overshoots its target direction because it will always attempt to reach that target by moving at its designated max speed. The devs could try to fix this by applying a curve to the speed of the servo that makes it get slower the closer it gets to its target rotation. This will make it less likely for it to overshoot and create a feedback loop. There is probably a way to do this using the new logic too More weight or the weight being moved further out means more torque is required for the servos to move the weight, which causes them to accelerate to it's target max speed slower, when it overshoots its target rotation it then has to try to accelerate in the other direction and overcome the momentum it imparted to the weight before
Another comment suggested using a compass on an aiming servo to control it, (which is effectively an amplifier) and yeah I think the combination of that and the new logic would be enough to design at least a basic controller. I'm thinking about finally getting Trailmakers just for this xD
Its because its giving full power into rotating once its past its "camera point threshold"... it needs a PID controller (proportional integral derivative controller). What a PID does is when it approaches the target point, it lessens the throttle/power so it doesnt over shoot, or at the very least will be much less of an overshoot and will stable out... unlike without it, constantly overshooting due to constant full power... We humans have this system somewhat installed into us, when we fly a drone and want it to hover at a height, we manually reduce throttle as it getsbto where we want, then adjust as and when needed... PID is basically that but part of the automated process
2:30 Interestingly, that was the *exact* same problem the new F-35 fighterjets had up until fairly late in their development. The Fly-by-wire system overcorrected on inputs from the pilot, and then overcorrected on its overcorrection and so on and son on, creating a feedback loop that hept builing until it crashed. ... I really hope they fixed that properly, considering how we've made them my nation's primary fighter.
My theory is that the aiming servos are in an on off state, so minor corrections have the sane speed as major ones. But heavy objects have momentum the servo has to recorrect then recorrect again. And a feedback loop begins. The way to solve this would be for servos to have an option for variable strength within a range.
The fact that aiming servos become more stable as you decrease the speed value makes me think that the passive damping effect is directly tied to that speed value. I'm sure it makes total sense from a math/coding standpoint, like, the faster the servo moves, the more damping it needs to apply to remain stable while active, but it ends up causing a crazy feedback loop in situations where the servo is forced to deviate from either the base "off" position or the current facing position If you enable "off by default" and "hold position" with a forward-facing, vertically rotated servo on a really low speed value (ex: 0.02), it will actually try to orient itself as straight up and down as possible (despite its default facing direction) before losing strength and entering a feedback loop. So, it seems like adding extra weight simply increases the damping required to keep a servo stable, thus exaggerating the feedback loop
There's one generic takeaway from this video, DEVs need to implement either a "Deadband" and/or "Gain" options in the configurator. For more info, search the web for PID, a common application is a household thermostat, if the temperature is above the setpoint the system attempts to correct the temperature until it is within range, when it is far from the setpoint the ouput is increased to respond quickly. As the temperature gets closer to the setpoint the output is reduced to compensate and stop an overshoot.
I think i got it: the more torque, the more it wobles. It accouts for what you observed: the further you are from the pivot point the worse, and the more mass the worse, and toeque equals mass times acelerarion. The servo is bad becouse its stabilasation is bad, its code is bad, you needed to mess whith it like a PID controler for it to be better. It starts to resonate in a feedback loopbecause of the bad settings, woobling. Hope this helps!
If we use the Moment of Inertia formula given, and substitute in, Base formula: MoI = (Intergral)r^2dm If we substitute in for the cannon, MoI= 4.9*7 Assuming all attach points are 1m away in simplicity (you can adjust in your own calculations) this gives us an MoI of 2450kg/m^2. This gives us some interesting math. For one, this is exponential, the increase from say 9-10m is 93.1kg/m^2 but 28-29 is 280.3kg/m^2. Using the formula, f(x)=4.9*x^2, then hit the gear and tap, the table and add a few entries you can see for yourself and do your own math. Hope this is helpful!
It's very clear to tell that just from the vertical heavyweight test alone that the aiming servos main issue is with angular momentum and angular velocity. When you have all your weight centered near the point of rotation it has no trouble moving, aiming and stopping your creation's arm or whatever. But when you have all of your weight far away, just like with the point of a sword that tip is going to have a hard time coming to a complete stop, because its weight and momentum are just too much to get aimed properly and steadily. The aiming servos also clearly don't have an automatic means of compensating for having a heavy load to move at the end of a long lever.
It looks like it's taking the distance and multiplying the weight, but the distance is the limiting factor, where the weight doesn't count towards the equation more then 1 time at each direction
It seems like today (1 day after the original release of this video) Trailmakers received an update with the following patch notes: - Added a new "Verticallity Checks" toggle to the Aiming Servo. This will allow for more complex uses of the Aiming Servo block. - Fixed many cases of the Aiming Servo being jittery in certain structures. I think there is more testing and retesting to be done xD
Day 5 of asking for a battle where you each make a vehicle of your choice unknown to the other players. This might lead to a tank, a submarine, and a helicopter in a battle, so you would have to prepare a way to combat any threat. In case of an OP build, you can let the losers have some more power cores and blocks to try and even the playing field.
what you forgot to test is stacked aiming servos in the same direction! like you'd do helicopters by stacking servos or such, to make the blades rotate faster, you should've tested it with aiming servos too, if slower speeds make it more stable, could you stack several slow-speed ones on top of each other (probably with a thin buffer block) and achieve decent speed with more weight capacity?
The very first attempts looked like a cat got something sticky to the paws, trying to get rid of it 😆 "Get it off, get it off, get it... ok I'm fine now" A way to overcome those effects would might be, if the servo gets a bit stronger but with a kind of dampening effect. So it starts at its set speed, but the further it gets to the point of aim, it slows down to counteract the force put into it. Like a hydraulic piston for example. The more you compress it, the more resistance it builds up. Or those buffers for drawers. You can push them for closing but the last few inches get slowed down by a mechanical attachment to close them softly and quiet. A similar thing applies to tank turrets. Their mass needs to be accelerated by strong electric motors and will slow down before they hit the point of aim, depending on the angle of rotation it needs to make. Locked on a target and/or while moving it just needs to rotate a few degrees steadily, so the electric motors doesn't need to be fast, but applying constant torque for stable rotation before the operator might lock the current position. Just listen to real life applications. They speed up and slow down. I guess this should be working in trailmakers as well if the devs tweak those servos.
You are firmly in the world of discrete math in Trailmakers, due to the blocky nature of builds. So rather than I = integral of r squared dm, use I = sum of r squared m. (Stupid YT won't let me use the summation character). Which is the summation of the square of the center point displacement of each block, multiplied by its mass. No messy antiderivatives needed.
25:52 this happen because the 2x4 block hitbox is colliding with the aiming servo hitbox, i tested it. the shaking would be reduce by using any kind of wedge or curved block with the curving side is facing the aiming servo rounded part (bad english)
Yes? He quit YT a long time ago to pursue his own career in apparently music, gaming just wasn’t it for him. Thus my side of the story which of i’ve heard from numerous of other people, i urge you not to take this as the immediate truth.
He went to pursue something else, but he has deleted his discord and maybe his twitter(from another comment) So I don't think he's coming back, just in memory now. I joined his discord a while ago but I can't find it and his discord invite link doesn't work anymore so all is pointing to being deleted.
You’re all wrong lol. He still has a discord, he chats every once in a while. RUclips wasn’t going to work out as a career so he moved on to another gig. He hasn’t fully left, he does plan to return at some point.
@@austin.5947 which is what i’ve said minus the return part, though i must admit the music part could be incorrect but i wasn’t fully wrong, it was a guess from other commenters more than anything. Thank you anyways sir.
Lower speed making the aiming servo more stable than if it were at a higher speed is actually good if you are trying to make tanks, or realistic ones at that. Even before the PvP update when making tank turrets I would put a rotating servo at 0.1 speed to get as much realism and accuracy as I could. Because the aiming servo works better at low speeds, I believe that it would be a bit easier to make tank turrets
To counter the torque, you need something spinning in the opposite direction. What if you put a servo on the other side of an aiming servo that spins in the opposite direction rather than counterweighting on the same servo which spins in the same rotational direction (Clockwise/counter-clockwise). To neutralise the spin, the servo would be at speed 1.00, but to actually counter the spin, it'd need to be at 2.00 speed when the aiming servo is set to 1.00 speed.
In engineering, proportional control systems tend to have this issue where they essentially over correct and appear under damped. One way you could hack this could be to add a gyro to it without control and tune the strength to damp the motion for the mass you have applied
I think there needs to be an adjustable dead zone for the aiming servo to adjust for different weights to stop the feedback loop similar to the max angle.
Yzuei has a video about a mouse controlled plane that uses an aiming servo that points into 2 distance sensors that outputs a positive and negative signal into gyros. Instead of the gyros, use a normal servo. It works for a large tank I made. Just make sure the horizontal sensor is on the turret, and the vertical sensor is on the barrel.
Hey i've done done my own testing and I found that if you put A gyro on whatever the aiming servo is holding (im not sure if alignment matters) it can dampen the wobble though the stregnth and the amount of them depends on the thing your trying to prevent from wobleing.
The term you are looking for, Scrap, in describing weight vs distance is footpound. Though kg doesnt relate to feet or pounds without maths, I think Newtons might be the fogbreathing equivilant.
Scrapman ! I tried something and got VERY interesting results, 150 kg of weight centered on the servo, no problem. 100kg of weight centered on the servo + 3 meter grid block arms on each side, BIG wiggle. So it truly has nothing to do with momentum, the 150kg one has way more momentum, those little dinky arms are purely adding length, there weight is ridiculously low, and yet, even with 50kg LESS, those arms make it completely unstable. Edit : the devs just announced a coming soon hotfix that should fix the issue entirely, I got Jamie (a dev) to test my blueprint described above in the new hotfix and it is indeed nice and stable.
@@JasonBlack-d4l I know, I work in engineering. You just didn't understood my comment. I have 2 aiming servos, on one of them is 150kg stacked directly on top of the servo, as expected, that doesn't create any wobble. On the other one, I have 100kg also stacked directly on top, in addition to that, I have two very lightweight arms that create very little inertia, sufficiently so that the extra 50kg on the other servo largely offsets it. And yet, despite having less inertia than the first servo, it wobbles a lot, whereas the first one is completely fine.
I thinj the reason is bc it's meant to attach a weapon, not a entire build for it, but as someone said you can likely use it with a compass the other logic block to read the angle and send it to a regular cervo as logic blocks now are not binary but they can output a whole value like angles
It would be cool if they visualized parts of the aiming servo like the range limit so you could see how far it will be able to turn while in build mode.
I do think it would be cool to get a finite number on it, like at what weight and distance makes it unstable just to see a graph of the weight compared to distance haha
Video idea: use aiming servos to steer, so you have to look where you're going. Then race with the vehicles, or put an stationary forwards facing gun on top of it and do a pvp battle
Video Idea: Planes, but the pitch surfaces are controlled with the aiming servo. Step further could be pitch and yaw, but I'm not sure how predictable that would be. 😅
Until the patch fixing aiming servos is released, the way to correct the wobble is by using two opposing aiming servos for each axis. They will cancel out the feedback loop. You can still only build out so far before wobble is an issue, but at least this way I was able to get a mouse aim tank turret to work with minimal to no wobble.
from a game dev perspective (myself) dampening would do wonders, the devs need to add a small amount of dampening to the aiming servos, would fix ALL wobbling
Think about it as if you were a ship in space. You have forward and reverse thrusters You max thrust all the way to your destination, you over shoot it, have to reverse, then overshoot again. If you max thrust up to 1 m/s till you get there, then you're gonna do much less overshooting The more weight you have the harder it will be for your thrusters to stop the momentum from pushing you past your destination. You can use stabilizer fins like shock absorbers to limit to help reduce the overshooting on the servos
Can you do capture the flag with an attacker and a defender. The attacker must have a magnet to grab the flag and the attacker has to be either a VTOL, helicopter or drone. The defender must stay on their aircraft carrier and defend their flag. They will have more weapons than the attacker.
I would suggest connecting servos to vehicle via "soft physics blocks" like suspention or pistons. In theory soft nature would absorb exagerrated servo strengh and overcompensation in movement making aiming and turning much more smoother with fluid action
Could you use angle sensors mounted to mouse aim servos to measure your angle of aim and then have regular servos "repeat" those angles. So maybe you could have larger turrets, with a mini "aiming turret" hidden within the build
Don't know if you get there yet. Stacking servos in general might help, but stacking them with limited angles might create a bunch of stable hard stop points along the way. Personally I think stacking them and seting them slow, so they are stable and fast based on additive movement
You could make a circuit per say, where youd have aming servos and sensors output to normal 360 servos, wich will have enough torque to handle more weight. Ether that or multiple aming servos connected to the same frame so their power multiplies. But those options are quite big to interpret into creations....
Video Idea: Mouse Controlled Racing Build and race vehicles, potentially directly against other players like Yuzi, that are controlled entirely with your mouse. Engines and thrusters are controlled by left and right click and steering is done through the aiming servos.
Camera position, for the times when the results were inconsistent. You can see the wobble in the whole world, because the camera is not just following your input, but also the object. That adds to the forces involved. When the camera is closer, and especially if you look directly down, the wobble lessens or stops. Of course that's not the whole thing, the weight obviously matters more.
Although I know the Dev's already announced they are going to release a hotfix for the aiming servos soon and increase the strength, but I just wanted to say your slight inconsistencies are due to the anchor blocks, they never let you land perfectly level or land consistently. So you had a slight angle affecting the movements, with 2 weights it made a very very minor difference, but as you saw, horizontal stability is drastically different from vertical. That's a thing I don't like about the anchor blocks haha.
I wonder if stacking two servos on top of each other and setting the speed of the top one at half the speed of the bottom. While also having a small range limit on the top would improve the stability. Since it would have a slight trailing, and ride the limit which was stable.
Oh wow, I joked about the aiming servo having no PID controller last vid, but the behaviour in testing confirms there is no PID going on. Tuning a PID to work with any mass is impossible, but I'd expect better from TM... These issues can be easily resolved by reducing the speed, but then it'd be less responsive. Alternatively you use a PID with a derivative term, but that requires case by case tuning depending on the mass and inertia on the servo. You can however get an extremely responsive arm that way. And the boring solution would be to physically fix the orientation of the arm and interpolate between positions, essentially creating infinite strength like how a piston clips through its own creation.
I kind of feel like I'm a fly on the wall of Scrapman going to the ophthalmologist (eye doctor) when he's doing the side by side testing. Doc: "Alright tell me which one looks better; number one...or number two....Again, number one....and number two." Scrapman: "They're very similar....NO, THE LEFT ONE IS WAY WORSE!!!!" Doc: "That's not how this works. Again, number one... and number two. Which one is better?" Scrapman: "They're practically the same." Doc: "........."
Also you can use this intentionally and I'm surprised it hasn't been used in one of your multiplayer battles yet. You rig up this system with a couple miniguns and you have covering fire clearly covered. Spray and Pray is the name of this wobble if you mount a gun on it. Accuracy by volume.
This game needs melee weapon block. Make them use power cores and make them VERY resistant to collision damage, but not shooting damage. Then have blades and spike that can be fixed to vehicles and helicopter servos. Can you put a regular gyro on the arm. It might make slow it, but it also might act like a shock absorber.
In Unity, when objects with a large mass difference are connected, everything becomes chaotic. I don't know what kind of physics engine Trailmakers uses, but there might be a similar issue.
hey scrapman just a suggestion for your mouse controlled arm to fix the uncontrollable movement if you haven't tried it already try lowering the strength on the servos maybe that would work.
its cuz when it's trying to track your mouse when it goes past the mouse it goes to correct itself but passes your mouse and corrects again causing the wiggle. So, I don't think it's intended
I think the lack of dampenimg make the cervo go in a oscillatory state. A fix can be to make the cervo slower to reduce the overshoot but yeah. We need a dampening option.
Adding more things is linked to adding more weight. More weight equal more momentum, so a bigger oscillation. That's why adding a counterweight isn't helping in this case.
dampening should 1, be an option and 2, we should get different options for it like the censors (exact, more than, less than, average, etc) also just a general weight buff would be very nice
The distance from rotation makes a lever effect that will amplify the weight. That's why just a small weight far from rotation point will affect more than a lot stacked.
Your buffer blocks add weight to the horizontal aiming cervo making it worse, if the vertical ones are identical, the buffer blocks shouldn't impact its performance. Except if theres sone stuff in the game engine thay I don't know.
You are firmly in the world of discrete math in Trailmakers, due to the blocky nature of builds. So rather than I = ∫r²Δm, use I = ∑r²m. Which is the summation of the square of the center point displacement of each block, multiplied by its mass. No messy antiderivatives needed.
It seems like it's just an issue with how it is designed to function; when the angle is not at your mouse, it puts 100% power to get there, taking the weights and inertia with it, causing overshoot, which then get 100% power to go back the other way, forever. If it were changed to percentage-based instead of boolean on/off power, if it were only off by a little then it would only give a little bit of power to move back, preventing the feedback loop, as it would slowly get closer and closer to its desired Target as it decreased the amount of power it reintroduced as it got closer.
I wonder if center of mass has something to do wih the instabilities? Because if your camera is centered on your center of mass, the aiming servo moving would move the center of mass and thus your camera and thus where you're aiming.
I've seen people have this brilliant idea: You put a compass on an aiming servo to detect where it's facing and use the compass' output to move a stronger regular servo that controls what you want to move.
was thinking the same blud, good to know we both watch him
I wish I knew *how* that is done
You need to have a second compass on the base and substract the value. Rotation sensors work too, but you need to set them at an angle.
@@V3RYM3GAFUNIt's really not that hard at all. Put a compass on the aiming servo and have it power the normal servo
@@alexling4347 That... that does not give a coherent input.
An hour after the video was posted devs confirmed they will make it less wobbly, thx scrap
They where already working on it for about 5 days. Or atleast that's how long we have been testing the new fix
Okay it’s also on a spike and we all know the unstable of that
@@andrewlarge655it does this, maybe even worse without being on the anchor block, i've tested it myself aswell
*_YES!_*
Props to the editor for the explainations! 8:48 might be the most consise explaination of the Moment of inertia formula!
6:08 - this is working like a PID controller, it needs to be balanced by situation. Unless you can controll dynamically the strength or speed of the motors you'll always be able to make it be unstable.
There's a process that kinda tests and ajusts the values on the control automatically I just don't really remember how it works and would have to look it up, but it should be possible. Ideally the devs would program this process to happen automatically or let the variable available for us to ajust.
10:30 - yee, the internal values for the code that defines how much it's trying to correct, how does it tries to dampen movement, etc... those are the ones that need to be available for ajustment.
100% Bad PID tune
I feel like the simplest solution for usability would be to expose some kind of damping factor to the player, which tunes some of control loop variables. You want quick and snappy responses for guns, even if that means it overshoots a tiny bit when it gets to its destination, but on something like this, that same behaviour results in a wobbly mess
I think the biggest problem isn't that the aiming servo PID function isn't tuned properly, it's that it's not dynamic like you were saying. That thing is very finely tuned to handle one thing and one thing only; the prefab weapons. From the tiny cannon to the tank cannon and everything in between, those aiming servos have been tweaked to handle those to a meticulous level as well as the bare minimum of anything else required to make those weapons function, like frame blocks to place a tank cannon on to actually face in a direction the aiming servo effects instead of just rotating in place. I don't think the devs ever intended for entire tank turrets or mech torsos to be slapped onto those, and that's where the problem is.
This is a creative game. Making something with a scoped view of "This will only be used for 1 scenario, only that scenario, and nothing else" is a bad development plan and eventually someone will find a scenario outside of the one intended that is very valid, but the thing doesn't work for it. I think the devs were just short sighted on this particular part in thinking that this could/would only be used to slap guns on and that'd be the end of it. So hopefully they can get a dynamic PID system on an aiming servo, but I'd also like this one to stick around. Slap some weights on an aiming servo and pack on the miniguns and you'll have spray'n and pray'n down pat.
@@H3xx1stis the problem mostly in the I? I am trying to learn about PID's
6:32
At the edges, there's likely a constraint in the game engine with infinite force which simply prevents the servo from going past that point, as though there was a physical blockage in the mechanism itself
Using an infinite force constraint to stop movement is typically fine, but using that same infinite force constraint to _cause_ movement can cause some serious bugs and unexpected behaviour. Basically, an immovable wall is significantly more stable than an unstoppable force. Imagine if your gun touched your vehicle by just a few degrees, and immediately blew up and put a dent into your creation, despite it moving extremely slowly. That's why it doesn't work. You have to put a limit on that movement force
To me, this issue is not one of lack of strength, but rather an intentional compromise. The servos were tuned to turn quickly and responsively so that the moment you turn your camera, the servos follow suit and line up with your facing direction as soon as their speed value allows, even if they overshoot a little bit while doing so. For a lightweight gun, this works perfectly, but for a heavy creation, that kind of tuning results in a feedback loop. Realistically there should be a damping setting so you can tone down the internal control loop for a heavier creation to make it slow down as it approaches the set point, rather than having it speed up until the moment it reaches its target
Hey Scrap, your editor was right on!
The measurement you wanted to describe was Moment of Inertia (I)
Where I=mr², for a point mass (like a single 50kg block)
pvp where the servos are backwards
to aim at your enemy, you must aim away from your enemy
YES
that would be an awful viewing experience
@Blackbirdtree1 Yeah, this idea requires someone who isn't fighting to be the designated cameraman.
You make it a 2v2 build. One is the spotter the other is the gunner. The spotter tells where to shoot and how to adjust the aiming.
I had an idea while i was watching and immediately hopped on the game.
I found that if you double up the aiming servos, set their individual speeds to 0.15 (which would add to a 0.3 speed total), there should be a period after turning them where the second servo needs time to catch up, which give you a few seconds of stability before needing to aim in a different direction to stabilise them again.
This doesnt really fix the issue, its more of a bandaid but it worked for me, hopefully it works for u
You can tell his “dev” videos. I like them. He tackles a problem he encounters and breaks them down in a way to have the devs fix the problem. Plus, you can tell these give hime the advantage in the multiplayer videos
I found that out that by using the camera block, the oscillation is massively reduced if you center the camera block to the middle of the aiming servo with pistons on the horizontal line.
For the vertical line, it seems to work best if the camera block is 3 to 4 blocks higher than the aiming servo.
Imagine a void, now imagine a single point in that void, this point will be the point your camera spins around, if you want to reduce the wobble try to place the aiming servo 3 to 4 blocks in any direction away from that point.
Forgot to say. I achieved a 24 block long, stable, tank nozzle with that trick and I didn't fine-tune the aiming servos, I used the standard settings.
I think at some point the wobble caused by one of the servos exagerated the wobble on the other servo, especially when it makes the whole creation shake, which makes your camera shake and thus a servo that would have otherwise been fine would have been wobbling to follow your aim.
The shaking camera is what I was thinking
I have built a lot of tanks and when the update came out I immediately tested replacing the servos on my tanks with the aiming servo. At first it is not stable but when I repair and not move my camera while the tank is spawning and drive forward for like 5 seconds it became very stable. And that's my solution to make the aiming servo stable.
wow, did you have the situation where when you turned the big turret strongly in one direction, the body itself could move in the opposite direction?
@@onlinetL I also had that issue but I realized I have gyros in my turret because that's how you make realistic FCS before the update. So the gyro is turning your hull so if you have a gyro in your turret just delete it. If it still rotates the hull I don't know
@bocahexplorer9706 yeah, it looks like this feature was made possible by the gyroscopes I used to stabilize the aiming servo for my MBT. Another feature of this method is that when falling from a height, your tank starts spinning like a helicopter. It's very interesting how the aiming servo works with gyroscopes, it turns out to be something like a quantum runner but for air
Literally 30 minutes after SM uploads an aim servo strength test, the devs announce a hotfix for them. lol
You should do a tank battle with the new aiming servo at 0.1 speed, then you would have to strategize and make smart choices instead of rushing your enemies. It would essentially be almost a realistic tank battle.
They definitely need some buffing.
thank you for using your voice to hopefully fix this issue, the wobble is genuinely so frustrating
It always overshoots its target direction because it will always attempt to reach that target by moving at its designated max speed. The devs could try to fix this by applying a curve to the speed of the servo that makes it get slower the closer it gets to its target rotation. This will make it less likely for it to overshoot and create a feedback loop. There is probably a way to do this using the new logic too
More weight or the weight being moved further out means more torque is required for the servos to move the weight, which causes them to accelerate to it's target max speed slower, when it overshoots its target rotation it then has to try to accelerate in the other direction and overcome the momentum it imparted to the weight before
Another comment suggested using a compass on an aiming servo to control it, (which is effectively an amplifier) and yeah I think the combination of that and the new logic would be enough to design at least a basic controller. I'm thinking about finally getting Trailmakers just for this xD
I love the editor's science and physics notes
Its because its giving full power into rotating once its past its "camera point threshold"... it needs a PID controller (proportional integral derivative controller).
What a PID does is when it approaches the target point, it lessens the throttle/power so it doesnt over shoot, or at the very least will be much less of an overshoot and will stable out... unlike without it, constantly overshooting due to constant full power...
We humans have this system somewhat installed into us, when we fly a drone and want it to hover at a height, we manually reduce throttle as it getsbto where we want, then adjust as and when needed... PID is basically that but part of the automated process
2:30
Interestingly, that was the *exact* same problem the new F-35 fighterjets had up until fairly late in their development.
The Fly-by-wire system overcorrected on inputs from the pilot, and then overcorrected on its overcorrection and so on and son on, creating a feedback loop that hept builing until it crashed.
... I really hope they fixed that properly, considering how we've made them my nation's primary fighter.
I love scrapmans testing videos. I have no idea why, but they're my favorite.
The strength setting maybe is causing the feedback loop because is over compensating the movement
My theory is that the aiming servos are in an on off state, so minor corrections have the sane speed as major ones. But heavy objects have momentum the servo has to recorrect then recorrect again. And a feedback loop begins. The way to solve this would be for servos to have an option for variable strength within a range.
Was refreshing my page at the time of your video’s release like a mad man
Same
Same
Cool video idea: A dogfight but you can only use your mouse to control the plane or 2 buttons and one joystick.
already been done by multiple people
The fact that aiming servos become more stable as you decrease the speed value makes me think that the passive damping effect is directly tied to that speed value. I'm sure it makes total sense from a math/coding standpoint, like, the faster the servo moves, the more damping it needs to apply to remain stable while active, but it ends up causing a crazy feedback loop in situations where the servo is forced to deviate from either the base "off" position or the current facing position
If you enable "off by default" and "hold position" with a forward-facing, vertically rotated servo on a really low speed value (ex: 0.02), it will actually try to orient itself as straight up and down as possible (despite its default facing direction) before losing strength and entering a feedback loop. So, it seems like adding extra weight simply increases the damping required to keep a servo stable, thus exaggerating the feedback loop
There's one generic takeaway from this video, DEVs need to implement either a "Deadband" and/or "Gain" options in the configurator. For more info, search the web for PID, a common application is a household thermostat, if the temperature is above the setpoint the system attempts to correct the temperature until it is within range, when it is far from the setpoint the ouput is increased to respond quickly. As the temperature gets closer to the setpoint the output is reduced to compensate and stop an overshoot.
I think i got it: the more torque, the more it wobles. It accouts for what you observed: the further you are from the pivot point the worse, and the more mass the worse, and toeque equals mass times acelerarion. The servo is bad becouse its stabilasation is bad, its code is bad, you needed to mess whith it like a PID controler for it to be better. It starts to resonate in a feedback loopbecause of the bad settings, woobling. Hope this helps!
Yuzei have been countering the wobble with dampening gyros
A video idea is making the most durable actual vehicle
If we use the Moment of Inertia formula given, and substitute in,
Base formula: MoI = (Intergral)r^2dm
If we substitute in for the cannon,
MoI= 4.9*7
Assuming all attach points are 1m away in simplicity (you can adjust in your own calculations)
this gives us an MoI of 2450kg/m^2.
This gives us some interesting math.
For one, this is exponential, the increase from say 9-10m is 93.1kg/m^2 but 28-29 is 280.3kg/m^2.
Using the formula, f(x)=4.9*x^2, then hit the gear and tap, the table and add a few entries you can see for yourself and do your own math. Hope this is helpful!
Gotta do a top 1% using aiming servo video
It's very clear to tell that just from the vertical heavyweight test alone that the aiming servos main issue is with angular momentum and angular velocity. When you have all your weight centered near the point of rotation it has no trouble moving, aiming and stopping your creation's arm or whatever. But when you have all of your weight far away, just like with the point of a sword that tip is going to have a hard time coming to a complete stop, because its weight and momentum are just too much to get aimed properly and steadily. The aiming servos also clearly don't have an automatic means of compensating for having a heavy load to move at the end of a long lever.
It looks like it's taking the distance and multiplying the weight, but the distance is the limiting factor, where the weight doesn't count towards the equation more then 1 time at each direction
It seems like today (1 day after the original release of this video) Trailmakers received an update with the following patch notes:
- Added a new "Verticallity Checks" toggle to the Aiming Servo. This will allow for more complex uses of the Aiming Servo block.
- Fixed many cases of the Aiming Servo being jittery in certain structures.
I think there is more testing and retesting to be done xD
Always an amazing day when scrapman posts a new vid
Yeah I agree, every day except Sundays are amazing days!!
Day 5 of asking for a battle where you each make a vehicle of your choice unknown to the other players.
This might lead to a tank, a submarine, and a helicopter in a battle, so you would have to prepare a way to combat any threat.
In case of an OP build, you can let the losers have some more power cores and blocks to try and even the playing field.
what you forgot to test is stacked aiming servos in the same direction!
like you'd do helicopters by stacking servos or such, to make the blades rotate faster, you should've tested it with aiming servos too, if slower speeds make it more stable, could you stack several slow-speed ones on top of each other (probably with a thin buffer block) and achieve decent speed with more weight capacity?
7:15-8:30 it's because the weight of the parts connected to the servo are ballance on both perpendicular cross-axis...
The very first attempts looked like a cat got something sticky to the paws, trying to get rid of it 😆 "Get it off, get it off, get it... ok I'm fine now"
A way to overcome those effects would might be, if the servo gets a bit stronger but with a kind of dampening effect. So it starts at its set speed, but the further it gets to the point of aim, it slows down to counteract the force put into it. Like a hydraulic piston for example. The more you compress it, the more resistance it builds up. Or those buffers for drawers. You can push them for closing but the last few inches get slowed down by a mechanical attachment to close them softly and quiet.
A similar thing applies to tank turrets. Their mass needs to be accelerated by strong electric motors and will slow down before they hit the point of aim, depending on the angle of rotation it needs to make. Locked on a target and/or while moving it just needs to rotate a few degrees steadily, so the electric motors doesn't need to be fast, but applying constant torque for stable rotation before the operator might lock the current position. Just listen to real life applications. They speed up and slow down. I guess this should be working in trailmakers as well if the devs tweak those servos.
You are firmly in the world of discrete math in Trailmakers, due to the blocky nature of builds. So rather than I = integral of r squared dm, use I = sum of r squared m. (Stupid YT won't let me use the summation character). Which is the summation of the square of the center point displacement of each block, multiplied by its mass. No messy antiderivatives needed.
25:52 this happen because the 2x4 block hitbox is colliding with the aiming servo hitbox, i tested it. the shaking would be reduce by using any kind of wedge or curved block with the curving side is facing the aiming servo rounded part (bad english)
Is moonbo alright
Yes? He quit YT a long time ago to pursue his own career in apparently music, gaming just wasn’t it for him.
Thus my side of the story which of i’ve heard from numerous of other people, i urge you not to take this as the immediate truth.
@ that’s fair
Not a word from him tho is kinda strange
He went to pursue something else, but he has deleted his discord and maybe his twitter(from another comment) So I don't think he's coming back, just in memory now.
I joined his discord a while ago but I can't find it and his discord invite link doesn't work anymore so all is pointing to being deleted.
You’re all wrong lol. He still has a discord, he chats every once in a while. RUclips wasn’t going to work out as a career so he moved on to another gig. He hasn’t fully left, he does plan to return at some point.
@@austin.5947 which is what i’ve said minus the return part, though i must admit the music part could be incorrect but i wasn’t fully wrong, it was a guess from other commenters more than anything. Thank you anyways sir.
They just posted about fixing the issue with the servos being wobbly in the discord server.
Scrapman's editor is becoming a mathematician XD
Lower speed making the aiming servo more stable than if it were at a higher speed is actually good if you are trying to make tanks, or realistic ones at that. Even before the PvP update when making tank turrets I would put a rotating servo at 0.1 speed to get as much realism and accuracy as I could. Because the aiming servo works better at low speeds, I believe that it would be a bit easier to make tank turrets
this just tells me that we need to make scrapechanic style creations in order for this to work now. Blocks with bearings/servos between
To counter the torque, you need something spinning in the opposite direction. What if you put a servo on the other side of an aiming servo that spins in the opposite direction rather than counterweighting on the same servo which spins in the same rotational direction (Clockwise/counter-clockwise). To neutralise the spin, the servo would be at speed 1.00, but to actually counter the spin, it'd need to be at 2.00 speed when the aiming servo is set to 1.00 speed.
In engineering, proportional control systems tend to have this issue where they essentially over correct and appear under damped. One way you could hack this could be to add a gyro to it without control and tune the strength to damp the motion for the mass you have applied
During the doubled turret testing, the shake from one turret was transferring to the other turret.
Could use the wiggle to potentially make it as a thrust source somehow.... Might be a fun video :)
Programing a dead zone would be the best way to improve stability when adding more weight and speed with the way the servos currently operate.
I think there needs to be an adjustable dead zone for the aiming servo to adjust for different weights to stop the feedback loop similar to the max angle.
Yzuei has a video about a mouse controlled plane that uses an aiming servo that points into 2 distance sensors that outputs a positive and negative signal into gyros. Instead of the gyros, use a normal servo. It works for a large tank I made. Just make sure the horizontal sensor is on the turret, and the vertical sensor is on the barrel.
Hey i've done done my own testing and I found that if you put A gyro on whatever the aiming servo is holding (im not sure if alignment matters) it can dampen the wobble though the stregnth and the amount of them depends on the thing your trying to prevent from wobleing.
The term you are looking for, Scrap, in describing weight vs distance is footpound. Though kg doesnt relate to feet or pounds without maths, I think Newtons might be the fogbreathing equivilant.
I believe the SI unit for torque is the Newton-meter.
Scrapman ! I tried something and got VERY interesting results,
150 kg of weight centered on the servo, no problem.
100kg of weight centered on the servo + 3 meter grid block arms on each side, BIG wiggle.
So it truly has nothing to do with momentum, the 150kg one has way more momentum, those little dinky arms are purely adding length, there weight is ridiculously low, and yet, even with 50kg LESS, those arms make it completely unstable.
Edit : the devs just announced a coming soon hotfix that should fix the issue entirely, I got Jamie (a dev) to test my blueprint described above in the new hotfix and it is indeed nice and stable.
Incorrect. It does have to do with momentum. Momentum increases as distance from center of rotation increases. It's called moment of inertia.
@@JasonBlack-d4l I know, I work in engineering.
You just didn't understood my comment.
I have 2 aiming servos, on one of them is 150kg stacked directly on top of the servo, as expected, that doesn't create any wobble.
On the other one, I have 100kg also stacked directly on top, in addition to that, I have two very lightweight arms that create very little inertia, sufficiently so that the extra 50kg on the other servo largely offsets it.
And yet, despite having less inertia than the first servo, it wobbles a lot, whereas the first one is completely fine.
The issue might also be that the shaking is actually moving your camera and therefore changes the target the aiming servo is aiming for.
I thinj the reason is bc it's meant to attach a weapon, not a entire build for it, but as someone said you can likely use it with a compass the other logic block to read the angle and send it to a regular cervo as logic blocks now are not binary but they can output a whole value like angles
During the tank Mecha battle you told Yuezi that the aiming servo was too wobbly and he said, yeah so I stuck a gyro stabilizer on it.
It would be cool if they visualized parts of the aiming servo like the range limit so you could see how far it will be able to turn while in build mode.
Just by playing with the speed of the rotators, it gives a great idea of PvP with a with an Artillery type cannon, like the Missile Cluster with Yuzi
the aiming servos sometimes glitch out when they spawn and start to wobble a lot, as seen in 3:10
I do think it would be cool to get a finite number on it, like at what weight and distance makes it unstable just to see a graph of the weight compared to distance haha
At 9:50 would adding a gyro to the turret above the servo help smooth the motion out?
Video idea: use aiming servos to steer, so you have to look where you're going. Then race with the vehicles, or put an stationary forwards facing gun on top of it and do a pvp battle
been done multiple times already
@JasonBlack-d4l what do you mean? I havent seen on scrapmans channel.
Video Idea: Planes, but the pitch surfaces are controlled with the aiming servo. Step further could be pitch and yaw, but I'm not sure how predictable that would be. 😅
The devs need to learn about the PID lmao
Until the patch fixing aiming servos is released, the way to correct the wobble is by using two opposing aiming servos for each axis. They will cancel out the feedback loop. You can still only build out so far before wobble is an issue, but at least this way I was able to get a mouse aim tank turret to work with minimal to no wobble.
from a game dev perspective (myself) dampening would do wonders, the devs need to add a small amount of dampening to the aiming servos, would fix ALL wobbling
Think about it as if you were a ship in space.
You have forward and reverse thrusters
You max thrust all the way to your destination, you over shoot it, have to reverse, then overshoot again.
If you max thrust up to 1 m/s till you get there, then you're gonna do much less overshooting
The more weight you have the harder it will be for your thrusters to stop the momentum from pushing you past your destination.
You can use stabilizer fins like shock absorbers to limit to help reduce the overshooting on the servos
Can you do capture the flag with an attacker and a defender. The attacker must have a magnet to grab the flag and the attacker has to be either a VTOL, helicopter or drone.
The defender must stay on their aircraft carrier and defend their flag. They will have more weapons than the attacker.
I would suggest connecting servos to vehicle via "soft physics blocks" like suspention or pistons. In theory soft nature would absorb exagerrated servo strengh and overcompensation in movement making aiming and turning much more smoother with fluid action
Could you use angle sensors mounted to mouse aim servos to measure your angle of aim and then have regular servos "repeat" those angles.
So maybe you could have larger turrets, with a mini "aiming turret" hidden within the build
Don't know if you get there yet.
Stacking servos in general might help, but stacking them with limited angles might create a bunch of stable hard stop points along the way.
Personally I think stacking them and seting them slow, so they are stable and fast based on additive movement
You could make a circuit per say, where youd have aming servos and sensors output to normal 360 servos, wich will have enough torque to handle more weight. Ether that or multiple aming servos connected to the same frame so their power multiplies. But those options are quite big to interpret into creations....
I would have loved to see you add a gyro to the rotation axis to see if it is possible to dampen the wobble
i made a tank with a turret using the aiming servo. i just used 4 max strength gyros with no controls and was pretty fine
Video Idea: Mouse Controlled Racing
Build and race vehicles, potentially directly against other players like Yuzi, that are controlled entirely with your mouse. Engines and thrusters are controlled by left and right click and steering is done through the aiming servos.
Camera position, for the times when the results were inconsistent.
You can see the wobble in the whole world, because the camera is not just following your input, but also the object. That adds to the forces involved. When the camera is closer, and especially if you look directly down, the wobble lessens or stops.
Of course that's not the whole thing, the weight obviously matters more.
I thought the camera position’s perspective affects both the vanishing point and the focus point 16:05
The wobbles could be a source of movement. If maybe feet with triggered anchor blocks on the feet could make a creation move without a motor.
Although I know the Dev's already announced they are going to release a hotfix for the aiming servos soon and increase the strength, but I just wanted to say your slight inconsistencies are due to the anchor blocks, they never let you land perfectly level or land consistently. So you had a slight angle affecting the movements, with 2 weights it made a very very minor difference, but as you saw, horizontal stability is drastically different from vertical. That's a thing I don't like about the anchor blocks haha.
Im really afraid that flashbulb be like ''EEHHH.. its fiineee''' and just leave it as it is...
I wonder if stacking two servos on top of each other and setting the speed of the top one at half the speed of the bottom. While also having a small range limit on the top would improve the stability. Since it would have a slight trailing, and ride the limit which was stable.
Oh wow, I joked about the aiming servo having no PID controller last vid, but the behaviour in testing confirms there is no PID going on.
Tuning a PID to work with any mass is impossible, but I'd expect better from TM...
These issues can be easily resolved by reducing the speed, but then it'd be less responsive.
Alternatively you use a PID with a derivative term, but that requires case by case tuning depending on the mass and inertia on the servo. You can however get an extremely responsive arm that way.
And the boring solution would be to physically fix the orientation of the arm and interpolate between positions, essentially creating infinite strength like how a piston clips through its own creation.
I kind of feel like I'm a fly on the wall of Scrapman going to the ophthalmologist (eye doctor) when he's doing the side by side testing.
Doc: "Alright tell me which one looks better; number one...or number two....Again, number one....and number two."
Scrapman: "They're very similar....NO, THE LEFT ONE IS WAY WORSE!!!!"
Doc: "That's not how this works. Again, number one... and number two. Which one is better?"
Scrapman: "They're practically the same."
Doc: "........."
Also you can use this intentionally and I'm surprised it hasn't been used in one of your multiplayer battles yet. You rig up this system with a couple miniguns and you have covering fire clearly covered. Spray and Pray is the name of this wobble if you mount a gun on it. Accuracy by volume.
23:45 thats a very strong shape
From first review, this servo need one additional "dead zone" settings to work properly.
This game needs melee weapon block. Make them use power cores and make them VERY resistant to collision damage, but not shooting damage. Then have blades and spike that can be fixed to vehicles and helicopter servos.
Can you put a regular gyro on the arm. It might make slow it, but it also might act like a shock absorber.
In Unity, when objects with a large mass difference are connected, everything becomes chaotic. I don't know what kind of physics engine Trailmakers uses, but there might be a similar issue.
hey scrapman just a suggestion for your mouse controlled arm to fix the uncontrollable movement if you haven't tried it already try lowering the strength on the servos maybe that would work.
Cool video idea : do a video on making a pure flying wing plane no vertical stabilisers or gyros
its cuz when it's trying to track your mouse when it goes past the mouse it goes to correct itself but passes your mouse and corrects again causing the wiggle.
So, I don't think it's intended
I think the lack of dampenimg make the cervo go in a oscillatory state.
A fix can be to make the cervo slower to reduce the overshoot but yeah.
We need a dampening option.
Adding more things is linked to adding more weight.
More weight equal more momentum, so a bigger oscillation.
That's why adding a counterweight isn't helping in this case.
dampening should 1, be an option and 2, we should get different options for it like the censors (exact, more than, less than, average, etc)
also just a general weight buff would be very nice
This is cool. It will make me practice my System class. Ima try to find a critically damped system that solves this.
I'm missing some data thought.
The distance from rotation makes a lever effect that will amplify the weight. That's why just a small weight far from rotation point will affect more than a lot stacked.
Your buffer blocks add weight to the horizontal aiming cervo making it worse, if the vertical ones are identical, the buffer blocks shouldn't impact its performance.
Except if theres sone stuff in the game engine thay I don't know.
They need to add a pid block, though I think that'll add wayyy more complexity
try using this instability to build a bionic league bird or other type of flying creation
You are firmly in the world of discrete math in Trailmakers, due to the blocky nature of builds. So rather than I = ∫r²Δm, use I = ∑r²m. Which is the summation of the square of the center point displacement of each block, multiplied by its mass. No messy antiderivatives needed.
It seems like it's just an issue with how it is designed to function; when the angle is not at your mouse, it puts 100% power to get there, taking the weights and inertia with it, causing overshoot, which then get 100% power to go back the other way, forever. If it were changed to percentage-based instead of boolean on/off power, if it were only off by a little then it would only give a little bit of power to move back, preventing the feedback loop, as it would slowly get closer and closer to its desired Target as it decreased the amount of power it reintroduced as it got closer.
I wonder if center of mass has something to do wih the instabilities? Because if your camera is centered on your center of mass, the aiming servo moving would move the center of mass and thus your camera and thus where you're aiming.