ROS Answers: Open Source Q&A Forum - RSS feedhttps://answers.ros.org/questions/Open source question and answer forum written in Python and DjangoenROS Answers is licensed under Creative Commons Attribution 3.0Fri, 05 May 2023 14:49:07 -0500robot_localization EKF internal motion modelhttps://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/As I was not able to find this information in the documentation of the [`robot_localization` package](http://wiki.ros.org/robot_localization) nor its source code, does anybody know what the "internal motion model" is that is used in the`ekf_robot_localization` node?
Edit: In the corresponding [paper](http://wiki.ros.org/robot_localization?action=AttachFile&do=view&target=robot_localization_ias13_revised.pdf), the authors state that they use a "standard 3D kinematic model derived from Newtonian mechanics", but I guess this model is derived from the kinematics of the test platform they used for the experiments.Tue, 01 Dec 2015 10:01:04 -0600https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/Answer by Tom Moore for <p>As I was not able to find this information in the documentation of the <a href="http://wiki.ros.org/robot_localization"><code>robot_localization</code> package</a> nor its source code, does anybody know what the "internal motion model" is that is used in the<code>ekf_robot_localization</code> node?</p>
<p>Edit: In the corresponding <a href="http://wiki.ros.org/robot_localization?action=AttachFile&do=view&target=robot_localization_ias13_revised.pdf">paper</a>, the authors state that they use a "standard 3D kinematic model derived from Newtonian mechanics", but I guess this model is derived from the kinematics of the test platform they used for the experiments.</p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?answer=221944#post-id-221944It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In [this](http://perso.uclouvain.be/georges.bastin/paper37.pdf) paper, it corresponds to the robot type (3,0), but the model in *robot_localization* is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is `x_new = x_old + vx * t + 0.5 * a * t^2,` but `v` and `a` are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just `vx_new = vx_old + at`. Each row in the matrix is a transition function. We then derive the Jacobian analytically.
Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the `process_noise_covariance` matrix values if the model doesn't match your robot well.
If you want to take a look, check out the [predict](https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209) function. Thu, 03 Dec 2015 20:07:16 -0600https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?answer=221944#post-id-221944Comment by plafer for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=363486#post-id-363486I looked everywhere for this information, and I feel like it really should be included in the documentation of the package!Thu, 15 Oct 2020 08:50:51 -0500https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=363486#post-id-363486Comment by Tom Moore for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=363584#post-id-363584Yeeaaaah, it probably should, I agree. Feel free to file a ticket, but I can't promise anything soon, sorry. :(Fri, 16 Oct 2020 11:42:53 -0500https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=363584#post-id-363584Comment by takahashi for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=221948#post-id-221948thanks Tom and great work by the way! :-)Fri, 04 Dec 2015 01:15:02 -0600https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=221948#post-id-221948Comment by angelos.p for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=415066#post-id-415066Great explanation, Tom. Thank you for your great work!Fri, 05 May 2023 14:49:07 -0500https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=415066#post-id-415066Comment by Tom Moore for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=221975#post-id-221975Thank you!Fri, 04 Dec 2015 08:14:25 -0600https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=221975#post-id-221975Comment by kgandhi24 for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=271164#post-id-271164Hey Tom,
If sensor data ( encoder and IMU ) has been used in prediction step and which data are you using in correction step?Tue, 19 Sep 2017 09:56:12 -0500https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=271164#post-id-271164Comment by Tom Moore for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=271165#post-id-271165The prediction step is handled entirely by the motion model. IMU and encoder data is used in correction.Tue, 19 Sep 2017 10:01:50 -0500https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=271165#post-id-271165Comment by Tom Moore for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=271166#post-id-271166@fastestindian The motion model isn't really conducive to Ackermann platforms (in 2D mode, it's really just a unicycle model), but it depends on the data you feed it. If you are feeding it pose data from some other Ackerman model, then the prediction step will be a bit off, but will get corrected.Tue, 19 Sep 2017 10:05:21 -0500https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=271166#post-id-271166Comment by fastestindian for <p>It's a generic omnidirectional motion model which isn't all that complicated, but it's a bit much to write out here. In <a href="http://perso.uclouvain.be/georges.bastin/paper37.pdf">this</a> paper, it corresponds to the robot type (3,0), but the model in <em>robot_localization</em> is in 3D. Each variable has a nonlinear transition function, and we encode those transition functions as a matrix. So, for example, the transition function for x is <code>x_new = x_old + vx * t + 0.5 * a * t^2,</code> but <code>v</code> and <code>a</code> are given in the body frame of the robot, so we have to apply 3D rotations to them. The orientations have similar logic. Velocities (for x) are just <code>vx_new = vx_old + at</code>. Each row in the matrix is a transition function. We then derive the Jacobian analytically.</p>
<p>Naturally, this won't necessarily match ever robot perfectly, but in practice, it works pretty well for a broad range of robots. You an always increase the <code>process_noise_covariance</code> matrix values if the model doesn't match your robot well.</p>
<p>If you want to take a look, check out the <a href="https://github.com/cra-ros-pkg/robot_localization/blob/indigo-devel/src/ekf.cpp#L209">predict</a> function. </p>
https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=269352#post-id-269352Hi Tom,
We want to use robot_localization to localise a non-holonomic platform, aka ackermann. I was wondering if the 3D motion model in the EKF/UKF nodes would cover these motion constraints, and if so, is there a chance it could fail for an ackermann platform? Your advise is appreciated!Tue, 22 Aug 2017 11:43:38 -0500https://answers.ros.org/question/221837/robot_localization-ekf-internal-motion-model/?comment=269352#post-id-269352