From c7604fcfa694666a09719addafb92c21d8d4a8b0 Mon Sep 17 00:00:00 2001 From: hojunlim Date: Fri, 15 Dec 2023 16:15:19 +0900 Subject: [PATCH] eutobot dependency node skip --- src/.vscode/colcon.env | 75 ++++++ .../eutobot_bringup/launch/robot.launch.py | 74 ++--- .../launch/yahboomcar_bringup_X3_launch.py | 16 +- src/yahboomcar_bringup/param/ekf.yaml | 254 ++++++++++++++++++ src/yahboomcar_bringup/param/ekf_origin.yaml | 253 +++++++++++++++++ .../yahboomcar_bringup/Mcnamu_driver_X3.py | 2 +- .../Mcnamu_driver_X3.cpython-310.pyc | Bin 4653 -> 4653 bytes 7 files changed, 621 insertions(+), 53 deletions(-) create mode 100644 src/.vscode/colcon.env create mode 100644 src/yahboomcar_bringup/param/ekf.yaml create mode 100644 src/yahboomcar_bringup/param/ekf_origin.yaml diff --git a/src/.vscode/colcon.env b/src/.vscode/colcon.env new file mode 100644 index 0000000..68bbe89 --- /dev/null +++ b/src/.vscode/colcon.env @@ -0,0 +1,75 @@ +SHELL=/bin/bash +SESSION_MANAGER=local/hjmatt-linux:@/tmp/.ICE-unix/2257,unix/hjmatt-linux:/tmp/.ICE-unix/2257 +QT_ACCESSIBILITY=1 +COLORTERM=truecolor +XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg +XDG_MENU_PREFIX=gnome- +GNOME_DESKTOP_SESSION_ID=this-is-deprecated +TERMINATOR_DBUS_PATH=/net/tenshu/Terminator2 +LC_ADDRESS=ko_KR.UTF-8 +GNOME_SHELL_SESSION_MODE=ubuntu +LC_NAME=ko_KR.UTF-8 +SSH_AUTH_SOCK=/run/user/1000/keyring/ssh +ELECTRON_RUN_AS_NODE=1 +TERMINATOR_UUID=urn:uuid:1b1c9186-aec3-4494-ab5a-f51a9555abf6 +XMODIFIERS=@im=ibus +DESKTOP_SESSION=ubuntu +LC_MONETARY=ko_KR.UTF-8 +SSH_AGENT_PID=2219 +VSCODE_AMD_ENTRYPOINT=vs/workbench/api/node/extensionHostProcess +GTK_MODULES=gail:atk-bridge +PWD=/home/hjmatt/task8/13.ros/SRDK/mnt_target/workspace/src +XDG_SESSION_DESKTOP=ubuntu +LOGNAME=hjmatt +XDG_SESSION_TYPE=x11 +GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 +VSCODE_CODE_CACHE_PATH=/home/hjmatt/.config/Code/CachedData/1a5daa3a0231a0fbba4f14db7ec463cf99d7768e +_=/usr/bin/env +XAUTHORITY=/run/user/1000/gdm/Xauthority +GJS_DEBUG_TOPICS=JS ERROR;JS LOG +WINDOWPATH=2 +HOME=/home/hjmatt +USERNAME=hjmatt +IM_CONFIG_PHASE=1 +LC_PAPER=ko_KR.UTF-8 +LANG=en_US.UTF-8 +LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36: +XDG_CURRENT_DESKTOP=Unity +VSCODE_IPC_HOOK=/run/user/1000/vscode-7e50df75-1.84-main.sock +VTE_VERSION=6003 +VSCODE_CLI=1 +INVOCATION_ID=67cab6c134a244dba56513793b4cab58 +TERMINATOR_DBUS_NAME=net.tenshu.Terminator21a9d5db22c73a993ff0b42f64b396873 +MANAGERPID=2041 +CHROME_DESKTOP=code-url-handler.desktop +GJS_DEBUG_OUTPUT=stderr +LESSCLOSE=/usr/bin/lesspipe %s %s +XDG_SESSION_CLASS=user +TERM=xterm-256color +LC_IDENTIFICATION=ko_KR.UTF-8 +LESSOPEN=| /usr/bin/lesspipe %s +USER=hjmatt +DISPLAY=:0 +VSCODE_PID=609928 +SHLVL=1 +LC_TELEPHONE=ko_KR.UTF-8 +QT_IM_MODULE=ibus +LC_MEASUREMENT=ko_KR.UTF-8 +VSCODE_CWD=/home/hjmatt/task8/13.ros/SRDK/mnt_target/workspace/src +VSCODE_CRASH_REPORTER_PROCESS_TYPE=extensionHost +XDG_RUNTIME_DIR=/run/user/1000 +LC_TIME=ko_KR.UTF-8 +ELECTRON_NO_ATTACH_CONSOLE=1 +JOURNAL_STREAM=8:55273 +XDG_DATA_DIRS=/usr/share/ubuntu:/usr/local/share/:/usr/share/ +GDK_BACKEND=x11 +PATH=/home/hjmatt/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin +GDMSESSION=ubuntu +ORIGINAL_XDG_CURRENT_DESKTOP=ubuntu:GNOME +DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus +VSCODE_NLS_CONFIG={"locale":"en-us","osLocale":"en-us","availableLanguages":{},"_languagePackSupport":true} +GIO_LAUNCHED_DESKTOP_FILE_PID=2710 +GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/terminator.desktop +VSCODE_HANDLES_UNCAUGHT_ERRORS=true +LC_NUMERIC=ko_KR.UTF-8 +OLDPWD=/home/hjmatt/task8/13.ros/SRDK/mnt_target/workspace diff --git a/src/eutobot/eutobot_bringup/launch/robot.launch.py b/src/eutobot/eutobot_bringup/launch/robot.launch.py index cce498a..950d0af 100644 --- a/src/eutobot/eutobot_bringup/launch/robot.launch.py +++ b/src/eutobot/eutobot_bringup/launch/robot.launch.py @@ -32,41 +32,23 @@ from launch_ros.parameter_descriptions import ParameterValue def generate_launch_description(): - LDS_MODEL = os.environ['LDS_MODEL'] - LDS_LAUNCH_FILE = '/hlds_laser.launch.py' - # Dynamixel USB Port - dynamixel_usb_port = LaunchConfiguration('dynamixel_usb_port', default='/dev/ttyUSB0') + dynamixel_usb_port = LaunchConfiguration('dynamixel_usb_port', default='/dev/ttyUSB1') - eutobot_param_dir = LaunchConfiguration( - 'eutobot_param_dir', - default=os.path.join( - get_package_share_directory('eutobot_bringup'), - 'param', - 'eutobot.yaml')) + # eutobot_param_dir = LaunchConfiguration( + # 'eutobot_param_dir', + # default=os.path.join( + # get_package_share_directory('eutobot_bringup'), + # 'param', + # 'eutobot.yaml')) - if LDS_MODEL == 'LDS-01': - lidar_pkg_dir = LaunchConfiguration( - 'lidar_pkg_dir', - default=os.path.join(get_package_share_directory('hls_lfcd_lds_driver'), 'launch')) - elif LDS_MODEL == 'LDS-02': - lidar_pkg_dir = LaunchConfiguration( - 'lidar_pkg_dir', - default=os.path.join(get_package_share_directory('ld08_driver'), 'launch')) - LDS_LAUNCH_FILE = '/ld08.launch.py' - elif LDS_MODEL == 'YDLIDAR': - lidar_pkg_dir = LaunchConfiguration( - 'lidar_pkg_dir', - default=os.path.join(get_package_share_directory('ydlidar_ros2_driver'), 'launch')) - LDS_LAUNCH_FILE = '/ydlidar_launch.py' - else: - lidar_pkg_dir = LaunchConfiguration( - 'lidar_pkg_dir', - default=os.path.join(get_package_share_directory('hls_lfcd_lds_driver'), 'launch')) + lidar_pkg_dir = LaunchConfiguration( + 'lidar_pkg_dir', + default=os.path.join(get_package_share_directory('ydlidar_ros2_driver'), 'launch')) + # LDS_LAUNCH_FILE = '/ydlidar_launch.py' use_sim_time = LaunchConfiguration('use_sim_time', default='false') - # YAHBOOM yahboom_pkg_dir = LaunchConfiguration( 'yahboom_pkg_dir', @@ -79,19 +61,19 @@ def generate_launch_description(): default_value=use_sim_time, description='Use simulation (Gazebo) clock if true'), - DeclareLaunchArgument( - 'eutobot_param_dir', - default_value=eutobot_param_dir, - description='Full path to eutobot parameter file to load'), + # DeclareLaunchArgument( + # 'eutobot_param_dir', + # default_value=eutobot_param_dir, + # description='Full path to eutobot parameter file to load'), + + # IncludeLaunchDescription( + # PythonLaunchDescriptionSource( + # [ThisLaunchFileDir(), '/eutobot_state_publisher.launch.py']), + # launch_arguments={'use_sim_time': use_sim_time}.items(), + # ), IncludeLaunchDescription( - PythonLaunchDescriptionSource( - [ThisLaunchFileDir(), '/eutobot_state_publisher.launch.py']), - launch_arguments={'use_sim_time': use_sim_time}.items(), - ), - - IncludeLaunchDescription( - PythonLaunchDescriptionSource([lidar_pkg_dir, LDS_LAUNCH_FILE]), + PythonLaunchDescriptionSource([lidar_pkg_dir, '/ydlidar_launch.py']), launch_arguments={'port': '/dev/ttySAC6', 'frame_id': 'base_scan'}.items(), ), @@ -99,10 +81,10 @@ def generate_launch_description(): PythonLaunchDescriptionSource([yahboom_pkg_dir, "/yahboomcar_bringup_X3_launch.py"]), ), - Node( - package='eutobot_node', - executable='eutobot_ros', - parameters=[eutobot_param_dir], - arguments=['-i', dynamixel_usb_port], - output='screen'), + # Node( + # package='eutobot_node', + # executable='eutobot_ros', + # parameters=[eutobot_param_dir], + # arguments=['-i', dynamixel_usb_port], + # output='screen'), ]) diff --git a/src/yahboomcar_bringup/launch/yahboomcar_bringup_X3_launch.py b/src/yahboomcar_bringup/launch/yahboomcar_bringup_X3_launch.py index c792dcd..ba0617c 100644 --- a/src/yahboomcar_bringup/launch/yahboomcar_bringup_X3_launch.py +++ b/src/yahboomcar_bringup/launch/yahboomcar_bringup_X3_launch.py @@ -65,6 +65,12 @@ def generate_launch_description(): 'imu_filter_param.yaml' ) + ekf_filter_config = os.path.join( + get_package_share_directory('yahboomcar_bringup'), + 'param', + 'ekf.yaml' + ) + driver_node = Node( package='yahboomcar_bringup', executable='Mcnamu_driver_X3', @@ -88,13 +94,11 @@ def generate_launch_description(): executable='ekf_node', name='ekf_filter_node', output='screen', - parameters=[ - os.path.join(get_package_share_directory("robot_localization"), 'params', 'ekf.yaml') - ], + parameters=[ekf_filter_config], remappings=[ - ("/example/imu", "/imu/data"), - ("/example/odom", "/odom_raw"), - ("/odometry/filtered", "/odom"), + ('/odom0', '/odom_raw'), + ('/imu0', '/imu/data'), + ('/odometry/filtered', '/odom') ] ) diff --git a/src/yahboomcar_bringup/param/ekf.yaml b/src/yahboomcar_bringup/param/ekf.yaml new file mode 100644 index 0000000..0464f90 --- /dev/null +++ b/src/yahboomcar_bringup/param/ekf.yaml @@ -0,0 +1,254 @@ +### ekf config file ### +ekf_filter_node: + ros__parameters: +# The frequency, in Hz, at which the filter will output a position estimate. Note that the filter will not begin +# computation until it receives at least one message from one of the inputs. It will then run continuously at the +# frequency specified here, regardless of whether it receives more measurements. Defaults to 30 if unspecified. + frequency: 20.0 + +# The period, in seconds, after which we consider a sensor to have timed out. In this event, we carry out a predict +# cycle on the EKF without correcting it. This parameter can be thought of as the minimum frequency with which the +# filter will generate new output. Defaults to 1 / frequency if not specified. + sensor_timeout: 0.1 + +# ekf_localization_node and ukf_localization_node both use a 3D omnidirectional motion model. If this parameter is +# set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar +# environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected +# by, for example, an IMU. Defaults to false if unspecified. + two_d_mode: true + +# Use this parameter to provide an offset to the transform generated by ekf_localization_node. This can be used for +# future dating the transform, which is required for interaction with some other packages. Defaults to 0.0 if +# unspecified. + transform_time_offset: 0.0 + +# Use this parameter to provide specify how long the tf listener should wait for a transform to become available. +# Defaults to 0.0 if unspecified. + transform_timeout: 0.0 + +# If you're having trouble, try setting this to true, and then echo the /diagnostics_agg topic to see if the node is +# unhappy with any settings or data. + print_diagnostics: true + +# Debug settings. Not for the faint of heart. Outputs a ludicrous amount of information to the file specified by +# debug_out_file. I hope you like matrices! Please note that setting this to true will have strongly deleterious +# effects on the performance of the node. Defaults to false if unspecified. + debug: false + +# Defaults to "robot_localization_debug.txt" if unspecified. Please specify the full path. + debug_out_file: /path/to/debug/file.txt + +# Whether we'll allow old measurements to cause a re-publication of the updated state + permit_corrected_publication: false + +# Whether to publish the acceleration state. Defaults to false if unspecified. + publish_acceleration: false + +# Whether to broadcast the transformation over the /tf topic. Defaults to true if unspecified. + #publish_tf: true + +# REP-105 (http://www.ros.org/reps/rep-0105.html) specifies four principal coordinate frames: base_link, odom, map, and +# earth. base_link is the coordinate frame that is affixed to the robot. Both odom and map are world-fixed frames. +# The robot's position in the odom frame will drift over time, but is accurate in the short term and should be +# continuous. The odom frame is therefore the best frame for executing local motion plans. The map frame, like the odom +# frame, is a world-fixed coordinate frame, and while it contains the most globally accurate position estimate for your +# robot, it is subject to discrete jumps, e.g., due to the fusion of GPS data or a correction from a map-based +# localization node. The earth frame is used to relate multiple map frames by giving them a common reference frame. +# ekf_localization_node and ukf_localization_node are not concerned with the earth frame. +# Here is how to use the following settings: +# 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system. +# 1a. If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of +# odom_frame. +# 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set +# "world_frame" to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes. +# 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates +# from landmark observations) then: +# 3a. Set your "world_frame" to your map_frame value +# 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another state +# estimation node from robot_localization! However, that instance should *not* fuse the global data. + map_frame: map # Defaults to "map" if unspecified + odom_frame: odom # Defaults to "odom" if unspecified + base_link_frame: base_footprint # Defaults to "base_link" if unspecified + world_frame: odom # Defaults to the value of odom_frame if unspecified + +# The filter accepts an arbitrary number of inputs from each input message type (nav_msgs/Odometry, +# geometry_msgs/PoseWithCovarianceStamped, geometry_msgs/TwistWithCovarianceStamped, +# sensor_msgs/Imu). To add an input, simply append the next number in the sequence to its "base" name, e.g., odom0, +# odom1, twist0, twist1, imu0, imu1, imu2, etc. The value should be the topic name. These parameters obviously have no +# default values, and must be specified. + odom0: /odom0 + +# Each sensor reading updates some or all of the filter's state. These options give you greater control over which +# values from each measurement are fed to the filter. For example, if you have an odometry message as input, but only +# want to use its Z position value, then set the entire vector to false, except for the third entry. The order of the +# values is x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Note that not some message types +# do not provide some of the state variables estimated by the filter. For example, a TwistWithCovarianceStamped message +# has no pose information, so the first six values would be meaningless in that case. Each vector defaults to all false +# if unspecified, effectively making this parameter required for each sensor. + odom0_config: [false, false, false, + false, false, false, + true, true, false, + false, false, true, + false, false, false] + +# If you have high-frequency data or are running with a low frequency parameter value, then you may want to increase +# the size of the subscription queue so that more measurements are fused. + odom0_queue_size: 1 + +# [ADVANCED] Large messages in ROS can exhibit strange behavior when they arrive at a high frequency. This is a result +# of Nagle's algorithm. This option tells the ROS subscriber to use the tcpNoDelay option, which disables Nagle's +# algorithm. + odom0_nodelay: false + +# [ADVANCED] When measuring one pose variable with two sensors, a situation can arise in which both sensors under- +# report their covariances. This can lead to the filter rapidly jumping back and forth between each measurement as they +# arrive. In these cases, it often makes sense to (a) correct the measurement covariances, or (b) if velocity is also +# measured by one of the sensors, let one sensor measure pose, and the other velocity. However, doing (a) or (b) isn't +# always feasible, and so we expose the differential parameter. When differential mode is enabled, all absolute pose +# data is converted to velocity data by differentiating the absolute pose measurements. These velocities are then +# integrated as usual. NOTE: this only applies to sensors that provide pose measurements; setting differential to true +# for twist measurements has no effect. + odom0_differential: true + +# [ADVANCED] When the node starts, if this parameter is true, then the first measurement is treated as a "zero point" +# for all future measurements. While you can achieve the same effect with the differential paremeter, the key +# difference is that the relative parameter doesn't cause the measurement to be converted to a velocity before +# integrating it. If you simply want your measurements to start at 0 for a given sensor, set this to true. + odom0_relative: false + +# [ADVANCED] If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to +# control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to +# numeric_limits::max() if unspecified. It is strongly recommended that these parameters be removed if not +# required. Data is specified at the level of pose and twist variables, rather than for each variable in isolation. +# For messages that have both pose and twist data, the parameter specifies to which part of the message we are applying +# the thresholds. + odom0_pose_rejection_threshold: 5.0 + odom0_twist_rejection_threshold: 1.0 + +# Further input parameter examples + odom1: example/odom2 + odom1_config: [false, false, true, + false, false, false, + false, false, false, + false, false, true, + false, false, false] + odom1_differential: false + odom1_relative: true + odom1_queue_size: 2 + odom1_pose_rejection_threshold: 2.0 + odom1_twist_rejection_threshold: 0.2 + odom1_nodelay: false + pose0: example/pose + pose0_config: [true, true, false, + false, false, false, + false, false, false, + false, false, false, + false, false, false] + pose0_differential: true + pose0_relative: false + pose0_queue_size: 5 + pose0_rejection_threshold: 2.0 # Note the difference in parameter name + pose0_nodelay: false + + twist0: example/twist + twist0_config: [false, false, false, + false, false, false, + true, true, true, + false, false, false, + false, false, false] + twist0_queue_size: 3 + twist0_rejection_threshold: 2.0 + twist0_nodelay: false + + imu0: /imu0 + imu0_config: [false, false, false, + true, true, true, + false, false, false, + true, true, true, + false, false, false] + #imu0_nodelay: false + imu0_differential: true + imu0_relative: false + imu0_queue_size: 1 + imu0_pose_rejection_threshold: 0.8 # Note the difference in parameter names + imu0_twist_rejection_threshold: 0.8 # + imu0_linear_acceleration_rejection_threshold: 0.8 # + +# [ADVANCED] Some IMUs automatically remove acceleration due to gravity, and others don't. If yours doesn't, please set +# this to true, and *make sure* your data conforms to REP-103, specifically, that the data is in ENU frame. + imu0_remove_gravitational_acceleration: true + +# [ADVANCED] The EKF and UKF models follow a standard predict/correct cycle. During prediction, if there is no +# acceleration reference, the velocity at time t+1 is simply predicted to be the same as the velocity at time t. During +# correction, this predicted value is fused with the measured value to produce the new velocity estimate. This can be +# problematic, as the final velocity will effectively be a weighted average of the old velocity and the new one. When +# this velocity is the integrated into a new pose, the result can be sluggish covergence. This effect is especially +# noticeable with LIDAR data during rotations. To get around it, users can try inflating the process_noise_covariance +# for the velocity variable in question, or decrease the variance of the variable in question in the measurement +# itself. In addition, users can also take advantage of the control command being issued to the robot at the time we +# make the prediction. If control is used, it will get converted into an acceleration term, which will be used during +# predicition. Note that if an acceleration measurement for the variable in question is available from one of the +# inputs, the control term will be ignored. +# Whether or not we use the control input during predicition. Defaults to false. + use_control: false +# Whether the input (assumed to be cmd_vel) is a geometry_msgs/Twist or geometry_msgs/TwistStamped message. Defaults to +# false. + stamped_control: false +# The last issued control command will be used in prediction for this period. Defaults to 0.2. + control_timeout: 0.2 +# Which velocities are being controlled. Order is vx, vy, vz, vroll, vpitch, vyaw. + control_config: [true, false, false, false, false, true] +# Places limits on how large the acceleration term will be. Should match your robot's kinematics. + acceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 3.4] +# Acceleration and deceleration limits are not always the same for robots. + deceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 4.5] +# If your robot cannot instantaneously reach its acceleration limit, the permitted change can be controlled with these +# gains + acceleration_gains: [0.8, 0.0, 0.0, 0.0, 0.0, 0.9] +# If your robot cannot instantaneously reach its deceleration limit, the permitted change can be controlled with these +# gains + deceleration_gains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0] +# [ADVANCED] The process noise covariance matrix can be difficult to tune, and can vary for each application, so it is +# exposed as a configuration parameter. This matrix represents the noise we add to the total error after each +# prediction step. The better the omnidirectional motion model matches your system, the smaller these values can be. +# However, if users find that a given variable is slow to converge, one approach is to increase the +# process_noise_covariance diagonal value for the variable in question, which will cause the filter's predicted error +# to be larger, which will cause the filter to trust the incoming measurement more during correction. The values are +# ordered as x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Defaults to the matrix below if +# unspecified. + process_noise_covariance: [0.05, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.05, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.03, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.03, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.025, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.025, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.04, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.02, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.015] +# [ADVANCED] This represents the initial value for the state estimate error covariance matrix. Setting a diagonal +# value (variance) to a large value will result in rapid convergence for initial measurements of the variable in +# question. Users should take care not to use large values for variables that will not be measured directly. The values +# are ordered as x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Defaults to the matrix below +#if unspecified. + initial_estimate_covariance: [1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9] + diff --git a/src/yahboomcar_bringup/param/ekf_origin.yaml b/src/yahboomcar_bringup/param/ekf_origin.yaml new file mode 100644 index 0000000..6bf3f4f --- /dev/null +++ b/src/yahboomcar_bringup/param/ekf_origin.yaml @@ -0,0 +1,253 @@ +### ekf config file ### +ekf_filter_node: + ros__parameters: +# The frequency, in Hz, at which the filter will output a position estimate. Note that the filter will not begin +# computation until it receives at least one message from one of the inputs. It will then run continuously at the +# frequency specified here, regardless of whether it receives more measurements. Defaults to 30 if unspecified. + frequency: 30.0 + +# The period, in seconds, after which we consider a sensor to have timed out. In this event, we carry out a predict +# cycle on the EKF without correcting it. This parameter can be thought of as the minimum frequency with which the +# filter will generate new output. Defaults to 1 / frequency if not specified. + sensor_timeout: 0.1 + +# ekf_localization_node and ukf_localization_node both use a 3D omnidirectional motion model. If this parameter is +# set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar +# environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected +# by, for example, an IMU. Defaults to false if unspecified. + two_d_mode: false + +# Use this parameter to provide an offset to the transform generated by ekf_localization_node. This can be used for +# future dating the transform, which is required for interaction with some other packages. Defaults to 0.0 if +# unspecified. + transform_time_offset: 0.0 + +# Use this parameter to provide specify how long the tf listener should wait for a transform to become available. +# Defaults to 0.0 if unspecified. + transform_timeout: 0.0 + +# If you're having trouble, try setting this to true, and then echo the /diagnostics_agg topic to see if the node is +# unhappy with any settings or data. + print_diagnostics: true + +# Debug settings. Not for the faint of heart. Outputs a ludicrous amount of information to the file specified by +# debug_out_file. I hope you like matrices! Please note that setting this to true will have strongly deleterious +# effects on the performance of the node. Defaults to false if unspecified. + debug: false + +# Defaults to "robot_localization_debug.txt" if unspecified. Please specify the full path. + debug_out_file: /path/to/debug/file.txt + +# Whether we'll allow old measurements to cause a re-publication of the updated state + permit_corrected_publication: false + +# Whether to publish the acceleration state. Defaults to false if unspecified. + publish_acceleration: false + +# Whether to broadcast the transformation over the /tf topic. Defaults to true if unspecified. + publish_tf: true + +# REP-105 (http://www.ros.org/reps/rep-0105.html) specifies four principal coordinate frames: base_link, odom, map, and +# earth. base_link is the coordinate frame that is affixed to the robot. Both odom and map are world-fixed frames. +# The robot's position in the odom frame will drift over time, but is accurate in the short term and should be +# continuous. The odom frame is therefore the best frame for executing local motion plans. The map frame, like the odom +# frame, is a world-fixed coordinate frame, and while it contains the most globally accurate position estimate for your +# robot, it is subject to discrete jumps, e.g., due to the fusion of GPS data or a correction from a map-based +# localization node. The earth frame is used to relate multiple map frames by giving them a common reference frame. +# ekf_localization_node and ukf_localization_node are not concerned with the earth frame. +# Here is how to use the following settings: +# 1. Set the map_frame, odom_frame, and base_link frames to the appropriate frame names for your system. +# 1a. If your system does not have a map_frame, just remove it, and make sure "world_frame" is set to the value of +# odom_frame. +# 2. If you are fusing continuous position data such as wheel encoder odometry, visual odometry, or IMU data, set +# "world_frame" to your odom_frame value. This is the default behavior for robot_localization's state estimation nodes. +# 3. If you are fusing global absolute position data that is subject to discrete jumps (e.g., GPS or position updates +# from landmark observations) then: +# 3a. Set your "world_frame" to your map_frame value +# 3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another state +# estimation node from robot_localization! However, that instance should *not* fuse the global data. + map_frame: map # Defaults to "map" if unspecified + odom_frame: odom # Defaults to "odom" if unspecified + base_link_frame: base_link # Defaults to "base_link" if unspecified + world_frame: odom # Defaults to the value of odom_frame if unspecified + +# The filter accepts an arbitrary number of inputs from each input message type (nav_msgs/Odometry, +# geometry_msgs/PoseWithCovarianceStamped, geometry_msgs/TwistWithCovarianceStamped, +# sensor_msgs/Imu). To add an input, simply append the next number in the sequence to its "base" name, e.g., odom0, +# odom1, twist0, twist1, imu0, imu1, imu2, etc. The value should be the topic name. These parameters obviously have no +# default values, and must be specified. + odom0: example/odom + +# Each sensor reading updates some or all of the filter's state. These options give you greater control over which +# values from each measurement are fed to the filter. For example, if you have an odometry message as input, but only +# want to use its Z position value, then set the entire vector to false, except for the third entry. The order of the +# values is x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Note that not some message types +# do not provide some of the state variables estimated by the filter. For example, a TwistWithCovarianceStamped message +# has no pose information, so the first six values would be meaningless in that case. Each vector defaults to all false +# if unspecified, effectively making this parameter required for each sensor. + odom0_config: [true, true, false, + false, false, false, + false, false, false, + false, false, true, + false, false, false] + +# If you have high-frequency data or are running with a low frequency parameter value, then you may want to increase +# the size of the subscription queue so that more measurements are fused. + odom0_queue_size: 2 + +# [ADVANCED] Large messages in ROS can exhibit strange behavior when they arrive at a high frequency. This is a result +# of Nagle's algorithm. This option tells the ROS subscriber to use the tcpNoDelay option, which disables Nagle's +# algorithm. + odom0_nodelay: false + +# [ADVANCED] When measuring one pose variable with two sensors, a situation can arise in which both sensors under- +# report their covariances. This can lead to the filter rapidly jumping back and forth between each measurement as they +# arrive. In these cases, it often makes sense to (a) correct the measurement covariances, or (b) if velocity is also +# measured by one of the sensors, let one sensor measure pose, and the other velocity. However, doing (a) or (b) isn't +# always feasible, and so we expose the differential parameter. When differential mode is enabled, all absolute pose +# data is converted to velocity data by differentiating the absolute pose measurements. These velocities are then +# integrated as usual. NOTE: this only applies to sensors that provide pose measurements; setting differential to true +# for twist measurements has no effect. + odom0_differential: false + +# [ADVANCED] When the node starts, if this parameter is true, then the first measurement is treated as a "zero point" +# for all future measurements. While you can achieve the same effect with the differential paremeter, the key +# difference is that the relative parameter doesn't cause the measurement to be converted to a velocity before +# integrating it. If you simply want your measurements to start at 0 for a given sensor, set this to true. + odom0_relative: false + +# [ADVANCED] If your data is subject to outliers, use these threshold settings, expressed as Mahalanobis distances, to +# control how far away from the current vehicle state a sensor measurement is permitted to be. Each defaults to +# numeric_limits::max() if unspecified. It is strongly recommended that these parameters be removed if not +# required. Data is specified at the level of pose and twist variables, rather than for each variable in isolation. +# For messages that have both pose and twist data, the parameter specifies to which part of the message we are applying +# the thresholds. + odom0_pose_rejection_threshold: 5.0 + odom0_twist_rejection_threshold: 1.0 + +# Further input parameter examples + odom1: example/odom2 + odom1_config: [false, false, true, + false, false, false, + false, false, false, + false, false, true, + false, false, false] + odom1_differential: false + odom1_relative: true + odom1_queue_size: 2 + odom1_pose_rejection_threshold: 2.0 + odom1_twist_rejection_threshold: 0.2 + odom1_nodelay: false + pose0: example/pose + pose0_config: [true, true, false, + false, false, false, + false, false, false, + false, false, false, + false, false, false] + pose0_differential: true + pose0_relative: false + pose0_queue_size: 5 + pose0_rejection_threshold: 2.0 # Note the difference in parameter name + pose0_nodelay: false + + twist0: example/twist + twist0_config: [false, false, false, + false, false, false, + true, true, true, + false, false, false, + false, false, false] + twist0_queue_size: 3 + twist0_rejection_threshold: 2.0 + twist0_nodelay: false + + imu0: example/imu + imu0_config: [false, false, false, + true, true, true, + false, false, false, + true, true, true, + true, true, true] + imu0_nodelay: false + imu0_differential: false + imu0_relative: true + imu0_queue_size: 5 + imu0_pose_rejection_threshold: 0.8 # Note the difference in parameter names + imu0_twist_rejection_threshold: 0.8 # + imu0_linear_acceleration_rejection_threshold: 0.8 # + +# [ADVANCED] Some IMUs automatically remove acceleration due to gravity, and others don't. If yours doesn't, please set +# this to true, and *make sure* your data conforms to REP-103, specifically, that the data is in ENU frame. + imu0_remove_gravitational_acceleration: true + +# [ADVANCED] The EKF and UKF models follow a standard predict/correct cycle. During prediction, if there is no +# acceleration reference, the velocity at time t+1 is simply predicted to be the same as the velocity at time t. During +# correction, this predicted value is fused with the measured value to produce the new velocity estimate. This can be +# problematic, as the final velocity will effectively be a weighted average of the old velocity and the new one. When +# this velocity is the integrated into a new pose, the result can be sluggish covergence. This effect is especially +# noticeable with LIDAR data during rotations. To get around it, users can try inflating the process_noise_covariance +# for the velocity variable in question, or decrease the variance of the variable in question in the measurement +# itself. In addition, users can also take advantage of the control command being issued to the robot at the time we +# make the prediction. If control is used, it will get converted into an acceleration term, which will be used during +# predicition. Note that if an acceleration measurement for the variable in question is available from one of the +# inputs, the control term will be ignored. +# Whether or not we use the control input during predicition. Defaults to false. + use_control: true +# Whether the input (assumed to be cmd_vel) is a geometry_msgs/Twist or geometry_msgs/TwistStamped message. Defaults to +# false. + stamped_control: false +# The last issued control command will be used in prediction for this period. Defaults to 0.2. + control_timeout: 0.2 +# Which velocities are being controlled. Order is vx, vy, vz, vroll, vpitch, vyaw. + control_config: [true, false, false, false, false, true] +# Places limits on how large the acceleration term will be. Should match your robot's kinematics. + acceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 3.4] +# Acceleration and deceleration limits are not always the same for robots. + deceleration_limits: [1.3, 0.0, 0.0, 0.0, 0.0, 4.5] +# If your robot cannot instantaneously reach its acceleration limit, the permitted change can be controlled with these +# gains + acceleration_gains: [0.8, 0.0, 0.0, 0.0, 0.0, 0.9] +# If your robot cannot instantaneously reach its deceleration limit, the permitted change can be controlled with these +# gains + deceleration_gains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0] +# [ADVANCED] The process noise covariance matrix can be difficult to tune, and can vary for each application, so it is +# exposed as a configuration parameter. This matrix represents the noise we add to the total error after each +# prediction step. The better the omnidirectional motion model matches your system, the smaller these values can be. +# However, if users find that a given variable is slow to converge, one approach is to increase the +# process_noise_covariance diagonal value for the variable in question, which will cause the filter's predicted error +# to be larger, which will cause the filter to trust the incoming measurement more during correction. The values are +# ordered as x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Defaults to the matrix below if +# unspecified. + process_noise_covariance: [0.05, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.05, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.03, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.03, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.025, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.025, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.04, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.02, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.015] +# [ADVANCED] This represents the initial value for the state estimate error covariance matrix. Setting a diagonal +# value (variance) to a large value will result in rapid convergence for initial measurements of the variable in +# question. Users should take care not to use large values for variables that will not be measured directly. The values +# are ordered as x, y, z, roll, pitch, yaw, vx, vy, vz, vroll, vpitch, vyaw, ax, ay, az. Defaults to the matrix below +#if unspecified. + initial_estimate_covariance: [1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9, 0.0, + 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-9] diff --git a/src/yahboomcar_bringup/yahboomcar_bringup/Mcnamu_driver_X3.py b/src/yahboomcar_bringup/yahboomcar_bringup/Mcnamu_driver_X3.py index b03e57e..e41fb84 100644 --- a/src/yahboomcar_bringup/yahboomcar_bringup/Mcnamu_driver_X3.py +++ b/src/yahboomcar_bringup/yahboomcar_bringup/Mcnamu_driver_X3.py @@ -30,7 +30,7 @@ class yahboomcar_driver(Node): global car_type_dic self.RA2DE = 180 / pi # self.car = Rosmaster() - self.car = Rosmaster(1, "/dev/ttyUSB1", 2, False); + self.car = Rosmaster(1, "/dev/ttyUSB0", 2, False); self.car.set_car_type(1) #get parameter self.declare_parameter('car_type', 'X3') diff --git a/src/yahboomcar_bringup/yahboomcar_bringup/__pycache__/Mcnamu_driver_X3.cpython-310.pyc b/src/yahboomcar_bringup/yahboomcar_bringup/__pycache__/Mcnamu_driver_X3.cpython-310.pyc index f5e2afe48fe3ebfa838a2dcfd11e5e40fbf4756f..a2701ad87bbdbf9eb1dc45ba034233eb64595345 100644 GIT binary patch delta 19 ZcmZ3hvQ~vFpO=@50SGqS+Q_9W1OPE61iAnK delta 19 ZcmZ3hvQ~vFpO=@50SF2gZRAoG0st