Rotor Velocity syncing

Is it possible to make script which allows rotors to copy another rotors velocity, not by copying the input I give but by copying the movement of the main rotorhead?

And if yes could someone write it?

Why?:
I want to make a car but I don't want to use the normal suspensions, so I intent to use rotors for the wheels and still accelerate forward and backwards with W and S by controlling the velocity of the main rotor through a rotor attached to a wheel with suspension

Sorry for my crappy english

P.s. Example Screenshot



If the master rotor is spun the slave rotors should mimic him

 

There are scripts to synchronize the angle which once they are in sync leads to a good approximation of the same velocity.
Though i dont have a link at hand. It also shouldnt be too difficulty to make a small program to do that youself as you have to define one master block and a list of slave blocks. The master gets directly driven and the slaves try to sync with the master where the offset defines the magnitude (either acceleration in an ideal case or simply just velocity for a simple approach).

 

I found a script that promises something similar to what I want but if the Master Rotor stops the Slaves will keep spinning and if the Master Rotor starts spinning in the other direction the Slaves will keep going in the same direction the did before

 

Shame it didnt work like you expected.

Also it just came to me when i got a video comment today.
It seems that i did something you could use and even try to do too there.

I had a suspension wheel which drives a rotor from which i read the angle to drive rotor attached wheel blocks.
Apparently you had the same setup, so once i upload the world next week when iam home - if it still works after all the recent patches since i made it - you should have a working copy of a script to adapt to your use.

Overall though, there is one important note. Wheel blocks on rotors do not work as good as suspension wheels as they got friction settings etc and thus kinda "glue" to the ground unlike rotor blocks which slide over it in a very annoying way.

 

Nice @plaYer2k , I can see this becoming really handy in the future.

 

@plaYer2k: I look forward to your upload. I'm currently developing a proportional 6 axis (probably going to end up as 5, the linear vertical is proving hard to sample) controller script for someone else's project. I would like to see your control sampling implementation in more detail. are you slaving the angles of the drive motors to the sample rotor or the velocity? or are you using a time based measure to get change in velocity? how do you then garantee the drive wheels are in sync with each other for speed if you are applying speed changes as angular accelerations? related to that, how does in react to inertial lag? what method are you using for damping oscillations about the set point?
sorry, you don't have to answer those, I can wait for the upload.

 

I would use the velocity if that were accessible, at least it wasnt when i made the script there.

Here is a schematic overview



I gather the current Rotor Sensors angle (orange) and determined the velocity over time through the time difference. Though that was still with the old method of using the current timestamp and not the elapsedTime which didnt exist then.

The Rotor Sensor is directly connected to the Suspension Accelerator (green) which gets controlled through the cockpits default game mechanics. Steering is disabled for these Suspension Wheel blocks.

Based on the detected velocity aswell as a straight linear velocity multiplier, the Rotor Acceleration (red) gets driven to which the Wheels are attached. That propels the car in either forward or backward direction.

The Suspension Steering (purple) is controlled through the cockpit aswell. Only steering is enabled, the propulsion is disabled.

The steering angles (teal) are still fixed, but that is my next project. The angles shall tighten so that they have a common focal point to allow better rotations.


I hope that quick overview is enough info to understand this concept.

 

@plaYer2k wow, i was not expecting such a well presented and considered response, thanks i hope you didn't spend too much time on it.

that's pretty much the same physical set up I've settled on for sampling W/S inputs. i can see how the wheel inertia and a slight rotor brake would give you good damping, as well as effectively an acceleration curve based on current speed. that's cool
i am using it for piston and rotor position control.
i wasn't aware of the restrictions to the PB being so restrictive in the (recent?) past. I've only been using the PB for a few weeks.
have you considered a servomechanisms?

the way Ive set it up, use the rotors angle limited to +\- 5 degrees, set the torque to not quite overcome the suspension power (i wish we had an actual torque figure there). then run a script that samples the current rotor angle (and converts to degrees), gets the reciprocal angle, then subtracts that angle from 180. this outputs the error between where a null input is, and where the current input is, signed for direction. i amplify that by a constant to bring it up to rotor speeds, run it through a min/max so it doesn't exceed the rotors variable range, then set it as the rotors velocity in rpm (+\-). this drives the rotor back onto zero degrees as long as its set torque is more than the suspension torque. when you press W or S it drives the suspension wheel into the min or max deflection of the rotor and holds it there as long as you are pressing it. the error output is also fed off into a tri-state logic tree. there is a small dead zone around zero error (which you need, because with float, and the nature of the continuous efforts of the rotor to self correct, you never actually get zero) which outputs a 'no change' state. a positive deflection (W pressed) gives a 'accelerate' state, negative (S Pressed) gives a 'decelerate' state. because its such a small deflection, the state changes very quickly. and because its self centering, it detects no input very quickly too.
the tri-state outputs to the acceleration controller. that samples the output velocity (the current velocity of the drive rotor) which is also signed for direction. based on the tristate and the current velocity, it applies one of 4 accelerations to the drive velocity, there are different acceleration and deceleration values, acceleration is assumed as 'an application of force' for the purposes here. mostly so i could have 2 constants rather than 4, so if you press W or S, the velocity is increased or decreased by x (whatever you like for your style) depending on which direction its currently moving. if there is no input, it uses the decelerate value, (generally 0.5x). so if the rotor is under no input, it will slow itself at a user defined rate. when it falls to 0.6x velocity, its told to set its speed to zero. if you then push the drive rotor, sure, it will spin, but it will also fight to stay at zero speed.
im also using a gyro/rotor combo to sample Q and E in a similar self centering set up. in mine that controlling a piston. but in yours it could be set up with the same acceleration values, but they are applied to 'zero speed' value of the drive rotor and don't apply the deceleration values. the speed the drive rotor tries to achieve under a no input state. it would act like... electronic cruise control, the longer you hold E, the faster you cruise, hit S to break, W to overtake, Q to set a lower speed. you could probably toggle a light with the tool bar and sample its state to reset the cruise speed to zero. any way, my point is, if you use a similar set up you could use rotors for proportional steering control by having the output rotors centre on the angle the tristate drives to, and get away from the suspension blocks. (although i suppose you could also use the process to adjust the steering angle of the suspension.)
the biggest issue I've found with the rotors is that now you can set the angle directly, people seem to be assuming they are like hobbyist servo motors. give them an angle and they drive to it using a PID controller with preset damping. but they are not that sophisticated. I've found just straight scripted error proportional feedback control works ok for the mechanical parts as long as you are careful to set the limits to balance response speed and accuracy. then its a servomechanism maintaining a set state of motor position. or velocity. or acceleration, or torque. or any combination of them.
i have mine set up to run every tick (small acceleration values are a must...) with getblockbyname (i don't see the point in listing everything when i know what I'm looking for) cycling through the input axis and outputs with a for loop. at the moment I've achieved 2 axis outputting to 12 rotors or pistons. its very smooth. i cant give you the actual script to look at because I'm developing it for someone else. but the proportional feed back control concept is industry standard and basically considered assumed knowledge, so i can share that. you know, it would have been shorter to post the code ah well.

while i would be happy if you found something in the above useful, i would be thrilled should you come up with a novel solution that has good control. I'm very interested to see your approach to dynamic steering toe-in, its a fiddly problem and bound to be fun to solve. i wish you the best of luck. oh, also there are some photos of an arm made with cantilevered pistons, its looked really stable, might be an interesting alternative to rotors for steering control... i cant remember which planet thread it was in. sorry.

 

Whew thats a nice feature, finally.

I havent played for three weeks now. So if that works now, it will help a lot.

I had some simple servo wrapper for rotors but i never liked to use it because it felt odd.


Your approach of having an acceleration value that gets increased or decreased through the wheels velocity is a nice, if i understood that right with the IRL heat here around.
When linked to a constant decay aswell as some simple parameters, this could be a good method of building a second layer of car controls.
Only the handbreak is missing, which can be a hotbar key.

That just reminds me of a ship control method i wanted to do long ago and thought about today.
Having a Gimbal system with two axis that holds a cockpit or chair with a gyro. The rotors are set to a moment of 0 N and their CoM is balanced around the center of rotation as close as possible.
The rotating cockpit then determines the forward vector which it is facing at and the ship then tries to align to that vector.
This could be used for spacecrafts aswell as for cars and the steering on cars would feel like Halo car driving. On space crafts it would be similar to that, kinda like freelancer controls maybe.
That could be a really interesting concept.
Adding a third axis for space crafts allows for rotations aswell

These concepts are why i love SE. The flexibility and especially the ingame programming.
But its also the reason why i hate it. I dont have time for all of these ideas, and for a life too.

Other ideas like using lights and dynamic 3D pattern to control these lights on a ships hull and interior for effects like the video below are long on hold.

So redoing some crafts of others aswell as finally coding the focal steering script are the next projects, when i am back home after 3 weeks without SE.

 

ouch, 3 weeks without SE. *sympathetic shoulder pat* that would hurt.
the handbrake is self implimented. if the set point of the feedback controller is zero rpm, it will use torque and velocity to attempt to maintain zero rpm dynamically.
with your gimbaled cockpit idea: if you put a remote block on the gimbaled grid instead of a cockpit, you can make it smaller, remove the need for advanced rotors passing oxygen and remove the consideration of pilot egress. because its on an attached grid to where the actual cockpit is, it doesn't need an antenna to acess. and as its always attached, the remote block can be tool bar equiped. now that I'm thinking about it, the new autopilot functions could be used with it too. autopilot hates cars. it doesn't know how to use them. but it does know how to use gyros and thrusters to point at a waypoint and accellerate. if it does that from inside the gimbal, the control script could translate it into car controls. hmm.
I'm still trying to sample for six axis. if I can get the PB to access the values a cockpit applies to gyros and thrusters, I should be able to make a 'solid state' system with no moving parts. it would be even better if those values are set and stored in thrusters and gyros that have power and override set to zero. I need to get off my butt and copy the html library document to my phone so I can look this stuff up at work.
also, volumetric led displays are awesome. I wanted to make one as a project, but dimable tricolour leds are really expensive (some getting on to $2 each) doesn't sound like much, until you count how many you need for a 50 pixel wide cube.

 

So.. no luck

 

I'm sorry @ThatGuy, I've had something for this for a month or so, I had just completely forgotten about this thread. ill pm you a short script tonight that will do the job.