Group Details Private

administrators

  • RE: 小强AMCL导航,可以自主定位吗?为什么rviz里每次都需要手动定位(2d pose estimate)才可以?

    @eee 试试cartographer的重定位

    posted in 激光雷达
  • RK3588 npu python运行 YOLOv8 和 YOLOv8-seg 的教程

    在 RK3588 上运行 YOLOv5 的教程比较丰富,而对于 YOLOv8 相关的 Python 开源库则较少。对于多线程推理,一个不错的开源库是 rknn-multi-threaded。RKNN_model_zoo 中的 examples 提供了 YOLOv8 的相关 demo,但其 Python 后处理部分编写不佳,需要 PyTorch 依赖,并且后处理耗时较大,无法满足视频实时推理的需求。
    我们在 rknn-multi-threaded 的基础上,对 RKNN_model_zoo 中的 YOLOv8 example 进行了整合,并使用 github Copilot 重写了后处理函数。这一改进不仅取消了对 PyTorch 的依赖,还将后处理耗时从几百毫秒降低到了几十毫秒。在 3 线程模式下,推理 YOLOv8s 模型可以达到约 45fps,而推理 YOLOv8s-seg 模型则可以达到约 25fps。

    一、优化修改后的开源代码库

    二、代码运行说明

    上面三个代码仓库的运行方法相同,都是通过 git clone 克隆代码后,准备好 Python 环境,然后执行 main.py。我们以 YOLOv8 为例:

    1. 升级 NPU 运行库。参考 RK3588 在 Ubuntu22.04 下使用 rknn-toolkit2 的注意事项
    2. 克隆源代码:
    git clone http://git.bwbot.org/publish/rknn3588-yolov8.git
    
    1. 准备python运行环境:
      我们在 RK3588 上使用的是 Ubuntu22.04 Desktop,默认的 Python 版本是 3.10。为了避免破坏系统环境,我们使用 virtualenv 来配置需要的 Python 运行环境。
    sudo apt install python3-virtualenv
    
    #进入上面git clone下来的文件夹根目录
    cd rknn3588-yolov8
    
    #创建虚拟环境
    virtualenv --system-site-packages -p /usr/bin/python3 venv
    
    #激活虚拟环境
    source venv/bin/activate
    
    #开始在虚拟环境中安装rknn_toolkit_lite2,这里需要安装和python版本相同的whl
    pip install rknn_toolkit_lite2-2.0.0b0-cp310-cp310-linux_aarch64.whl
    
    #安装opencv
    pip install -i https://mirror.baidu.com/pypi/simple opencv_contrib_python
    

    4.环境配置完成,开始运行yolov8:

    python main.py
    

    main.py 文件中,您可以修改模型、线程数,还可以修改成实时推理摄像头。

    # 推理视频文件
    cap = cv2.VideoCapture('./720p60hz.mp4')
    # 推理实时摄像头
    cap = cv2.VideoCapture(0)
    cap.set(cv2.CAP_PROP_FRAME_WIDTH,640)
    cap.set(cv2.CAP_PROP_FRAME_HEIGHT,480)
    

    三、运行结果

    YOLOv8s 的运行速度大约是 YOLOv5 的 70%,YOLOv8s-seg 的运行速度大约是 YOLOv8s 的 50%。
    YOLOv8s 运行截图
    YOLOv8s-seg 运行截图
    YOLOv8s-seg 实时摄像头截图

    posted in 技术交流
  • RE: 求助:orbslam2中观测为0的地图点是怎样产生的?谢谢

    @anbeeyao 这个是因为keyframe可能会被删除,删除后相关的地图点也就可能存在观测为零的情况

    posted in 机器视觉
  • rk3588在ubuntu22.04下使用rknn-toolkit2的注意事项

    rknn-toolkit2是开发rk3588的npu时使用的sdk,github地址是:https://hub.nuaa.cf/airockchip/rknn-toolkit2.git。
    git clone下载后,在doc文件内有相关的pdf使用文档,比较重要的是这份文档:02_Rockchip_RKNPU_User_Guide_RKNN_SDK_V2.0.0beta0_CN.pdf。

    一、 rk3588npu驱动升级

    上面这份文档的2.2节设备NPU环境准备中,会更新RKNN Server和 RKNPU2 Runtime 库,操作是通过adb指令,不方便,可以直接把rknn-toolkit2下载到rk3588里面,然后直接cp指令拷贝升级。

    #升级rknn server
    sudo cp rknpu2/runtime/RK3588/Linux/rknn_server/aarch64/usr/bin/rknn_server  /usr/bin/rknn_server
    sudo cp rknpu2/runtime/RK3588/Linux/rknn_server/aarch64/usr/bin/start_rknn.sh  /usr/bin/start_rknn.sh
    sudo cp rknpu2/runtime/RK3588/Linux/rknn_server/aarch64/usr/bin/restart_rknn.sh  /usr/bin/restart_rknn.sh
    #升级 RKNPU2 Runtime 库
    cp rknpu2/runtime/RK3588/Linux/librknn_api/aarch64/librknnrt.so /usr/lib/librknnrt.so
    #2.0版本没有librknn_api.so,创建一个软连接到librknnrt.so
    sudo ln -s /usr/lib/librknnrt.so /usr/lib/librknn_api.so
    

    npu的driver可以不用升级,我们用的是0.8.2版本,实测发现除了动态shape功能不支持外,暂时没发现其他问题,可以正常跑通yolov5、yolov8。

    二、 运行rknn_model_zoo中的demo

    rknn_model_zoo中的demo模型连板运行时,需要先在rk3588中启动rknn_server

    #在rk3588上执行
    start_rknn.sh
    

    rk3588的adb支持网络模式

    #在x86主机上执行
    adb connect 192.168.0.xxx:5555
    #192.168.0.xxx需要换成实际的rk3588地址
    
    posted in 技术交流
  • RE: Rviz无法打开

    @pec ssh中不能打开图像窗口。除非ssh的时候加上 -X

    posted in 技术交流
  • RE: navtest时显示一直没有tf

    @凉风拂面 底盘串口是不是插错位置了。这个tf是底盘驱动负责的

    posted in ROS教程
  • RE: 使用xiaoqiang_track进行人体跟随和追踪

    @huapiaoxiang21 支持现在应该只支持python3, https://git.bwbot.org/publish/body_pose

    posted in 技术交流
  • netplan导致systemd-networkd-wait-online.service卡住的问题

    如果用netplan控制网络设备,同时把设备设置成固定ip。如果对应的设备不存在,那么在系统启动后systemd-networkd-wait-online.service就会卡住几分钟,导致后续的服务无法执行。

    比如下面的网络设置

    network:
      version: 2
      ethernets:
        enx00e04c680c9b:
          dhcp4: false
          addresses:
            - 192.168.198.1/24
          routes:
            - to: default
              via: 192.168.198.1
              metric: 200
        enx344b50000000:
          dhcp4: true
          dhcp4-overrides:
            route-metric: 90
    

    这样即使enx00e04c680c9b这个网络设备不存在或者enx00e04c680c9b网口上没有插网线systemd-networkd-wait-online.service这个服务也还是会卡住。这是因为netplan默认的后台用的是systemd-network。按照这样设置之后系统图形界面中也是看不到被控制的网卡的。同时由于网络同时受两个后端控制,还可能导致dns错误等问题。

    我们可以让netplan也使用NetworkManager作为后端来解决这个问题。只需要在配置中增加 renderer: NetworkManager

    最后配置如下

    network:
      version: 2
      renderer: NetworkManager
      ethernets:
        enx00e04c680c9b:
          dhcp4: false
          addresses:
            - 192.168.198.1/24
          routes:
            - to: default
              via: 192.168.198.1
              metric: 200
        enx344b50000000:
          dhcp4: true
          dhcp4-overrides:
            route-metric: 90
    

    这样就不会存在卡住的问题。同时网卡也可以在系统网络设置界面中看到。

    posted in 技术交流
  • linux 优化启动速度

    https://wiki.archlinux.org/title/Improving_performance/Boot_process

    Improving the boot performance of a system can provide reduced boot wait times and serves as a means to learn more about how certain system files and scripts interact with one another. This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.

    1 Analyzing the boot process

    1.1 Using systemd-analyze

    systemd provides a tool called systemd-analyze that can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. You can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly.

    To see how much time was spent in kernelspace and userspace on boot, simply use:

    $ systemd-analyze
    

    Tip: If you boot via UEFI and use a boot loader which implements systemd’s Boot Loader Interface (which currently systemd-boot and GRUB do), systemd-analyze can additionally show you how much time was spent in the EFI firmware and the boot loader itself.

    To list the started unit files, sorted by the time each of them took to start up:

    $ systemd-analyze blame
    

    At some points of the boot process, things can not proceed until a given unit succeeds. To see which units find themselves at these critical points in the startup chain, do:

    $ systemd-analyze critical-chain
    

    You can also create an SVG file which describes your boot process graphically, similar to Bootchart:

    $ systemd-analyze plot > plot.svg
    

    See systemd-analyze(1) for details.

    1.2 Using bootchart2

    You could also use Bootchart2 to visualize the boot sequence.

    2 Using systemd instead of busybox on early init

    By default, the Mkinitcpio configuration uses the base and udev hooks for building the initramfs. Faster boot times can be achieved by replacing them with systemd.

    See Mkinitcpio#Common hooks for more details. See also Fsck#Boot time checking if replacing the fsck hook.

    3 Compiling a custom kernel

    Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64-bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. See Kernel#Compilation for more info.

    4 Initramfs

    In a similar approach to #Compiling a custom kernel, the initramfs can be slimmed down. A simple way is to include the mkinitcpio autodetect hook. If you want to go further than that, see Minimal initramfs.

    Depending on your hardware (processor and storage speed), using lz4 instead of the default zstd compression option may be quicker since the faster decompression speed at boot time usually offsets the slightly larger size of the initramfs that has to be read from disk. See Mkinitcpio#COMPRESSION.

    5 Choose the adequate way to start for services

    One central feature of systemd is D-Bus and socket activation. This feature should be preferred for most cases as it causes services to be started only when they are first accessed and is generally a good thing (e.g. having cups.service enabled at boot time is usually not useful for desktop use, enable instead cups.socket which will only start the service when actually printing).

    However, if you know that a service (like upower) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by enabling upower.service.

    This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.

    6 Staggered spin-up

    Some hardware implements staggered spin-up, which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:

    # dmesg | grep SSS
    

    If it was not used during boot, there will be no output.

    To disable it, add the libahci.ignore_sss=1 kernel parameter.

    7. Filesystem mounts

    Thanks to mkinitcpio’s fsck hook, you can avoid a possibly costly remount of the root partition by changing ro to rw on the kernel line: options can be set with rootflags=rw,other_mount_options. The entry must be removed from the /etc/fstab file, otherwise the systemd-remount-fs.service will continue to try applying these settings. Alternatively, one could try to mask that unit.

    If Btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, mkinitcpio’s fsck hook can be removed. You may also want to mask the systemd-fsck-root.service, or tell it not to fsck the root filesystem from the kernel command line using fsck.mode=skip. Without mkinitcpio’s fsck hook, systemd will still fsck any relevant filesystems with the systemd-fsck@.service

    You can also remove API filesystems from /etc/fstab, as systemd will mount them itself (see pacman -Ql systemd | grep ‘.mount$’ for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.

    Other filesystems, like /home or EFI system partition, can be mounted with custom mount units. Adding noauto,x-systemd.automount to mount options will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.

    Note:

    This will make your /home filesystem type autofs, which is ignored by mlocate by default. The speedup of automounting /home may not be more than a second or two, depending on your system, so this trick may not be worth it.

    If the system is installed into a btrfs subvolume (specifically: the root directory / itself is a subvolume) and /home is a separate file system, you may also want to prevent the creation of a /home subvolume. Mask the home.conf tmpfile: ln -s /dev/null /etc/tmpfiles.d/home.conf.

    8. Less output during boot

    For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting. See the Silent boot article for suggestions.

    9. Changing boot loader

    Changing your boot loader (e.g. a simpler boot loader such as systemd-boot) may reduce boot time by seconds.

    If your setup allows it, try using only EFISTUB for even shorter boot times.

    10. Suspend to RAM

    The best way to reduce boot time is not booting at all. Consider suspending your system to RAM instead.

    posted in 技术交流