Is there a property for relative velocity

  • David Piotrowski

    I want to implement a velocity sensor for AirRobot but accessing the Platform.CenterItem.StaticMeshComponent.BodyInstance.Velocity variable yields only absolute velocity-values. If I set the AirRobot to fly circles by giving it a constant forward velocity and rotation I would like to get these values back from my velocity sensor. Instead what I get are constantly changing velocities in the X/Y plane (well, absolute values). Is there some other variable that contains the relative velocity values or do I have to write a method that recalculates these values from the absolute velocities and the AirRobot's orientation? This seems like quite a lot of overhead to me.

  • Stephen Balakirsky

    I am afraid that my reply will not be of much help, but I thought that I would try…

    I know that some of the calls in UDK support both global and local frames. The best way to try and find a local frame equivalent would be to dig around in the UDK script reference and look at various properties. Unfortunately, I have been using the UT3 script reference since I have been unable to find one for UDK (it works for most things). The UT3 reference is located at If anyone know of a similar resource for UDK, please post it!

  • Nicola Basilico

    Nicola Basilico - 2012-05-04

    I'm not sure to have completely understood which information you would like to obtain with that sensor. Are you interest in the robot's speed (i.e., the absolute value of the velocity) or in the velocity relative to the AirRobot's center of mass?

    Anyways, I would suggest to look at the last part of the Tick() function (in AerialVehicle.uc), where you have this call that sets the vehicle's velocity:


    If speed is what you need, you can just take the absolute value of the vector linVelocities>>linVelTrans

    . If instead you need velocity, just taking the vector itself should work. A fast way to do that could be to store the data you need into a global variable and then accessing it from the sensor script (from what you mentioned, I guess you did something similar with the [...].BodyInstance.Velocity)
    Let me know if this answered your question.
  • David Piotrowski

    Thanks a lot for your replies :-) I'll have a look at your suggestions and tell you wether it helped.

    I'm sorry I didn't make myself clear. I guess I tend to overcomplicate things a little…
    I know how to get the absolute velocities. What I want to get I guess is what you called 'the velocity relative to the AirRobot's center of mass'. If the robot flies in circles I want to be able to decompose that movement into a constant forward movement and a rotation speed which is constant, too, instead of the three absolute velocity's components which are going up and down in a sinus/cosinus kind of way. Hope I made myself a little clearer now although I guess I'm making it more complicated than neccessary again…

  • David Piotrowski

    Since I have not been able to find some useful method in the UT3 Script reference and the code suggested by nbasilico didn't help me much either, I had to write the code for the sensor from scratch. I seem to have a working sensor now that gives me the relative velocities. The approach I took is the following.
    Considering that the AirRobot's roll and pitch angle in the current implementation have no influence on its movement but only try to make things look nicer, the only thing that needs to be taken into account for the relative velocities are the AirRobots yaw angle and its absolute velocity. It boils down then to a rotation matrix in 2D, since the AirRobot's z-speed stays the same in the relative and absolute case.
    The sensor performs ok so far. If I am letting the AirRobot fly circles at 100% forward speed and 50% rotation speed the sensor should report a forward speed of 2 m/s and a left/right speed of 0 m/s. What I am actually getting from the sensor is a forward speed of 1.99xx m/s and a left/right speed of about 0.02 m/s which is an error of about 1%. This is quite all right with me. I guess the errors depend on the accuracy of floats and the timing of measurements. Maybe the error could be reduced a little bit more if the sensor would not calculate with m/s internally but with unreals native units and numbers, doing a transformation only before reporting the values.

    Thanks for your input guys :-)

  • Stephen Balakirsky

    great news on the sensor. can you check it in so others can use it? Also, a wiki entry would be great. Thanks.

  • David Piotrowski

    I'll try to find the time for it,

    cheers :-)


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks