IMU stopped working #41
Comments
|
I will check if new changes broke anything for imu. Would you mind doing: and pasting the output so I can quickly check if everything seems right there. |
|
Sure, here's it: root@rae:~# fw_printenv
altbootcmd=run mender_altbootcmd; run bootcmd
arch=arm
baudrate=115200
board=kmb-dm3370-r5m2e5
board_name=kmb-dm3370-r5m2e5
boot_failed_handle=if test ${is_secure} = 1; then run do_reset; fi;
boot_fit=bootm ${fit_addr} - ${fdt_addr}
boot_linux=booti ${kernel_addr} ${initrd_addr} ${fdt_addr}
bootargs=rootwait rw mender.data=/dev/mmcblk1p11 earlycon=uart8250,mmio32,0x20180000
bootcmd=run os_recovery_if_needed_cmd; run mender_setup; setenv bootargs root=${mender_rootfs_name} ${bootargs}; load ${mender_kernel_root} ${kernel_addr_r} ${mender_kernel_name}; ${mender_boot_kernel_type} ${kernel_addr_r} - ${fdt_addr}; run mender_try_to_recover; run boot_failed_handle
bootcount=1
bootdelay=2
bootlimit=1
cpu=armv8
do_reset=echo Secure system reset on boot cmd fail; reset;
env_version=1
fastboot.Bootstage=bl33
fastboot_flash_mmc_dev=1
fdt_addr=fff3bf80
fdt_high=f8200000
fit_addr=90000000
flash_env_version=1
initrd_addr=f8200000
initrd_high=0xffffffffffffffff
is_secure=0
kernel_addr=f0080000
kernel_addr_r=90000000
mender_altbootcmd=if test ${mender_boot_part} = 5; then setenv mender_boot_part 8; else setenv mender_boot_part 5; fi; setenv upgrade_available 0; saveenv; run mender_setup
mender_boot_kernel_type=bootm
mender_boot_part=8
mender_kernel_name=Image
mender_setup=setenv mender_rootfs_name /dev/${mender_storage_device_base}${mender_boot_part}; setexpr mender_kernel_part ${mender_boot_part} - 1;setenv mender_kernel_root ${mender_uboot_storage_if} "${mender_uboot_storage_dev}":${mender_kernel_part}; setenv expand_bootargs "setenv bootargs \\"${bootargs}\\""; run expand_bootargs; setenv expand_bootargs
mender_storage_device_base=mmcblk1p
mender_try_to_recover=if test ${upgrade_available} = 1; then reset; fi
mender_uboot_boot=${mender_uboot_storage_if} "${mender_uboot_storage_dev}":4
mender_uboot_storage_dev=1
mender_uboot_storage_if=mmc
os_recovery_if_needed_cmd= keembay_recovery_flag read_and_clear recovflag; if test $recovflag -eq 1; then run recoverycmd; elif test $recovflag -eq 2; then run recoveryeth; elif test $recovflag -eq 3; then mmc dev 1; mmc purge data; elif test $recovflag -eq 4; then fastboot 0 3000 ; fi; gpt verify mmc ${fastboot_flash_mmc_dev} $required_partitions; if test $? -ne 0; then run recoverycmd; fi
partitions=name=capsule,start=1MB,size=32MB,type=8DA63339-0007-60C0-C436-083AC8230908;name=env-main,start=0x2100000,size=0x80000,type=8DA63339-0007-60C0-C436-083AC8230908;name=env-redund,start=0x2180000,size=0x80000,type=8DA63339-0007-60C0-C436-083AC8230908;name=boot_a,size=256MB,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;name=system_a,size=3GB,type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;name=syshash_a,size=128MB,type=8DA63339-0007-60C0-C436-083AC8230908;name=boot_b,size=256MB,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;name=system_b,size=3GB,type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;name=syshash_b,size=128MB,type=8DA63339-0007-60C0-C436-083AC8230908;name=factory,size=64MB,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;name=data,size=-,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
recoverycmd=fastboot 0
recoveryeth=load mmc 1:a ${kernel_addr_r} /Recovery; bootm ${kernel_addr_r} - ${fdt_addr}
required_partitions=name=capsule,start=1MB,size=32MB,type=8DA63339-0007-60C0-C436-083AC8230908;name=env-main,start=0x2100000,size=0x80000,type=8DA63339-0007-60C0-C436-083AC8230908;name=env-redund,start=0x2180000,size=0x80000,type=8DA63339-0007-60C0-C436-083AC8230908;name=boot_a,size=256MB,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;name=system_a,size=3GB,type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;name=syshash_a,size=128MB,type=8DA63339-0007-60C0-C436-083AC8230908;name=boot_b,size=256MB,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;name=system_b,size=3GB,type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;name=syshash_b,size=128MB,type=8DA63339-0007-60C0-C436-083AC8230908;
serial#=4B928816838860C6
soc=kmb
vendor=intel
reset_flag=false
upgrade_available=0 |
|
That's the host OS output. If you meant container, then |
|
In logs, I see the following: Only EKF prints something related to IMU: |
|
Topics: |
|
Here's the video from RViz. Note that a robot randomly moves left-right (virtually). But there was no physical interaction made or teleop ran. Then I moved it manually a little bit, but IMU marker obviously left in the same place, as there's no data received. rae_imu.mp4Could it be the result of the merging of the recent updates? As I believe that several days ago I haven't seen such behavior. |
|
Yea that is output for printenv I needed - everything seems ok there. We are working on IMU related things right now but no changes recently pushed to humble should break the behavior. Lets try one more thing. Can you add To your camera config at /ws/src/rae-ros/rae_camera/config/camera.yaml inside the container (you dont need to rebuild the package) as another sub category under ros_parameters. That should fix the issue. |
|
Yeah, now I see the data published. But, RViz doesn't reflect IMU changes due to: [INFO] [1697836266.854962595] [rviz]: Message Filter dropping message: frame 'rae_imu_frame' at time 1697746072.441 for reason 'the timestamp on the message is earlier than all the data in the transform cache'Seems like it drops all the messages.
|
|
Note that I tried Cyclone DDS as well, but no luck. |
|
Also note that if I change the fixed frame in RViz to base_link, the IMU message drop errors disappear. However, the IMU marker is displayed flipped (z at the bottom). And of course it affects the map rendering. |
sskorol
added a commit
to sskorol/rae-ros
that referenced
this issue
Oct 22, 2023
sskorol
added a commit
to sskorol/rae-ros
that referenced
this issue
Oct 22, 2023
sskorol
added a commit
to sskorol/rae-ros
that referenced
this issue
Oct 22, 2023
Signed-off-by: sskorol <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
IMU data is not published anymore.
Steps:
luxonis/rae-ros-robot:humblerobot.launch.pyorbringup.launch.pyw/o LED noderos2 topic echo /rae/imu/dataExpected: IMU data is published.
Actual: there's no data at all.
Note that when I used the previous docker images, at least angular velocity and linear acceleration were published. On the other hand, IMU plugin didn't reflect any changes in robot's pose in RViz.
The text was updated successfully, but these errors were encountered: