Waiting for robot_description to be published on robot_description topic

Hi there, I am currently doing my project on ROS2. Here are some of the hardware I am using:
Mecanum base, esp32-WROOM-32 microcontroller, Cytron MDD10A (Generic 1) motor drivers, A2M8 RPLidar, and a raspberry Pi 4B as the main computer.
I have followed the steps in this page exactly up until the "test_acc" part. One small issue that I did encounter was "test_sensors" part. The values are not changing even when I tilt my robot and so on. (But i guess its fine since the Gyro isn't that important for my project).
The main issue that I've been facing for the past 2 weeks was this:
when I run:
ros2 launch linorobot2_bringup bringup.launch.py
or
ros2 launch linorobot2_bringup bringup.launch.py base_serial_port:=/dev/ttyUSB0 lidar_serial_port:=/dev/ttyUSB1 micro_ros_baudrate:=921600
it gives me this in the terminal:

it just waits infinitely for the robot_description to be published on the robot_description topic.
If it helps, this is my urdf file for my robot:
<?xml version="1.0"?>
<robot xmlns:xacro="http://ros.org/wiki/xacro">
  <xacro:property name="base_length" value="0.49" />
  <xacro:property name="base_width" value="0.39" />
  <xacro:property name="base_height" value="0.06" />

  <xacro:property name="wheel_radius" value="0.0723" />
  <xacro:property name="wheel_width" value="0.05" />

  <xacro:property name="laser_pose">
    <origin xyz="-0.0475 0 0.125" rpy="0 0 0"/>
  </xacro:property>

  <material name="grey">
        <color rgba="0.5 0.5 0.5 1" />
    </material>

    <material name="blue">
        <color rgba="0 0 0.5 1" />
    </material>

    <material name="pink">
        <color rgba="1 0.75 0.8 1" />
    </material>

    <!-- base_footprint (projection of base_link on the ground) -->

    <link name="base_footprint"/>

    <joint name="base_joint" type="fixed">
        <parent link="base_footprint"/>
        <child link="base_link"/>
        <origin xyz="0 0 0.2" rpy="0 0 0"/>
    </joint>

    <!-- base_link and base_scan (required for Nav2) -->

    <link name="base_link">
        <visual>
            <geometry>
                <box size="${base_length} ${base_width} ${base_height}" />
            </geometry>
            <origin xyz="0 0 0" rpy="0 0 0" />
            <material name="blue" />
        </visual>
    </link>

    <joint name="base_scan_joint" type="fixed">
        <parent link="base_link"/>
        <child link="base_scan"/>
        <origin xyz="0 0 0.06" rpy="0 0 0"/>
    </joint>

    <link name="base_scan">
        <visual>
            <geometry>
                <cylinder radius="0.0375" length="0.04"/>
            </geometry>
            <origin xyz="0 0 0.04" rpy="0 0 0" />
            <material name="pink" />
        </visual>
    </link>

    <!-- Wheels (4 mecanum wheels) -->

    <joint name="base_left_back_wheel_joint" type="continuous">
        <parent link="base_link"/>
        <child link="left_back_wheel"/>
        <origin xyz="-0.22 0.225 -0.01" rpy="0 0 0"/>
        <axis xyz="0 1 0"/>
    </joint>

    <link name="left_back_wheel">
        <visual>
            <geometry>
                <cylinder radius="${wheel_radius}" length="${wheel_width}"/>
            </geometry>
            <origin xyz="0 0 0" rpy="1.57 0 0" />
            <material name="grey" />
        </visual>
    </link>

    <joint name="base_right_back_wheel_joint" type="continuous">
        <parent link="base_link"/>
        <child link="right_back_wheel"/>
        <origin xyz="-0.22 -0.225 -0.01" rpy="0 0 0"/>
        <axis xyz="0 1 0"/>
    </joint>

    <link name="right_back_wheel">
        <visual>
            <geometry>
                <cylinder radius="0.05" length="0.0723"/>
            </geometry>
            <origin xyz="0 0 0" rpy="1.57 0 0" />
            <material name="grey" />
        </visual>
    </link>

    <joint name="base_left_front_wheel_joint" type="continuous">
        <parent link="base_link"/>
        <child link="left_front_wheel"/>
        <origin xyz="0.22 0.225 -0.01" rpy="0 0 0"/>
        <axis xyz="0 1 0"/>
    </joint>

    <link name="left_front_wheel">
        <visual>
            <geometry>
                <cylinder radius="0.05" length="0.0723"/>
            </geometry>
            <origin xyz="0 0 0" rpy="1.57 0 0" />
            <material name="grey" />
        </visual>
    </link>

    <joint name="base_right_front_wheel_joint" type="continuous">
        <parent link="base_link"/>
        <child link="right_front_wheel"/>
        <origin xyz="0.22 -0.225 -0.01" rpy="0 0 0"/>
        <axis xyz="0 1 0"/>
    </joint>

    <link name="right_front_wheel">
        <visual>
            <geometry>
                <cylinder radius="0.05" length="0.0723"/>
            </geometry>
            <origin xyz="0 0 0" rpy="1.57 0 0" />
            <material name="grey" />
        </visual>
    </link>

</robot>

Any help to solve this issue is much appreciated, Thank youu!

Both esp32 and lidar use the same device names as /dev/ttyUSBx, 0 or 1. It is very easy to mixed up. Disconnect the lidar first. Only the esp32 is connected.
Please run the micro-ROS agent connection test. https://github.com/hippo5329/linorobot2_hardware/wiki#esp32-with-micro-ros-serial-transport
imu is not enabled by default in esp32_config.h. Which imu do you use? You will need to uncomment the line, eg, #define USE_MPU6050_IMU. You should see the i2cdetect. https://github.com/hippo5329/linorobot2_hardware/wiki#i2cdetect-debug-message . And the imu reading in test_sensors should change as you move. You should also see the /imu/data topic changing in step 2.
gyro is important. Ekf filter will fuse the wheel odometry and yaw from imu.
You should install the linorobot2 with "a2", which is for rplidar a2. eg. bash install_linorobot2.bash 2wd a2
You will need the by-path names to specify which serial port is esp32 and lidar. https://github.com/hippo5329/linorobot2_hardware/wiki#esp32-with-serial-transport-and-ld19-lidar
In the bring up messages, you should see many messages from "micro ros agent", "joint state publisher", "robot state publisher" and rplidar. In your photo, the micro-ros agent is not connected yet and the lidar did not start.

https://github.com/hippo5329/linorobot2_hardware/wiki#esp32-with-serial-transport-and-lidar-on-the-robot-computer

I added more details on micro-ros agent connection test and bringup launch. Please check the wiki.

Hi again, I am quite new to ROS so there are quite a few things that I am still unfamiliar with. For the past day, I have been trying to do step 2 and this is the output I am getting.

The open device errors are due to me unplugging the esp and plugging it back in.
I didn't face this problem before I started the changes at https://github.com/hippo5329/linorobot2_hardware/wiki#custom-configuration-file---recommended
I am quite unsure on how to proceed now.

No worries. I am new to ROS2 and I keep learning, too.
Please follow my suggested work flow. In another directory, clone my fork again. Follow this,
https://github.com/hippo5329/linorobot2_hardware/wiki#install-firmware-source
Do not change the source. Build, upload and test connection.
https://github.com/hippo5329/linorobot2_hardware/wiki#esp32-with-micro-ros-serial-transport

The access mode of ttyUSB0 might be wrong. You might miss the step,
Install PlatformIO udev rules.
curl -fsSL https://raw.githubusercontent.com/platformio/platformio-core/develop/platformio/assets/system/99-platformio-udev.rules | sudo tee /etc/udev/rules.d/99-platformio-udev.rules
sudo service udev restart
sudo usermod -a -G dialout $USER
sudo usermod -a -G plugdev $USER
Then unplug and plug esp32.
$ ls /dev/ttyU* -l
crw-rw-rw- 1 root dialout 188, 0 May 29 15:22 /dev/ttyUSB0

So, I've tried doing everything from scratch again and I've passed the connection test here: https://github.com/hippo5329/linorobot2_hardware/wiki#esp32-with-micro-ros-serial-transport
And now, I am currently doing step 3 in your earlier comment: https://github.com/hippo5329/linorobot2_hardware/issues/15#issuecomment-2133987557
This is the output I am getting:

(I've tried changing the baudrate because I've encountered similar problems in earlier projects related to Arduino.)
Is there any way I can complete this project without implementing the IMU?

Good. Please tell me which IMU you use. And show me the configuration of your IMU. The micro-ROS middle ware is running on the serial. So you will see random chars because the communication is binary, not ascii code. Keep the baud rate at 921600. You will need to press reset button on the esp32 to see the messages right after boot.

You should run the test_sensors. There is no micro-ros protocol in test_sensors. Press reset button on the esp32 to see the boot message.

I am using an MPU6050. My IMU is connected to an Arduino 5V and GND for the time being, and the SDA and SCL are connected to pins 21 and 22 of my ESP respectively.

Why Arduino? Connect 5V to 5V on esp32 module.

Connect 5V of MPU6050 to 5V on esp32.  Connect gnd of MPU6050 to gnd on esp32.

Sorry but I dont actually have a 5V pin on my ESP. I am using this dev board: https://i0.wp.com/circuits4you.com/wp-content/uploads/2018/12/ESP32-Pinout.jpg?resize=604%2C373&ssl=1

Please check with a multimeter the Vin of esp32. If you see 5-4.5V, then use the Vin. Otherwise use 3.3V output of esp32.

There is a LDO 3.3V on the GY521. The MPU6050 chip uses 3.3V. It is fine.

I've connected all the relevant pins as you instructed in previous comments. 5V and GND of IMU to Vin and GND of ESP.
Running "test_sensors" gives me the same output - random characters.

pio device monitor -e esp32 -b 921600

I've tried defining the baudrate for earlier comments too. Same, using "-b 921600" but the outputs are the same. Same case for this "test_sensors" command.

I'm really not sure why is it outputting these characters. I had no such issues earlier, even when running "test_motors", "test_sensors", and "test_acc".

cd test_motors
pio run -e esp32 -t upload
pio device monitor -e esp32
Test with a bare esp32 like yours. I will add a mpu6050 later.

Sorry but what does this error mean?
bash: /home/leesanhang/.platformio/penv/bin/pio: No such file or directory

It might be link. It is not important. Rebuild and test again.

Oh, I deleted pio. Need to reinstall platformio.
curl -fsSL -o get-platformio.py https://raw.githubusercontent.com/platformio/platformio-core-installer/master/get-platformio.py
python3 get-platformio.py

Yup, I just realised platformio was deleted. Got it, I reinstalled and I am trying to build now.

with mpu9250, and press reset button.

How about test_sensors? Press reset button to see the the message.

check, ls /dev/ttyU* -l

Try another usb cable.

I actually just tried and restart it a few times and now it works (weirdly).  The use the same serial port. Only one at a time.

So I tried building and testing some of the commands.
Running
cd firmware pio run -e myrobot
for https://github.com/hippo5329/linorobot2_hardware/wiki#i2cdetect-debug-message
Gives me:

and
Running
cd test_motors pio run -e myrobot -t upload pio device monitor -e myrobot
for https://github.com/hippo5329/linorobot2_hardware/wiki#test-the-motors-and-encoders
Gives me:

One more thing I'm curios is that, it takes me very long to build, roughly 15 mins where it will be "Building micro-ROS library".

Do you use ubuntu alone or are you using ubuntu inside windows? How about test_sensors? Press reset button to see the the message.

I use ubuntu 22.04 in my Raspberry Pi 4B 4GB.

One more update before logging off for a few hours:
I went ahead and checked some of the src folders, in the firmware.cpp file, for example: the firmware.cpp folder in test_motors. I realised that the baudrates are set to 115200. I changed it to 921600 and this is the output that I am getting:

Exact same outputs when I run the test_motors commands and the IMU checking commands. The 68 appears when I press the reset button on my ESP.

I figured I should show you this too:

The values aren't changing even when I'm moving the gyro around. Oh yes, and I tried changing the baudrate to 921600 for test_sensors as well.

please uncomment the line #define USE_MPU6050_IMU to enable mpu6050

env [esp32] use esp32_config.h, pio run -e esp32 -t upload
env [myrobot] use myrobot_config.h, pio run -e myrobot -t upload
don't mix up

I updated the workflow in wiki to avoid the trouble to create custom configuration file for beginners.

Please post photos of your esp32 and wiring.

Hi again, I've been looking around in the linorobot2_hardware folder.
I narrowed the micro-ROS connection issue down to this:
In the /config/custom/esp32config.h file and the /config/lino_base_config.h file, I replaced the following lines to this:
`//define your robot' specs here
#define MOTOR_MAX_RPM 222                   // motor's max RPM
#define MAX_RPM_RATIO 1.0                  // max RPM allowed for each MAX_RPM_ALLOWED = MOTOR_MAX_RPM * MAX_RPM_RATIO
#define MOTOR_OPERATING_VOLTAGE 24          // motor's operating voltage (used to calculate max RPM)
#define MOTOR_POWER_MAX_VOLTAGE 24          // max voltage of the motor's power source (used to calculate max RPM)
#define MOTOR_POWER_MEASURED_VOLTAGE 22     // current voltage reading of the power connected to the motor (used for calibration)
#define COUNTS_PER_REV1 19308                 // wheel1 encoder's no of ticks per rev
#define COUNTS_PER_REV2 26823                 // wheel2 encoder's no of ticks per rev
#define COUNTS_PER_REV3 26742                 // wheel3 encoder's no of ticks per rev
#define COUNTS_PER_REV4 26837                 // wheel4 encoder's no of ticks per rev
#define WHEEL_DIAMETER 0.1               // wheel's diameter in meters
#define LR_WHEELS_DISTANCE 0.5            // distance between left and right wheels
#define PWM_BITS 10                         // PWM Resolution of the microcontroller
#define PWM_FREQUENCY 20000                 // PWM Frequency
#define SERVO_BITS 12                       // Servo PWM resolution
#define SERVO_FREQ 50                       // Servo PWM frequency
// INVERT ENCODER COUNTS
#define MOTOR1_ENCODER_INV false
#define MOTOR2_ENCODER_INV true
#define MOTOR3_ENCODER_INV false
#define MOTOR4_ENCODER_INV true
// INVERT MOTOR DIRECTIONS
#define MOTOR1_INV true
#define MOTOR2_INV true
#define MOTOR3_INV true
#define MOTOR4_INV true
// ENCODER PINS
#define MOTOR1_ENCODER_A 23
#define MOTOR1_ENCODER_B 4
#define MOTOR2_ENCODER_A 15
#define MOTOR2_ENCODER_B 19
#define MOTOR3_ENCODER_A 18
#define MOTOR3_ENCODER_B 5
#define MOTOR4_ENCODER_A 17
#define MOTOR4_ENCODER_B 16
// MOTOR PINS
#ifdef USE_GENERIC_2_IN_MOTOR_DRIVER
#define MOTOR1_PWM 21 //Pin no 21 is not a PWM pin on Teensy 4.x, you can swap it with pin no 1 instead.
#define MOTOR1_IN_A 20
#define MOTOR1_IN_B 1
#define MOTOR2_PWM 5
#define MOTOR2_IN_A 6
#define MOTOR2_IN_B 8
#define MOTOR3_PWM 22
#define MOTOR3_IN_A 23
#define MOTOR3_IN_B 0
#define MOTOR4_PWM 4
#define MOTOR4_IN_A 3
#define MOTOR4_IN_B 2
#define PWM_MAX pow(2, PWM_BITS) - 1
#define PWM_MIN -PWM_MAX
#endif
#ifdef USE_GENERIC_1_IN_MOTOR_DRIVER
#define MOTOR1_PWM 32 //Pin no 21 is not a PWM pin on Teensy 4.x, you can use pin no 1 instead.
#define MOTOR1_IN_A 2
#define MOTOR1_IN_B -1 //DON'T TOUCH THIS! This is just a placeholder
#define MOTOR2_PWM 25
#define MOTOR2_IN_A 26
#define MOTOR2_IN_B -1 //DON'T TOUCH THIS! This is just a placeholder
#define MOTOR3_PWM 27
#define MOTOR3_IN_A 14
#define MOTOR3_IN_B -1 //DON'T TOUCH THIS! This is just a placeholder
#define MOTOR4_PWM 12
#define MOTOR4_IN_A 13
#define MOTOR4_IN_B -1 //DON'T TOUCH THIS! This is just a placeholder
#define PWM_MAX pow(2, PWM_BITS) - 1
#define PWM_MIN -PWM_MAX
#endif
`
Initially, pin2 was supposed to be assigned pin33 but then I saw 33 was used for the battery. So i temporarily changed it to pin2. But the issues remained the same. micro-ROS connection was not complete.
When I changed the corresponding lines back to what it was initially, micro-ROS connection is successful after building.

The lino_base_config.h is NOT used for esp32. Only esp32_config.h will be used. Use the original esp32_config.h. uncomment the line #define USE_MPU6050_IMU to enable mpu6050. Do not change any other lines in esp32_config.h. Follow the update workflow. Connect the mpu6050 and run test_sensors. Post the photos of your wiring.

The pins assignment of esp32 is totally different from teensy. Do not use the wiring for teensy,

Only 2 pwm pins mode is valid in current esp32_config.h . The other motor configurations is not valid. I will update generic 1 pin assignments later.

so actually, I should follow the wiring provided in the esp32_config file?

Correct me if im wrong, but the ESP32 has no Pin 0 right?

I changed the motor interface pin assignments. It should work though I didn't test them yet. I ordered generic 1 similar to the cytron to test.

You are right. esp32 30 pins version does not have d0. I push another update for motor pins. please pull again. Then perform the tests.
git pull

Hi again, I'm trying to follow your steps closely for now. However, I am facing an issue. Every time I shut down my Pi and come back the next day, micro-ROS will just magically not work. Do you maybe have an idea on why this is happening?

What is the error message  from micro-ROS agent? Check 'ls /dev/ttyU* -l" to the the access. Which micro-SD you use? Write speed of the memory card is important.

I mean, it just doesnt connect fully as usual. However, I just realised what the problem is.
There are a few parts to your steps: serial connection test, test sensors, test motors, and test acceleration right?
Starting from test sensors, I uncomment the MPU6050 line. That's when the connection is not complete when I run ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyUSB0 --baudrate 921600 . Is that normal?

I think the MPU might be the main problem in my case.
This is when MPU is commented out, while doing https://github.com/hippo5329/linorobot2_hardware/wiki#connect-micro-ros-agent-again-and-check-imudata-topic

This is when MPU is uncommented, doing the same steps

Hope this helps with helping me find out what my problem is 🙏🏼🙏🏼🙏🏼

Please uncomment the mpu6050 to enable IMU and run test_sensors. Press reset button to see the messages of i2cdetect.

https://github.com/hippo5329/linorobot2_hardware/wiki#connect-the-imu-and-test_sensors

If you have run this step, does the IMU reading correct in test_sensors?

In your previous message, micro-ros2 agent can not connect because the esp32 stopped when the IMU init failed. You should see the LED blinks 3 times per sec.

I ran the test_sensors commands and this is what i got.

The random characters are due to pressing the ESP reset button.
Yes, the LED blinks thrice if micro-ROS connection failed.

The IMU looks good in test_sensors.
Now, upload firmware and check the monitor . Press reset button to see the messages.
cd firmware
pio run -e esp32 -t upload
pio device monitor -e esp32

The reading of IMU changed too much. Do not move the IMU and check test_sensors later. The reading should be close to 0,0,9.8 with normal stand.
We will check the firmware boot monitor message first.

This is when I ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyUSB0 --baudrate 921600

I did not touch the IMU. Not sure why the values are fluctuating about those values.

The message you just posted is topic echo /imu/data on another terminal. esp32 is connected to agent and the /imu/data topic looks fine.

Post the photos of wiring of your esp32 board wiring and mpu6050.

The imu will do self calibration. It will take a few seconds.

Here is the temporary wiring. I have not switched to a full scale wiring since the wiring will be messy if I include the encoders and motor drivers.

Blue: ESP Vin -> MPU Vcc
Purple: ESP GND -> MPU GND
White: ESP SCL(22) - > MPU SCL
Grey: ESP SDA(21) -> MPU SDA

We run the i2c at 400Khz. The 2k pull up on sda scl are required at this speed. Otherwise, i2c communication will be unstable. You may reduce the i2c speed tp 100Khz temporarily if there is no pull up.
In esp32_config.h
#define BOARD_INIT {
Wire.begin(SDA_PIN, SCL_PIN);
Wire.setClock(400000);
}
change 400000 to 100000 for 100Khz.

Would this be okay? I connected the SDA and SCL pins through a 2k resistance before passing it to the MPU.

Wrong.
I should draw a schematic.

Okay, but yea I understand my mistake. I interpreted "pull up" wrongly. My bad.

How about this?

Black (Top) is from 3v3
orange and yellow is from SDA SCL of the ESP respectively
Grey and white (bottom 2 wires) are to SDA and SCL of MPU respectively

The value of pull up resisters does not have to be exact 2K. something around 2-2.2k will work. What are the resisters you have? If you have 1K, then put two 1K in series to get 2K.

Anyways. Your previous wiring might work. Try out.

Is this good? they're 1k resistors each.

Good. It  should work.

This is my output now.

Look good.

I'll continue with test_motors now.

The reading of the IMU looks good. Minor noise.

I just wanted to ask if GPIO pins 36 and 39 needs to be pulled high as well? Because I remember faintly that I did see that somewhere. Im asking this because I dont think Motor 1's encoder info is going to the ESP.

no

take photo motor and encoder

This is my motor, with the default encoder. The motor is rated 24V, 6000rpm, with a 1:27 reducer. The encoder is the GMR type.

Please post the detail of the motor and encoder.

spec / datasheet

encoder:  red to 3.3V  black gnd white A green B
You should add a LM1117-3.3V LDO for the encoder. Do not use 3V3 of esp32, because the motor wiring is very noisy.
LM1117 Vin = esp32 Vin 5V, gnd = gnd, Vout 3.3V to encoder Vcc

Hope this is good.

I changed the whole motor itself and it works now.

I'm getting this warning, what does the warning mean? I followed your steps, connecting the esp then only Lidar.

The by-path were mine. You will need to use your by-path.

I can't seem to get past this step always.

Try connection dev with by-path
ros2 run micro_ros_agent micro_ros_agent serial --dev     --baudrate 921600

I didn't see your rplidar node.
cat ~/.bashrc
Please use copy & paste of your screen message. Do not use screen capture. It is difficult for me to check. My eyes are not so good.

what is the lidar model? rplidar A2?

I want to know the installed packages in workspace.
ls linorobot2_ws/src

This is my .bashrc file:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    i) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	# We have color support; assume it's compliant with Ecma-48
	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
	# a case would tend to support setf rather than setaf.)
	color_prompt=yes
    else
	color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi

export LINOROBOT2_BASE=mecanum
source /opt/ros/humble/setup.bash
source ~/ros2_ws/install/setup.bash
source /usr/share/colcon_argcomplete/hook/colcon-argcomplete.bash

PATH="$PATH:$HOME/.platformio/penv/bin"

Yes, my rplidar model is A2M8
In linorobot2_ws/src/ , I have micro_ros_setup, ros2.repos and uros
When I run ros2 run micro_ros_agent micro_ros_agent serial --dev your- by-path --baudrate 921600
It says serial port not found ... error 2, waiting for connection...

Im not sure if this helps:
leesanhang@Pi4B:/tmp$ wget https://github.com/hippo5329/linorobot2/raw/humble/install_linorobot2.bash
--2024-05-31 13:46:06--  https://github.com/hippo5329/linorobot2/raw/humble/install_linorobot2.bash
Resolving github.com (github.com)... <IP_ADDRESS>
Connecting to github.com (github.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/hippo5329/linorobot2/humble/install_linorobot2.bash [following]
--2024-05-31 13:46:07--  https://raw.githubusercontent.com/hippo5329/linorobot2/humble/install_linorobot2.bash
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11334 (11K) [text/plain]
Saving to: ‘install_linorobot2.bash’

install_linorobot2.bash   100%[==================================>]  11.07K  --.-KB/s    in 0.005s

2024-05-31 13:46:07 (2.24 MB/s) - ‘install_linorobot2.bash’ saved [11334/11334]

leesanhang@Pi4B:/tmp$ bash install_linorobot2.bash mecanum a2

You are installing linorobot2 on your robot computer.

===========SUMMARY============
ROBOT TYPE   : mecanum
LASER SENSOR : a2
DEPTH SENSOR :

This installer will edit your ~/.bashrc.
Create a linorobot2_ws on your /home/leesanhang directory.
Install linorobot2 ROS2 dependencies.
Install udev rules on /etc/udev/rules.d folder.
Enter [y] to continue. y

INSTALLING NOW....

Starting >>> micro_ros_msgs
Starting >>> linorobot2
Starting >>> linorobot2_base
Starting >>> linorobot2_description
--- stderr: linorobot2
CMake Error: The source directory "/home/leesanhang/linorobot2_ws/linorobot2/linorobot2" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
gmake: *** [Makefile:226: cmake_check_build_system] Error 1
---
Failed   <<< linorobot2 [0.71s, exited with code 2]
Aborted  <<< linorobot2_base [0.69s]
Aborted  <<< linorobot2_description [0.66s]
Aborted  <<< micro_ros_msgs [2.46s]

Summary: 0 packages finished [3.94s]
  1 package failed: linorobot2
  3 packages aborted: linorobot2_base linorobot2_description micro_ros_msgs
  3 packages had stderr output: linorobot2 linorobot2_base linorobot2_description
  6 packages not processed

You need to use your by-path of ttyUSB0.  Try to install it again.
cd /tmp
rm -rf ~/linorobot2_ws
bash install_linorobot2.bash mecanum a2

Yea I thought it was abit odd when the sllidar folder was not in src. But I didn't dare to just change its location.
Sure, I will test the launch file with my A2 when you're done 🙏🙏 Thank you.

Remember, when I refer
by-path, it means the long by-path device names on your machine.
Pull-up means adding a resistor from the signal to vcc.   dio - R - vcc. usually R is 2K or 4.7K depended on requirement.
Pull-down means adding a resistor from the signal to gnd. dio - R - gnd. usually R is 10K.
Series termination means adding a resistor from the signal to outside to improve signal integrity. dio -R - outside. usually R is 10,22,33 or 110 Ohm depends on system requirement.

pull-up 4.7K for 5V, 2K for 3.3V

Please try the updated linorobot2 installation  script.
rm /tmp/install*
rm -rf ~/linorobot2_ws
source /opt/ros/humble/setup.bash
cd /tmp
wget https://github.com/hippo5329/linorobot2/raw/humble/install_linorobot2.bash
bash install_linorobot2.bash mecanum a2m8
source ~/.bashrc

This is my output:
**leesanhang@Pi4B:~$** ros2 launch linorobot2_bringup bringup.launch.py     base_serial_port:=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0     lidar_serial_port:=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0
[INFO] [launch]: All log files can be found below /home/leesanhang/.ros/log/2024-05-31-06-25-44-893068-Pi4B-6550
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [ekf_node-1]: process started with pid [6562]
[INFO] [micro_ros_agent-2]: process started with pid [6564]
[INFO] [joint_state_publisher-3]: process started with pid [6566]
[INFO] [robot_state_publisher-4]: process started with pid [6568]
[INFO] [sllidar_node-5]: process started with pid [6570]
[micro_ros_agent-2] [1717107951.799384] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[micro_ros_agent-2] [1717107951.802674] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4
[sllidar_node-5] [INFO] [1717107952.020719898] [sllidar_node]: SLLidar running on ROS2 package SLLidar.ROS2 SDK Version:1.0.1, SLLIDAR SDK Version:2.1.0
[sllidar_node-5] [INFO] [1717107952.047076454] [sllidar_node]: SLLidar S/N: 6BE69A86C0E09CC7A2E09DF7F9343077
[sllidar_node-5] [INFO] [1717107952.047263009] [sllidar_node]: Firmware Ver: 1.25
[sllidar_node-5] [INFO] [1717107952.047308621] [sllidar_node]: Hardware Rev: 5
[sllidar_node-5] [INFO] [1717107952.050089602] [sllidar_node]: SLLidar health status : 0
[sllidar_node-5] [INFO] [1717107952.050255306] [sllidar_node]: SLLidar health status : OK.
[robot_state_publisher-4] [INFO] [1717107952.087315732] [robot_state_publisher]: got segment base_footprint
[robot_state_publisher-4] [INFO] [1717107952.089622732] [robot_state_publisher]: got segment base_link
[robot_state_publisher-4] [INFO] [1717107952.089757639] [robot_state_publisher]: got segment camera_depth_link
[robot_state_publisher-4] [INFO] [1717107952.089803639] [robot_state_publisher]: got segment camera_link
[robot_state_publisher-4] [INFO] [1717107952.089834343] [robot_state_publisher]: got segment front_left_wheel_link
[robot_state_publisher-4] [INFO] [1717107952.089861806] [robot_state_publisher]: got segment front_right_wheel_link
[robot_state_publisher-4] [INFO] [1717107952.089887935] [robot_state_publisher]: got segment imu_link
[robot_state_publisher-4] [INFO] [1717107952.089913602] [robot_state_publisher]: got segment laser
[robot_state_publisher-4] [INFO] [1717107952.089939121] [robot_state_publisher]: got segment rear_left_wheel_link
[robot_state_publisher-4] [INFO] [1717107952.089965380] [robot_state_publisher]: got segment rear_right_wheel_link
[micro_ros_agent-2] [1717107952.334793] info     | Root.cpp           | create_client            | create                 | client_key: 0x3889E978, session_id: 0x81
[micro_ros_agent-2] [1717107952.334996] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x3889E978, address: 0
[sllidar_node-5] [INFO] [1717107952.390682731] [sllidar_node]: current scan mode: Express, sample rate: 4 Khz, max_distance: 12.0 m, scan frequency:10.0 Hz,
[micro_ros_agent-2] [1717107952.427383] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x3889E978, participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.446727] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x3889E978, topic_id: 0x000(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.453512] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x3889E978, publisher_id: 0x000(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.476448] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x3889E978, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[micro_ros_agent-2] [1717107952.483331] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x3889E978, topic_id: 0x001(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.488012] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x3889E978, publisher_id: 0x001(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.509029] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x3889E978, datawriter_id: 0x001(5), publisher_id: 0x001(3)
[micro_ros_agent-2] [1717107952.514478] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x3889E978, topic_id: 0x002(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.519086] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x3889E978, publisher_id: 0x002(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.536609] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x3889E978, datawriter_id: 0x002(5), publisher_id: 0x002(3)
[micro_ros_agent-2] [1717107952.547916] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x3889E978, topic_id: 0x003(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.554708] info     | ProxyClient.cpp    | create_subscriber        | subscriber created     | client_key: 0x3889E978, subscriber_id: 0x000(4), participant_id: 0x000(1)
[micro_ros_agent-2] [1717107952.570184] info     | ProxyClient.cpp    | create_datareader        | datareader created     | client_key: 0x3889E978, datareader_id: 0x000(6), subscriber_id: 0x000(4)
[joint_state_publisher-3] [INFO] [1717107953.520680509] [joint_state_publisher]: Waiting for robot_description to be published on the robot_description topic...
^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT)
[robot_state_publisher-4] [INFO] [1717107956.212791896] [rclcpp]: signal_handler(signum=2)
[ERROR] [micro_ros_agent-2]: process has died [pid 6564, exit code -2, cmd '/home/leesanhang/linorobot2_ws/install/micro_ros_agent/lib/micro_ros_agent/micro_ros_agent serial --dev /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0 --baudrate 921600 --ros-args -r __node:=micro_ros_agent'].
[ekf_node-1] [INFO] [1717107956.213465822] [rclcpp]: signal_handler(signum=2)
[sllidar_node-5] [INFO] [1717107956.389013859] [sllidar_node]: Stop motor
[INFO] [robot_state_publisher-4]: process has finished cleanly [pid 6568]
[INFO] [ekf_node-1]: process has finished cleanly [pid 6562]
[INFO] [sllidar_node-5]: process has finished cleanly [pid 6570]
[INFO] [joint_state_publisher-3]: process has finished cleanly [pid 6566]

Everything seems to be running well, with the teleop too.
These are my topics and nodes:
leesanhang@Pi4B:~$ ros2 node list
/ekf_filter_node
/esp32
/joint_state_publisher
/robot_state_publisher
/sllidar_node
/transform_listener_impl_aaaadeaf7ec0
leesanhang@Pi4B:~$ ros2 topic list
/battery
/cmd_vel
/diagnostics
/imu/data
/joint_states
/odom
/odom/unfiltered
/parameter_events
/robot_description
/rosout
/scan
/set_pose
/tf
/tf_static

good. check these,
ros2 topic hz /imu/data
ros2 topic hz /odom
ros2 topic hz /scan

The hz should be close to 10. Then you may proceed to slam, save the map and navigation with the map.

You will need to update the velocity smoother for mecanum drive.
https://github.com/hippo5329/linorobot2_hardware/wiki#velocity-smoother

Hi again, yesterday, everything was doing fine. Both hardware and software wise. Then I removed all the wirings to swap out the faulty motor. When I rewired it today (exactly same way), and ran the software part again, it was okay but when I tried moving the robot motors, it's vibrating front and back, jerking the whole robot. Do you maybe know what is the problem?

I would suggest test_motors and test_acc to diagnosis the problem. You must have enough space to run test_acc on the groud.

So I took your advice and ran test_motors and test_acc. Everything was doing fine. When I do the ros2 launch bring up command, and then use the teleop to move the robot, motor 1 is giving very weird outputs. For example, it can only turn in 1 direction and once it starts, it doesn't stop. When I pull out the encoder for motor 1, everything is okay, or at least much better.

This is the weird thing about the motor. I used a detached motor for a better visualization.
Uploading WhatsApp Video 2024-06-06 at 04.23.36_41da4a00.mp4…

Please take a picture of the robot to see four wheels. The Mecanum wheels must be installed correctly. Front wheels pair and back wheels pair are different.
Please correct the motor polarity and run test_motors / test_acc. In test_motors, the wheels do not touch ground. But in test_acc, the robot needs to be on the ground. The robot will move very fast. Be very careful. The robot will move forward and backward. Rotate counterclockwise and clockwise.
Can you post the video on youtube?

The problem was the polarity.
However, I am facing a micro-ROS issue now and I'm hoping to get some guidance on this.
This is when I run the robot bringup command.
leesanhang@Pi4B:~$ ros2 launch linorobot2_bringup bringup.launch.py     base_serial_port:=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2:1.0-port0     lidar_serial_port:=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0
[INFO] [launch]: All log files can be found below /home/leesanhang/.ros/log/2024-05-31-05-35-05-279499-Pi4B-4745
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [ekf_node-1]: process started with pid [4813]
[INFO] [micro_ros_agent-2]: process started with pid [4815]
[INFO] [joint_state_publisher-3]: process started with pid [4817]
[INFO] [robot_state_publisher-4]: process started with pid [4820]
[INFO] [sllidar_node-5]: process started with pid [4827]
[micro_ros_agent-2] [1717104913.972887] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[micro_ros_agent-2] [1717104913.973905] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4
[micro_ros_agent-2] [1717104914.182600] info     | Root.cpp           | create_client            | create                 | client_key: 0x604407F2, session_id: 0x81
[micro_ros_agent-2] [1717104914.182787] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x604407F2, address: 0
[robot_state_publisher-4] [INFO] [1717104914.457506579] [robot_state_publisher]: got segment base_footprint
[robot_state_publisher-4] [INFO] [1717104914.457979727] [robot_state_publisher]: got segment base_link
[robot_state_publisher-4] [INFO] [1717104914.458082561] [robot_state_publisher]: got segment camera_depth_link
[robot_state_publisher-4] [INFO] [1717104914.458122487] [robot_state_publisher]: got segment camera_link
[robot_state_publisher-4] [INFO] [1717104914.458151116] [robot_state_publisher]: got segment front_left_wheel_link
[robot_state_publisher-4] [INFO] [1717104914.458178802] [robot_state_publisher]: got segment front_right_wheel_link
[robot_state_publisher-4] [INFO] [1717104914.458307857] [robot_state_publisher]: got segment imu_link
[robot_state_publisher-4] [INFO] [1717104914.458351857] [robot_state_publisher]: got segment laser
[robot_state_publisher-4] [INFO] [1717104914.458382746] [robot_state_publisher]: got segment rear_left_wheel_link
[robot_state_publisher-4] [INFO] [1717104914.458412209] [robot_state_publisher]: got segment rear_right_wheel_link
[micro_ros_agent-2] [1717104914.466890] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x604407F2, participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.498531] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x000(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.514749] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x604407F2, publisher_id: 0x000(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.530972] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x604407F2, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[sllidar_node-5] [INFO] [1717104914.541342727] [sllidar_node]: SLLidar running on ROS2 package SLLidar.ROS2 SDK Version:1.0.1, SLLIDAR SDK Version:2.1.0
[micro_ros_agent-2] [1717104914.547264] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x001(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.558755] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x604407F2, publisher_id: 0x001(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.566465] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x604407F2, datawriter_id: 0x001(5), publisher_id: 0x001(3)
[micro_ros_agent-2] [1717104914.576680] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x002(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.590002] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x604407F2, publisher_id: 0x002(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.610584] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x604407F2, datawriter_id: 0x002(5), publisher_id: 0x002(3)
[micro_ros_agent-2] [1717104914.615586] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x003(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.621520] info     | ProxyClient.cpp    | create_subscriber        | subscriber created     | client_key: 0x604407F2, subscriber_id: 0x000(4), participant_id: 0x000(1)
[sllidar_node-5] [INFO] [1717104914.625870875] [sllidar_node]: SLLidar S/N: 6BE69A86C0E09CC7A2E09DF7F9343077
[sllidar_node-5] [INFO] [1717104914.626406875] [sllidar_node]: Firmware Ver: 1.25
[sllidar_node-5] [INFO] [1717104914.626509357] [sllidar_node]: Hardware Rev: 5
[sllidar_node-5] [INFO] [1717104914.633722320] [sllidar_node]: SLLidar health status : 0
[sllidar_node-5] [INFO] [1717104914.633914061] [sllidar_node]: SLLidar health status : OK.
[micro_ros_agent-2] [1717104914.674358] info     | ProxyClient.cpp    | create_datareader        | datareader created     | client_key: 0x604407F2, datareader_id: 0x000(6), subscriber_id: 0x000(4)
[sllidar_node-5] [INFO] [1717104914.984629783] [sllidar_node]: current scan mode: Express, sample rate: 4 Khz, max_distance: 12.0 m, scan frequency:10.0 Hz,
[joint_state_publisher-3] [INFO] [1717104916.308042356] [joint_state_publisher]: Waiting for robot_description to be published on the robot_description topic...
[micro_ros_agent-2] [1717104930.907725] info     | Root.cpp           | delete_client            | delete                 | client_key: 0x604407F2
[micro_ros_agent-2] [1717104930.909726] info     | SessionManager.hpp | destroy_session          | session closed         | client_key: 0x604407F2, address: 0
[micro_ros_agent-2] [1717104930.938645] info     | Root.cpp           | create_client            | create                 | client_key: 0x57A4A9FF, session_id: 0x81
[micro_ros_agent-2] [1717104930.938714] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x57A4A9FF, address: 0
[micro_ros_agent-2] [1717104931.010435] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x57A4A9FF, participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.015549] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x000(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.019623] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x57A4A9FF, publisher_id: 0x000(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.026763] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x57A4A9FF, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[micro_ros_agent-2] [1717104931.031753] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x001(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.036422] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x57A4A9FF, publisher_id: 0x001(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.042683] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x57A4A9FF, datawriter_id: 0x001(5), publisher_id: 0x001(3)
[micro_ros_agent-2] [1717104931.048564] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x002(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.055204] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x57A4A9FF, publisher_id: 0x002(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.072656] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x57A4A9FF, datawriter_id: 0x002(5), publisher_id: 0x002(3)
[micro_ros_agent-2] [1717104931.090499] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x003(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.095011] info     | ProxyClient.cpp    | create_subscriber        | subscriber created     | client_key: 0x57A4A9FF, subscriber_id: 0x000(4), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.107278] info     | ProxyClient.cpp    | create_datareader        | datareader created     | client_key: 0x57A4A9FF, datareader_id: 0x000(6), subscriber_id: 0x000(4)

The issue is when I start running the robot controller - teleop_twist_keyboard and try to move the robot, the micro-ROS will suddenly disconnect and cause a major lag in my robot movement.

This might be power issue. You will need to add 220-470uF cap to every power. Put the cap near the load. Post the photos of all your parts and wiring. You should add a battery voltage sensor as I wrote in my wiki.
VBAT -- 33K -- adc pin -- 10K - gnd

Sorry, capacitor to the load of what exactly?

Sorry, Im not too sure if the photo is gonna do you any good. But the signal wiring has been verified.

24v battery

68k -- adc -- 10k -- gnd

Sure, but the 24V solely powers the motors only though. Would it fix the micro-ROS connection problem?

solder a 220uF cap to vin gnd of esp32. solder 220uF to vin gnd of each motor driver. note the cap are polarized.

how do you power pi

I have not actually found a solution to powering my Pi yet. For now my solution is a powerbank. But Im not sure if that would be sufficient.

change the vin of step down 3.3V of encoders, to 24v. you had shown me the photo before.

Okay so actually I tried to use an external supply (USB) from a powerbank and stepped it down to 3.3V and connected a common ground with the ESP. It is slightly better but the micro-ROS is still destroying the session and client sometimes.

cap to filter power noise is important.
check "sudo dmesg", if there any low voltage warning?
The power bank output voltage maybe to low. You can use a step down from 24V, and set the voltage to around 5.15V

No, there is no low power warning.
The 5.15V is for the encoders you mean?

no. 5.15v for pi

there are many connecters in the power and ground. they will create noise. try remove some connectors.for the switch, there is no need to have
⁰8 switch both wires. you canhe

no need to switch both 24v and gnd. switch 24v is enough.

do you use two 24v batteries?

I havevt ried to remove those contact resistence with soldering if possible. I removed the power switch and replaced with a power mosfet.

Oh, I see. step it down to 5.15 for Pi. I will check the current levels and try to power my Pi with that.
I use 2 12V batteries in series. Unfortunately I don't have 24V batteries.
Pardon me, but what do you mean by the contact resistance?

the noise can make the signal run into faulty level, lower than gnd or higher than vcc. and cause trouble to the controller.
the surge current when motor start or stop is very strong when it is loaded with weight.

I use 14 awg wire. other makers may use 12 awg wire.

Please try reduce the motor max rpm and current with
#define MOTOR_MAX_RPM   [ your rpm / 2 ]               // motor's max RPM
#define PWM_MAX (pow(2, PWM_BITS) - 1) / 2

I simply added capacitors to my motor terminals, would that be okay?
I use very big diameter wires actually. If i remember correctly, It's probably 22 or 24 AWG wires.

Wrong. Do not add cap to motor terminal. Add cap to VIN and GND of motor control boards.
The larger AWG number, the thinner wire. So AWG 22/24 are very thin.

https://en.wikibooks.org/wiki/Engineering_Tables/Standard_Wire_Gauge

The Vin and GND means the main 24V power right? not the signals?

Oh I'm not too sure about the wire AWG then. Maybe the seller labelled it wrongly. But anyways, I did confirm that it can support way over the motor rating.

Yes, the Vin and GND means the main 24V power. Add the cap on the motor controller board.

Okok, got it. Just wanted to clarify it. Thanks, I'll try it.

The problem was the polarity.
However, I am facing a micro-ROS issue now and I'm hoping to get some guidance on this. This is when I run the robot bringup command.
leesanhang@Pi4B:~$ ros2 launch linorobot2_bringup bringup.launch.py     base_serial_port:=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2:1.0-port0     lidar_serial_port:=/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0
[INFO] [launch]: All log files can be found below /home/leesanhang/.ros/log/2024-05-31-05-35-05-279499-Pi4B-4745
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [ekf_node-1]: process started with pid [4813]
[INFO] [micro_ros_agent-2]: process started with pid [4815]
[INFO] [joint_state_publisher-3]: process started with pid [4817]
[INFO] [robot_state_publisher-4]: process started with pid [4820]
[INFO] [sllidar_node-5]: process started with pid [4827]
[micro_ros_agent-2] [1717104913.972887] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[micro_ros_agent-2] [1717104913.973905] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4
[micro_ros_agent-2] [1717104914.182600] info     | Root.cpp           | create_client            | create                 | client_key: 0x604407F2, session_id: 0x81
[micro_ros_agent-2] [1717104914.182787] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x604407F2, address: 0
[robot_state_publisher-4] [INFO] [1717104914.457506579] [robot_state_publisher]: got segment base_footprint
[robot_state_publisher-4] [INFO] [1717104914.457979727] [robot_state_publisher]: got segment base_link
[robot_state_publisher-4] [INFO] [1717104914.458082561] [robot_state_publisher]: got segment camera_depth_link
[robot_state_publisher-4] [INFO] [1717104914.458122487] [robot_state_publisher]: got segment camera_link
[robot_state_publisher-4] [INFO] [1717104914.458151116] [robot_state_publisher]: got segment front_left_wheel_link
[robot_state_publisher-4] [INFO] [1717104914.458178802] [robot_state_publisher]: got segment front_right_wheel_link
[robot_state_publisher-4] [INFO] [1717104914.458307857] [robot_state_publisher]: got segment imu_link
[robot_state_publisher-4] [INFO] [1717104914.458351857] [robot_state_publisher]: got segment laser
[robot_state_publisher-4] [INFO] [1717104914.458382746] [robot_state_publisher]: got segment rear_left_wheel_link
[robot_state_publisher-4] [INFO] [1717104914.458412209] [robot_state_publisher]: got segment rear_right_wheel_link
[micro_ros_agent-2] [1717104914.466890] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x604407F2, participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.498531] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x000(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.514749] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x604407F2, publisher_id: 0x000(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.530972] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x604407F2, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[sllidar_node-5] [INFO] [1717104914.541342727] [sllidar_node]: SLLidar running on ROS2 package SLLidar.ROS2 SDK Version:1.0.1, SLLIDAR SDK Version:2.1.0
[micro_ros_agent-2] [1717104914.547264] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x001(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.558755] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x604407F2, publisher_id: 0x001(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.566465] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x604407F2, datawriter_id: 0x001(5), publisher_id: 0x001(3)
[micro_ros_agent-2] [1717104914.576680] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x002(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.590002] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x604407F2, publisher_id: 0x002(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.610584] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x604407F2, datawriter_id: 0x002(5), publisher_id: 0x002(3)
[micro_ros_agent-2] [1717104914.615586] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x604407F2, topic_id: 0x003(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104914.621520] info     | ProxyClient.cpp    | create_subscriber        | subscriber created     | client_key: 0x604407F2, subscriber_id: 0x000(4), participant_id: 0x000(1)
[sllidar_node-5] [INFO] [1717104914.625870875] [sllidar_node]: SLLidar S/N: 6BE69A86C0E09CC7A2E09DF7F9343077
[sllidar_node-5] [INFO] [1717104914.626406875] [sllidar_node]: Firmware Ver: 1.25
[sllidar_node-5] [INFO] [1717104914.626509357] [sllidar_node]: Hardware Rev: 5
[sllidar_node-5] [INFO] [1717104914.633722320] [sllidar_node]: SLLidar health status : 0
[sllidar_node-5] [INFO] [1717104914.633914061] [sllidar_node]: SLLidar health status : OK.
[micro_ros_agent-2] [1717104914.674358] info     | ProxyClient.cpp    | create_datareader        | datareader created     | client_key: 0x604407F2, datareader_id: 0x000(6), subscriber_id: 0x000(4)
[sllidar_node-5] [INFO] [1717104914.984629783] [sllidar_node]: current scan mode: Express, sample rate: 4 Khz, max_distance: 12.0 m, scan frequency:10.0 Hz,
[joint_state_publisher-3] [INFO] [1717104916.308042356] [joint_state_publisher]: Waiting for robot_description to be published on the robot_description topic...
[micro_ros_agent-2] [1717104930.907725] info     | Root.cpp           | delete_client            | delete                 | client_key: 0x604407F2
[micro_ros_agent-2] [1717104930.909726] info     | SessionManager.hpp | destroy_session          | session closed         | client_key: 0x604407F2, address: 0
[micro_ros_agent-2] [1717104930.938645] info     | Root.cpp           | create_client            | create                 | client_key: 0x57A4A9FF, session_id: 0x81
[micro_ros_agent-2] [1717104930.938714] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x57A4A9FF, address: 0
[micro_ros_agent-2] [1717104931.010435] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x57A4A9FF, participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.015549] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x000(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.019623] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x57A4A9FF, publisher_id: 0x000(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.026763] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x57A4A9FF, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[micro_ros_agent-2] [1717104931.031753] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x001(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.036422] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x57A4A9FF, publisher_id: 0x001(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.042683] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x57A4A9FF, datawriter_id: 0x001(5), publisher_id: 0x001(3)
[micro_ros_agent-2] [1717104931.048564] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x002(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.055204] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x57A4A9FF, publisher_id: 0x002(3), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.072656] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x57A4A9FF, datawriter_id: 0x002(5), publisher_id: 0x002(3)
[micro_ros_agent-2] [1717104931.090499] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x57A4A9FF, topic_id: 0x003(2), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.095011] info     | ProxyClient.cpp    | create_subscriber        | subscriber created     | client_key: 0x57A4A9FF, subscriber_id: 0x000(4), participant_id: 0x000(1)
[micro_ros_agent-2] [1717104931.107278] info     | ProxyClient.cpp    | create_datareader        | datareader created     | client_key: 0x57A4A9FF, datareader_id: 0x000(6), subscriber_id: 0x000(4)

When I continuously press on for example: forward, the client and session is destroyed. The issue is when I start running the robot controller - teleop_twist_keyboard and try to move the robot, the micro-ROS will suddenly disconnect and cause a major lag in my robot movement.

This issue still persists. The micro-ROS keeps disconnecting halfway, making my robot very laggy.

Have you tried reduce the motor max rpm and current with
#define MOTOR_MAX_RPM [ your rpm / 2 ] // motor's max RPM
#define PWM_MAX (pow(2, PWM_BITS) - 1) / 2
And try teleop with the robot lift above ground ( wheels do not touch ground).
Please take a photo of your robot from top and photos of your wiring. I want to see all four wheels.

Okay, I just did the changes to the esp32 config file. From what I observe, the movement is slightly better I think.
Btw, this is my robot currently.

What is the 4.9 step down used for? The encoders should be powered by 3.3V.
What is the 3.58 displayed for?

Oh, the 4.9V is actually for Pi. But I'm using the original power source for now.
The 3.58V is for displaying the overall battery and individual cell voltage level to prevent over-discharging the batteries.

Actually, Im not too sure if its a power issue at all.
Before this, I was running ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyUSB0 --baudrate 921600
Then I tried to use ros2 run teleop_twist_keyboard teleop_twist_keyboard to move the robot.
There were no latency between the Pi and the ESP. Not sure why is the problem only occuring now.

I suspected it was the MPU problem actually. I commented out the #define MPU line and the robot is moving perfectly.

Where do you mount the mpu6050? Have you added 2K pull up to the sda scl? You should mount the mpu6050 on your prototype board. The i2c cable should be short.

Shouldn't the MPU be mounted in the very middle of the robot? My prototype board is about right bottom of my robot.
Yes, the 2K resistors are added between the 3V3 and SCL and SDA pins.

The position of the IMU is not so important. We can adjust the IMU link later. The noise interference is more critical. I would suggest move the IMU on the prototype board.

Hi again, sorry there were no updates on my side for the IMU. For the past few days, I've been trying to solve the problem but it seems quite impossible to fix for now. I figured I continue without the IMU (for now) because my robot will always be on flat and clean surfaces.
I've decided to move on to the SLAM and navigation part. The issue now is that when I run l
ros2 launch linorobot2_navigation navigation.launch.py rviz:=true map:=/home/leesanhang/testing.yaml
the Rviz does show up but the map is just plain blank,, without the robot and laser scans too.

Have you tried move the IMU on the prototype board and use short wires to connect?
You should add a 220uF-470uF electrolytic capacitor to the VIN and GND of esp32. The small yellow cap is too small.
Have you tested the lidar on PC without esp32 pluged?
https://github.com/Slamtec/sllidar_ros2
ros2 launch sllidar_ros2 view_sllidar_a2m8_launch.py
Then, on the robot, bringup, check /scan rate, it should be 10.
ros2 topic hz /scan
run slam
https://github.com/hippo5329/linorobot2_hardware/wiki#slam
ros2 launch linorobot2_navigation slam.launch.py rviz:=true
Can you see the laser on slam rviz?
Can y

Hi again, sorry I have not given you an update. I was taking a short break.
However, I have just tried everything and tried to map the indoor environment and it went well. Probably just abit of a slow feedback time when the robot is facing dynamic obstacles.
May I also ask, is Cartographer or GMapping used to run SLAM?

Good.
"is Cartographer or GMapping used to run SLAM?", I don't know. I am new to ROS/NAV, too.

It returns the error: the following arguments are required: executable_name, argv

sudo apt-get install ros-humble-tf2-ros ros-humble-tf2-tools

It works, thank you.

I realized the localization stack uses AMCL, hence the robot can determine where it is in the map without us setting its position in "estimate pose" in RViz. May I ask if you know how to use it, or how to implement it?

http://wiki.ros.org/amcl#Parameters
~initial_pose_x (double, default: 0.0 meters)
Initial pose mean (x), used to initialize filter with Gaussian distribution.
~initial_pose_y (double, default: 0.0 meters)
Initial pose mean (y), used to initialize filter with Gaussian distribution.
The initial pose is required. The initial pose does not need to be very accurate.

So, actually, AMCL does not just auto-detect where the robot is when RViz is launched?

No. In case there are multiple rooms, there is no way to determine which room the robot is in.

Im now facing a problem where it says "timed out waiting for transform from base_link to map to become available, tf error: Invalid frame ID "map" passed to canTransform argument target_frame - frame does not exist.
This occurs quite frequently and Im not sure why, but now the navigation of my robot is very slow. As in the processing takes quite a long time.

From the other cases, I learned that rplidar sensors require higher voltage power, just like raspi boards. I would suggest 5.25V power and short thick USB charging cables. You may use a step down from battery. You should check the voltage on the rplidar adapter. It should be higher than 4.9V.
A2M8 has higher sampling rate. It means there are more laser scan data to process. You may check CPU load with top or htop. You might consider rpi5 or mini pc N95/N100/N200 as robot computer.
You may also try discovery server and run navigation/rviz on a remote PC.
https://github.com/hippo5329/linorobot2_hardware/wiki#use-ros2-with-fast-dds-discovery-server---optional
That way, run only bringup on robot computer and run navigation/slam/rviz on a remote PC.

Okay, I will try that out. one more thing, When I try to use the waypoint following to navigate through multiple goals, the robot doesnt move as well. May i know if that can be fixed?

I am currently testing the robot in the map but the feedback keeps aborting although the path is very big. May I know how I can fix that?

Please describe the moving issue.

Have you enabled the IMU?

Have you adjust the velocity_smoother parameters for Y and reduced accelerations?

The left/right wheels distance should be adjusted for Mecanum/4WD, which is different from differential drive. It might be the distance  front-left wheel to rear-right wheel. You may try to find the setting where the error between laser scan and map is minimized.

#define WHEEL_DIAMETER 0.0560               // wheel's diameter in meters

Have you checked the wheel speed with a digital tachometer in test_motors?

Hi, so I've been trying your suggestions.

Unfortunately, the IMU is still not working and i think i burnt it so it'll be a few days before i get a new one.
I've adjusted it like you instructed. X=Y
Im not sure if i understand. can you clarify?
Unfortunately I dont have a tachometer. What else do you suggest i can do to check? My wheel diameter is 10cm so i defined it to be 0.05. This is in URDF right?

Did you place the IMU on prototype board? IMU is important.

Try lower the accel to 1/2 the values.

I pasted the wrong line. in esp32_config.h,
#define LR_WHEELS_DISTANCE 0.224

For Mecanum drive, the LR_WHEELS_DISTANCE will be larger than the front-left wheel to front-right wheel eg 20. It might be front-left wheel to rear-right wheel, eg, if the wheels position is square, 20 * 1.414 .  You may have to adjust.

You may try cellphone apps, tacho meter strobe. I have never tried.

The distance (from centre of wheels) from left to right is 49 while centre of front to back is 46. Can you advice me on how to define the LR_WHEELS_DISTANCE ?

Between 0.49-0.67. You may try 0.6. Check the error when robot turn and try other values.

You used some expensive lidar, motors, encoders and motor drivers. They won't give you better result for the first time robot. It will be easier if you start over with a small, light-weight and cheap robot  as I suggested "the first robot for beginner" in my wiki. Lesson learned from small robot will help you with larger, more powerful robots. It will only waste your time (and mine), if you skip the simple step, jump into your dream robot and want to success in the first try. NO WAY. You need to learn the basic.
Your wiring is a mess.
You need to use thick short wires to connect the battery to motor controllers. Remove all unnecessary connectors. Use soldering if possible.
Add large 220uF-470uF electrolytic capacitors to your powers near the loads.
Add a battery voltage ADC sensor. It is important to diagnosis power issue.
Start with 12V power. Use only one 12V battery. Change the MAX_RPM to 1/2 the value. It will move slower and this will be fine for the first time robot.
Put IMU on your prototype board.

I will try it in abit.
Actually, on a side note, may I get your full name? I would like to include you in the acknowledgement part of my report.

Good. The starter robot is a learning tool.
Thomas Chou


How to use dmesh to reduce poly count?

Hi @SonSang,
Thank you for sharing your amazing work. I'm a novice in this field and is learning things through trail and error. With your guides on installation and well written readme, I was able to install dmesh and run the example.
Can you guide me on how to reduce poly count (number of faces as shown in Blender) of the attached file? Can you walk me through an example on how to do this? I'm not very sure on the different stages in the experiment (exp1, exp2, exp3). Your help is very much appreciated and I'm looking forward to your response.
Thanks,
Thomas.
crab.zip

Hi Thomas,
Thank you for the interest in my work. If you want to reduce the number of faces in your original mesh, one way could be put it in the point cloud reconstruction algorithm (exp2). It automatically samples points and normals from your mesh, and optimize DMesh to fit the mesh. In doing that, you can change the weight of the weight_regularizer_coef as shown here. This term is related to the number of faces in the final result. As it becomes larger, the algorithm reduces more faces. However, please note that our method does not guarantee manifold mesh for now -- you need post processing to get a clean mesh.

Thank you very much for your prompt response. I will try that today and get back to you.


Tile 25744 has petals 3,4,9 rejected for large STARRMS

Most of the signal for tile 25744 comes from the exposure 20220121/00119660.  Petals 3,4,9 are rejected due to a large STARRMS > 0.20 (dispersion in the standard star model fits) from the file /global/cfs/cdirs/desi/spectro/redux/daily/exposures/20220121/00119660/exposure-qa-00119660.fits
PETAL_LOC  STARRMS

    0 0.14335816
    1 0.14170471
    2 0.07650502
    3 0.20699991
    4 0.25244614
    5 0.13656339
    6 0.10696009
    7 0.16174984
    8 0.12091315
    9 0.20128961

Could the cause of this be the standard star fitting being pulled by the very poor data in the previous exposure 20220120/00119533 on the same tile?

Linking the QA plot for completeness
https://data.desi.lbl.gov/desi/spectro/redux/daily/tiles/cumulative/25744/20220127/tile-qa-25744-thru20220127.png

For petal 4 that shows large rms, the calibrated spectra do not present discontinuities at the boundary of cameras for all 3 exposures of tile 25744 and in particular for exposure 00119660. Could it be due to large positioning errors + an  unusual seeing ?

Transparency was reported to be good on that night, with decent seeing bouncing around between 1 and 1.5".  First exposure of the night, but skies were pretty dark.  It is the case that the observers reported that the focus was "a bit off", but I seem to think that this usually means tens of microns.

18:47 [01:47] Exp. 119660- Good - First tile of the night. A bit off focus and seeing a bit high (1.43). RMS of first correction move is around 4 (SO)
Tile 25744, Exptime: 844.75, Airmass: 1.20, Sequence: DESI, Flavor: science, Program: BRIGHT

The guiding PSF has some peculiar triangular shape. Only 44% of light in fibers on average. If we are out of focus, could there be radial changes in the PSF?
https://data.desi.lbl.gov/desi/spectro/data/20220121/00119660/etc-00119660.png

I suspect we were out of focus.

from astropy.table import Table
for spec in range(10) :
    t=Table.read(f"/global/cfs/cdirs/desi/spectro/redux/daily/exposures/20220121/00119660/cframe-r{spec}-00119660.fits","FIBERMAP")
    s=Table.read(f"/global/cfs/cdirs/desi/spectro/redux/daily/exposures/20220121/00119660/cframe-r{spec}-00119660.fits","SCORES")
    i=t["FIBERFLUX_R"]>10
    x=t["FIBER_X"][i]
    y=t["FIBER_Y"][i]
    ratio=s["MEDIAN_CALIB_COUNT_R"][i]/t["FIBERFLUX_R"][i]
    ratio /= np.median(ratio)
    plt.scatter(x,y,c=ratio,vmin=0.8,vmax=1.2)
plt.colorbar()

Thanks.  It looks like we need to mark this as bad in the offline pipeline.  @akremin, can you mark 119660 as bad so that it gets EFFTIME = 0 and reprocess this tile 25744, and then we need to clear its QA status in tiles-specstatus?
I hadn't used the SCORES extension before---that's obviously useful!  Aiming to be more self-sufficient in the future, can you confirm that:

RAW_COUNT -> frame file values
FFLAT_COUNT -> frame file values after applying fiberflat
SKYSUB_COUNT -> sframe file values
CALIB_COUNT -> cframe file values

I suspect that since the GFAs are on the edge, in terms of raw SNR, this tile is good on the edges and very good in the center, but I agree we don't want to deal with out-of-focus images and should just mark as bad.

yes

The following have been performed:

119660 marked as bad
removed all files associated with tile 25744 on 20220121
removed all redshift files associated with tile 25744 on 20220127
reran redshifts for 25744 on 20220127

The observation on 20220120 was flagged by David as low efftime. There were no other observations on 20220121, so after flagging this exposure there was nothing to rerun. The tile was also observed on 20220126, but it was a bad exposure that wasn't used. So the 20220127 is the only exposure remaining for this tile.
I think this is below the efftime threshold, but could be released for more observations.

Resetting to QA = none.  Confirmed that this tile now has EFFTIME_SPEC < GOALTIME in $DESI_SPECTRO_REDUX/daily/tiles.csv, so this should be scheduled for future observation.  Closing.


feat: service registry fix

total bond should be based on the number of agents & number of agent instance addresses.
It will be calculated when the input is blurred (ie. once the focus is removed from the input)

https://user-images.githubusercontent.com/22061815/233565656-e63ef2a0-a7d8-486e-a239-8a70b90f2475.mov

@oaksprout @kupermind do we want this to be calculated on every input type or on blur is enough?

I don't think it's bad as it currently is, but if you have time to do it with debounce that'd be best.


Running a static code analyser on Godot's codebase

Have any of you tried to run a static code analyser on Godot's codebase? GCC offers extra analysis via the -Wextra and -Weffc++ flags, Clang comes with its own static analyzer clang-check and there are a few standalone programs that perform static analysis (like cppcheck).
I tried to use clang-check but it requires a compilation database, which can be generated automatically from CMake but not from scons.
It should be a good way to find memory leaks and poor loops automatically, if anything.

@tomreyn set up Coverity scans for Godot at some time: https://scan.coverity.com/projects/godot-engine
It has some interesting results, but sadly they're not public, and the handful of devs with access to it don't necessarily have the time/motivation to go through.
If those results could be made public, it would be nice. Godot is not mission critical software so I don't see any issue with having defects exposed to the public, if that can help getting them fixed.

https://scan.coverity.com/policy lists some restrictions which may rule out publishing the results (e.g. "You will not publish any findings regarding or resulting from use of the Service or the Software"). Setting up a shared user account may or may not be an option, IANAL. I suggest to talk to them (send mail to: scan hyphon admin at coverity dot com) and find a solution which both you and they will be happy with. This is usually much more useful than trying to parse legalese.
See also https://scan.coverity.com/faq#who-can-have-access on their perspective on how the results should be handled and why.

Current state. This ignores /drivers directory (apart from gles2 driver).

Although your kindness is appreciated, you should delete the image, since it seems like sharing the results is against their ToS.

No. It's not findings but screen of public data (that you can see here).

You will not publish any findings regarding or resulting from use of the Service or the Software

It says findings.

Clang comes with its own static analyzer clang-check

@paper-pauper I think you meant scan-build called ClangAnalyzer command. It doesn't need any DB and I'd ran it few times against Godot, but it hasn't found much critical bugs (btw. Godot compile logs are flooded with warnings so it's hard to find those interesting onces).

@Marqin Whoops, sorry! I just get over-cautious when I see ToSs, that's why I prefer free software.
Well, I suppose that since you have access to it, only you could potentially fix those "defects", which Coverity doesn't want the rest of us to know about. I hope they aren't serious, but I guess some of them could be discovered via Valgrind.

you have access to it

@bojidar-bg also has access to my fork results, and @reduz or @punto- have access to @tomreyn's

I hope they aren't serious

As I said, I'm not proficent with Godot internals so I cannot say which of it's problems with Reference is false-positive and which is real problem.

@Marqin Just FYI, here's the components which I think reduz (?) configured on 'my' project:

Component name
Pattern
Ignore in analysis

Core
/(core|main)/.*
No

Platform specific code
/platform/.*
No

Scene code
/scene/.*
No

Servers
/servers/.*
No

Third party drivers
/drivers/(?!gles2)(.*)
Yes

GLES driver
/drivers/gles2/.*
No

Modules - GDScript
/modules/gdscript/.*
No

Modules - GridMap
/modules/gridmap/.*
No

Modules - other
/modules/(?!gridmap|gdscript)(.*)
No

Unit tests
/bin/tests/.*
No

Tools - Collada
/tools/collada/.*
No

Tools - Editor
/tools/editor/.*
No

Tools - other
/tools/(?!collada|editor)(.*)
No

As all "Ignore in analysis" checks are "No", Nothing is "Ignored in analysis" as it seems. In combination with defect density of 0.09 this seems a good result to me.

Actually, the "Third party drivers" component is ignored. It is also ignoring some of Godot code though, since some files there contain engine code (at least alsa, pulseaudio, unix and windows folders have only Godot code, and many of the others have a bit of engine code too).

If you ignore the "Third party drivers" component you end up with a defect density of 0.62 (at least that's how it was when the latest check was run with these settings in April):
https://scan.coverity.com/projects/godot-engine
Categorization of code into components serves three purposes:

ignore parts of the code (such as third party code)
allow for filtering on the 'defect browser'
gain a better understanding of the more problematic parts of the code

Is there any progress on this issue lately? If there are no developers interested in fixing some of the issues found by a Coverity scan, this issue should be closed for now.

I'm interested in having Coverity scans and having contributors work on fix issues, but the current setup we have is based on @tomreyn's fork (and uses outdated patterns). I'm also unhappy with Coverity's "private by default" system, so only approved contributors can access the stats (so basically noone, and thus nothing gets fixed).
I'm now looking into setting up Coverity scans for godotengine/godot, and if possible public for everyone (if not, I'll add all GitHub org members and then some so that they have access).
I'll open new issues to keep track of build results and work done to address them though, so closing this one.

While this doesn't make results universally available, it can ensure you always have current results:
https://scan.coverity.com/travis_ci
https://docs.travis-ci.com/user/coverity-scan/
https://blogs.s-osg.org/using-travis-ci-submit-coverity-scan-service/
https://github.com/bjorn/tiled/commit/c0fac49b6f9e96716a5554cb7d9a990bddbe7c29
Making results publicly available should prove difficult. I tried to download a full result set but it's not easy since it's just different sets of (not well defined) JSON data wrapped around a somewhat convoluted web UI.

Thanks for the input - I've also used your components as a reference to set the new ones, so thanks for that (thinking back I could maybe have just tweaked the tomreyn/godot project to make it more "official" instead of creating a new one, but well.. it's done).
Here's the new "official" Coverity Scan: https://scan.coverity.com/projects/godotengine-godot/
I plan to add Travis integration indeed, it's more convenient than uploading local builds (especially when they're still 250 MB xz-compressed).
I set the "Project summary and defects are viewable in read-only mode by all users" option, but it still doesn't seem to allow viewing defects without being invited first (at least in private mode/not logged in, I can't access defects). I guess I'll just invite all core contributors.

Indeed the build submission frequency limits will often collide with an automated build (and submission) mechanism - I have no (fully automated) solution for this either. I guess a cron job triggering a (not otherwise modified) fork to be synced with its upstream, committing and pushing this stage (just into the fork) then triggering a build via Travis-CI and that triggering a submission to Coverity / Synopsis Scan could do. Quite a bit of overhead, I guess, but it should work since you can decide on the build / submission frequency this way, remaining below the limits.

Revisiting the topic on how to extract analysis results, I stumbled upon
https://stackoverflow.com/questions/44119285/does-coverity-have-rest-api
I did not succeed in using HTTP basic authentication to authenticate against one of the report servers using a URL like this:
curl --verbose --user 'tomreyn%40megaglest.org:MYPASSWORD 'https://scan7.coverity.com/api/viewContents/issues/v1/All%20Newly%20Detected?projectId=MegaGlest&rowCount=-1'
I was, however, able to access this URL directly from my web browser just fine, and got a somewhat usable JSON output. Apparently the "REST API" allowing this type of scripted access is a newer feature. Chances are that the Coverity Scan (for OSS scans) platform is just not updated to the latest Coverity Analysis platform, yet.
I also learned that there actually is an export feature on the web UI:


Pinned test requirements to avoid random failing tests (#5666)

Coverage remained the same at 82.459% when pulling 5b6f7bddcf59493740d86b3dcf1306be56eadc45 on czpython:fp/3.4.x/pinned-test-requirements into 9e0dc693214f3d33323a5a74a53277d5ea5103ce on divio:develop.


Update storage api to support query operations by spanKind

Which problem is this PR solving?

Relates to #1921

Short description of the changes

storage API changes to support new query parameter and return type (across all storage engines)

overall changes look ok-ish, but I still think we should limit the blast raduis and not require filtering logic to be done in the storage, just let it return all ops for a service, and do the filtering in the QueryService only (one place).

Just want to your proposal to avoid potential duplicate filtering logic, not for reduce the number of affected files (I assume blast radius means the number of affected files). Because as long as we touch the interface (since spanKind has to be returned in the Operation struct), all the implementations need to be changed.
GetOperations(ctx context.Context, string service) ([]*Operation, error)
GetOperations(ctx context.Context, query *OperationQueryParameters) ([]*Operation, error)
The affected files will be the same for the above two versions.
The benefit of the second method is we can easily add more param into OperationQueryParameters without modifying so many files in the future, and we avoid storage plugin returning un-necessary kind of operations followed by filtering.
Regarding logic duplication, if the storage support filtering in the query statement, then we are not really duplicate the filtering logic in the code.

My point is that you're increasing the scope by requiring storage to implement filtering, which forces you to change memory storage implementation, for example. If you implement it once in the QueryService then all storage impls benefit automatically, whether they support internal filtering or not (e.g. do you know how to implement query-time filtering in Badger?)
but ok, let's do it your way.

My point is that you're increasing the scope by requiring storage to implement filtering, which forces you to change memory storage implementation, for example. If you implement it once in the QueryService then all storage impls benefit automatically, whether they support internal filtering or not (e.g. do you know how to implement query-time filtering in Badger?)
but ok, let's do it your way.

Those storage plugins have to be changed anyway in order to write & read the extra spanKind, they might just as well add the filtering when they make the changes since it's pretty easy. I will make the changes in proto and break longs lines then push another commit.
Btw, I think we might need to keep the following so that old proto users don't need to change their code, otherwise they need to use the corresponding updated get or set method:
message GetOperationsResponse {
    repeated string operation = 1; // deprecated
    repeated Operation operations_v2 = 2;
}

IIRC, the backward compatibility when change names only kicks in when you unmarshall saved data into new structure.

they might just as well add the filtering when they make the changes since it's pretty easy.

you don't know if it's easy or not, it depends on storage implementation (I wouldn't know how to make Badger return only filtered records). And if you're talking about filtering in Go code, then that's exactly the duplication I am referring to.

I need to reopen the PR with same changes against master since #1921-2 is merged


Homematicip_cloud fails to initialize

Home Assistant release with the issue:

0.96.0
Last working Home Assistant release (if known): 0.94.x
Operating environment (Hass.io/Docker/Windows/etc.):

Rasbian Jessy
Component/platform:

Homematicip_cloud
Description of problem:
During launch:
[homeassistant.config] Unable to import homematicip_cloud: cannot import name 'Deque'.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):
[homeassistant.config] Unable to import homematicip_cloud: cannot import name 'Deque'.

Additional information:

Hi,
please restart HA and add more log information to this issue (click full log).
BR

I've already attached the full log related to the issue. But here you go.

2019-07-18 09:13:18 ERROR (MainThread) [homeassistant.config] Unable to import homematicip_cloud: cannot import name 'Deque'
2019-07-18 09:13:18 ERROR (MainThread) [homeassistant.setup] Setup failed for homematicip_cloud: Invalid config.
2019-07-18 09:13:19 ERROR (SyncWorker_19) [xiaomi_gateway] The device with sid 90fd9ffffe2970dc isn't supported of the used gateway firmware. Please update the gateway firmware if possible! This is the only way the issue can be solved.
2019-07-18 09:13:22 INFO (MainThread) [homeassistant.components.media_player] Setting up media_player.mpd
2019-07-18 09:13:23 INFO (MainThread) [homeassistant.components.media_player] Setting up media_player.spotify
2019-07-18 09:13:28 INFO (MainThread) [homeassistant.components.media_player] Setting up media_player.cast
2019-07-18 09:35:21 ERROR (SyncWorker_17) [xiaomi_gateway] Cannot connect to Gateway
2019-07-18 09:35:21 ERROR (SyncWorker_17) [xiaomi_gateway] No data in response from hub None

@cgtobi please tag also core devs.
I don‘t think it is caused by the integration.

@karlkar i assume you have nothing named Deque.

No, I have only one custom component (basing on general thermostat) that is not named Deque nor it uses/declares anything like that

Can you please quickly try this in your HA python environment:
$ python
>>> from collections import deque

Do you get an error?

It works just fine

Please share your homematic related config.

I don't have one - I've been using homematicip_cloud integration.

I've removed the integration and set the component manually. Issue still persists

I've also removed all my custom components and issue still persists

Hi,
have you seen this blogpost?
Could it be relevant for you?
BR

(venv) pi@raspberrypi:~ $ python
Python 3.6.0 (default, Jan  3 2018, 22:17:30)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from homematicip.aio.device import AsyncDevice
>>> from homematicip.aio.home import AsyncHome
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/pi/home-assistant/venv/lib/python3.6/site-packages/homematicip/aio/home.py", line 10, in <module>
    from homematicip.aio.connection import AsyncConnection
  File "/home/pi/home-assistant/venv/lib/python3.6/site-packages/homematicip/aio/connection.py", line 9, in <module>
    import websockets
  File "/home/pi/home-assistant/venv/lib/python3.6/site-packages/websockets/__init__.py", line 3, in <module>
    from .auth import *
  File "/home/pi/home-assistant/venv/lib/python3.6/site-packages/websockets/auth.py", line 15, in <module>
    from .server import HTTPResponse, WebSocketServerProtocol
  File "/home/pi/home-assistant/venv/lib/python3.6/site-packages/websockets/server.py", line 49, in <module>
    from .protocol import WebSocketCommonProtocol
  File "/home/pi/home-assistant/venv/lib/python3.6/site-packages/websockets/protocol.py", line 18, in <module>
    from typing import (
ImportError: cannot import name 'Deque'

Maybe this will help in finding a solution?

I've upgraded my rasbian to buster and it works


After installing .Net Core SDK 3.x, RoslynPad is not working when Core x64 is chosen

It works fine when setting it back to 'Desktop x86" or 'Desktop x64"
Perhaps this could be quite easily fixed.

.NET Core 3 is not supported yet. #301

Duplicate of #301