ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
Sorry, I couldnt upload this pic as a comment. The "Form"/path precission is more accurate in slide 4/5(blue) as opposed to the last slide (orange). Size and starting point is just pixel perfect but specially in the turns I think its clearly seen that the yaw=0 roll=180 (slide 4/5) gives a more accurate ekf output compared to the reference.
2 | No.2 Revision |
Sorry, I couldnt upload this pic as a comment. The "Form"/path precission is more accurate in slide 4/5(blue) as opposed to the last slide (orange). Size and starting point is just pixel perfect but specially in the turns I think its clearly seen that the yaw=0 roll=180 (slide 4/5) gives a more accurate ekf output compared to the reference.
EDIT: I just realized that your tf tree above might no more be current. Is the static transform publisher between local and imu frame still active?
I also found in REP 103: "Coordinate Frame Convention".
Axis Orientation
In relation to a body the standard is:
x forward
y left
z up
For short-range Cartesian representations of geographic locations, use the east north up [5] (ENU) convention:
X east
Y north
Z up
To avoid precision problems with large float32 values, it is recommended to choose a nearby origin such as your system's starting position. Suffix Frames
In the case of cameras, there is often a second frame defined with a "_optical" suffix. This uses a slightly different convention:
z forward
x right
y down
For outdoor systems where it is desirable to work under the north east down [6] (NED) convention, define an appropriately transformed secondary frame with the "_ned" suffix:
X north
Y east
Z down
3 | No.3 Revision |
Sorry, I couldnt upload this pic as a comment. The "Form"/path precission is more accurate in slide 4/5(blue) as opposed to the last slide (orange). Size and starting point is just pixel perfect but specially in the turns I think its clearly seen that the yaw=0 roll=180 (slide 4/5) gives a more accurate ekf output compared to the reference.
EDIT:
I just realized that your tf tree above might no more be current. Is the static transform publisher between local and imu frame still active?active? There yaw is dialed up 99° and now e dial down yaw in the urdf by 90° leaving an error of 9°. If this transform is still active going back to the original urdf and setting the static transform correctin yaw to Zero, might finally solve it all.
I also found in REP 103: "Coordinate Frame Convention".
Axis Orientation
In relation to a body the standard is:
x forward
y left
z up
For short-range Cartesian representations of geographic locations, use the east north up [5] (ENU) convention:
X east
Y north
Z up
To avoid precision problems with large float32 values, it is recommended to choose a nearby origin such as your system's starting position. Suffix Frames
In the case of cameras, there is often a second frame defined with a "_optical" suffix. This uses a slightly different convention:
z forward
x right
y down
For outdoor systems where it is desirable to work under the north east down [6] (NED) convention, define an appropriately transformed secondary frame with the "_ned" suffix:
X north
Y east
Z down
4 | No.4 Revision |
Sorry, I couldnt upload this pic as a comment. The "Form"/path precission is more accurate in slide 4/5(blue) as opposed to the last slide (orange). Size and starting point is just pixel perfect but specially in the turns I think its clearly seen that the yaw=0 roll=180 (slide 4/5) gives a more accurate ekf output compared to the reference.
EDIT:
I just realized that your tf tree above might no more be current. Is the static transform publisher between local and imu frame still active? There yaw is dialed up 99° and now e we dial down yaw in the urdf by 90° leaving an error of 9°. If this transform is still active going back to the original urdf and setting the static transform correctin yaw to Zero, might finally solve it all.
I also found in REP 103: "Coordinate Frame Convention".
Axis Orientation
In relation to a body the standard is:
x forward
y left
z up
For short-range Cartesian representations of geographic locations, use the east north up [5] (ENU) convention:
X east
Y north
Z up
To avoid precision problems with large float32 values, it is recommended to choose a nearby origin such as your system's starting position. Suffix Frames
In the case of cameras, there is often a second frame defined with a "_optical" suffix. This uses a slightly different convention:
z forward
x right
y down
For outdoor systems where it is desirable to work under the north east down [6] (NED) convention, define an appropriately transformed secondary frame with the "_ned" suffix:
X north
Y east
Z down
5 | No.5 Revision |
Sorry, I couldnt upload this pic as a comment. The "Form"/path precission is more accurate in slide 4/5(blue) as opposed to the last slide (orange). Size and starting point is just pixel perfect but specially in the turns I think its clearly seen that the yaw=0 roll=180 (slide 4/5) gives a more accurate ekf output compared to the reference.
EDIT:
I just realized that your tf tree above might no more be current. Is the static transform publisher between local and imu frame still active? There yaw is dialed up 99° and now we dial dialed down yaw in the urdf by 90° leaving an error a difference of 9°. If this transform is still active going back to the original urdf and setting the static transform correctin yaw to Zero, this might finally solve it all.
I also found in REP 103: "Coordinate Frame Convention".
Axis Orientation
In relation to a body the standard is:
x forward
y left
z up
For short-range Cartesian representations of geographic locations, use the east north up [5] (ENU) convention:
X east
Y north
Z up
To avoid precision problems with large float32 values, it is recommended to choose a nearby origin such as your system's starting position. Suffix Frames
In the case of cameras, there is often a second frame defined with a "_optical" suffix. This uses a slightly different convention:
z forward
x right
y down
For outdoor systems where it is desirable to work under the north east down [6] (NED) convention, define an appropriately transformed secondary frame with the "_ned" suffix:
X north
Y east
Z down
6 | No.6 Revision |
Sorry, I couldnt upload this pic as a comment. The "Form"/path precission is more accurate in slide 4/5(blue) as opposed to the last slide (orange). Size and starting point is just pixel perfect but specially in the turns I think its clearly seen that the yaw=0 roll=180 (slide 4/5) gives a more accurate ekf output compared to the reference.
EDIT:
I just realized that your tf tree above might no more be current. Is the static transform publisher between local and imu frame still active? There yaw is dialed up 99° and now we dialed down yaw in the urdf by 90° leaving a difference of 9°. If this transform is still active going back to the original urdf and setting the static transform correctin yaw to Zero, this might finally solve it all.
I also found in REP 103: "Coordinate Frame Convention".
Axis Orientation
In relation to a body the standard is:
x forward
y left
z up
For short-range Cartesian representations of geographic locations, use the east north up [5] (ENU) convention:
X east
Y north
Z up
To avoid precision problems with large float32 values, it is recommended to choose a nearby origin such as your system's starting position. Suffix Frames
In the case of cameras, there is often a second frame defined with a "_optical" suffix. This uses a slightly different convention:
z forward
x right
y down
For outdoor systems where it is desirable to work under the north east down [6] (NED) convention, define an appropriately transformed secondary frame with the "_ned" suffix:
X north
Y east
Z down