Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32 issues anyone? #119

Open
tbalatka opened this issue Apr 26, 2024 · 50 comments
Open

ESP32 issues anyone? #119

tbalatka opened this issue Apr 26, 2024 · 50 comments

Comments

@tbalatka
Copy link

tbalatka commented Apr 26, 2024

Hello, I installed Linorobot2 on a laptop running ROS2 Humble. On an ESP32 Wroom, I am running Linorobot2_hardware (Rolling branch). The lidar model I am using is YDLidar2 x4. Both the lidar and ESP32 are connected to the laptop on the robot via USB. The IMU is a MPU6050.

Odom is fine. RZIV2 updates the position of the robot on the grid no problem, as I drive the real robot forward and reverse. But when I turn the direction of the robot, the map generated looks like a Picasso painting, which makes sense since the real robot changed direction but the virtual robot remained pointed in the old direction, resulting in the new perspective of the room superimposed over the old perspective. (hope that makes sense).

There is obviously a break somewhere in communication with respect to the TF data. This is demonstrated in RVIZ2 where I can see the wheels are not rotating when the real robot moves.

To troubleshoot, I ran "ros2 topic echo /tf" and the values under "rotation" show, for example, z: 0.18919803956070486 and w: 0.9819389501523941. Those values change as I move the robot around using teleop_twist_keyboard, but the onscreen wheels remain static as the robot model sort of drifts along the grid.

I've tried both base_serial_port and micro_ros_transport methods on the ESP32, thinking maybe the serial connection or baud rate was at fault. I got the same results.

ROS is new to me and I'm learning as much as I can on my own without assistance -- but this TF issue has me totally stumped.

Any advice would be much appreciated.

BTW, I've included here a photo of my project. It's large (wheels are 8 inches diameter) stands 18" tall. I'm using 12V car seat motors attached to E6B2-CWZ6C encoders. It has incredible torque and it's very quiet (not permitted to have noisy robots in our household...lol). Motor controller consists of two BTS7960 modules. The laptop is an i3. Everything is powered by a 12V 6Ah LiFePO4 Battery. I designed and 3D printed all the parts.
image

@tbalatka tbalatka changed the title ESP32 Anyone? ESP32 issues anyone? Apr 26, 2024
@hippo5329
Copy link
Contributor

Hi. I am the maintainer of esp32/pico port. I am new to ROS and robot, too. Your robot is awesome.

  1. The required micro-ros serial baudrate for esp32 is 921600 to run the control loop at 50Hz. Would you check the control loop refresh rate with "ros2 topic hz /imu/data" ? It should be close to 50Hz.
  2. The orientation of the IMU must be correct. X forward, Y left, Z up. Please check the ACC reading of "ros2 topic echo /imu/data". When the robot is not moving, the reading should be close to 0,0,9.8 . When the robot start to move forward, the accX should be positive. When the robot stop moving forward, the accX should be negative.
  3. Have you updated the robot spec in esp32_config.h? WHEEL_DIAMETER,LR_WHEELS_DISTANCE etc. Have you updated the URDF in ros2_ws/src/linorobot2/linorobot2_description/urdf/2wd_properties.urdf.xacro ?
  4. I maintain a wiki for linorobot2. Please check https://github.com/hippo5329/linorobot2_hardware/wiki .

Cheers,
Thomas Chou

@hippo5329
Copy link
Contributor

I created pull-requests pr-mag to both linorobot/linorobot2 and linorobot/linorobot2_hardware. You may use the new "micro_ros_baudrate" param in robot bringup to set the baudrate to 921600.

I had similar issue before. It was resolved at 921600 baud. I would also suggest adding a supported magnetometer sensor, such as QMC5883L. The magnetometer support is added in the pr-mag branch. It might help. It would be nice to have your comments and suggestions.

Thomas

@tbalatka
Copy link
Author

tbalatka commented Apr 28, 2024 via email

@tbalatka
Copy link
Author

tbalatka commented Apr 28, 2024 via email

@hippo5329
Copy link
Contributor

You are welcome.

  1. laser filter can be used to remove objects on robot. See extra in bringup.

  2. Power system. Power the esp32 from USB. Power the IMU from 5V output of esp32. Use a step down from battery to 3.3V to motors drivers and encoders. Esp32 io interfaces are 3.3V tolerance. Use logic level shifter to other logic level.

@hippo5329
Copy link
Contributor

My wheels are small. I looked into the rviz. Yes, the wheels are moving.

@hippo5329
Copy link
Contributor

Yes. Mount the magnetometer away from motors and battery as much as possible. Calibrate the magnetometer to remove hard iron bias.

@hippo5329
Copy link
Contributor

Power system and the Hz freq of control loop are the first things to check. I put low ESR cap on every power.

@hippo5329
Copy link
Contributor

The nav yaml on the linorobot2 is quite old. I updated the smoother for Mecanum robot. Check the hippo5329/linorobot2 omni branch.

@tbalatka
Copy link
Author

tbalatka commented Apr 28, 2024 via email

@tbalatka
Copy link
Author

tbalatka commented Apr 28, 2024 via email

@hippo5329
Copy link
Contributor

How about "ros2 topic hz /imu/data"?

@tbalatka
Copy link
Author

tb@tb-HP-EliteBook-Revolve-810-G1:~$ ros2 topic hz /imu/data
average rate: 43.232
min: 0.014s max: 0.037s std dev: 0.00630s window: 45
average rate: 42.556
min: 0.014s max: 0.041s std dev: 0.00616s window: 87
average rate: 40.602
min: 0.014s max: 0.050s std dev: 0.00652s window: 124
average rate: 40.661
min: 0.014s max: 0.050s std dev: 0.00652s window: 166
average rate: 39.613
min: 0.014s max: 0.082s std dev: 0.00798s window: 202
average rate: 36.457
min: 0.013s max: 0.380s std dev: 0.02667s window: 224
average rate: 36.215
min: 0.013s max: 0.380s std dev: 0.02662s window: 259
average rate: 36.982
min: 0.013s max: 0.380s std dev: 0.02481s window: 302

@hippo5329
Copy link
Contributor

MPU6050 on my robot

linear_acceleration:
x: 0.5915698495227844
y: 0.09340576571412385
z: 9.752519948408008

@hippo5329
Copy link
Contributor

Do you have 2K Ohm pull up to 3.3V on the i2c sda scl line of esp23?

@tbalatka
Copy link
Author

No I don't. Every schematic I've come across lately doesn't have one.

@hippo5329
Copy link
Contributor

Please add the pull up. esp32 does not have them on board.

@hippo5329
Copy link
Contributor

hippo5329 commented Apr 29, 2024

sda scl 2K to 3.3V output of esp32.

@hippo5329
Copy link
Contributor

2k or 2.2k are fine.

@tbalatka
Copy link
Author

tbalatka commented Apr 29, 2024 via email

@hippo5329
Copy link
Contributor

You may try lower the velocity and acceleration limits in velocity_smoother.

https://github.com/hippo5329/linorobot2_hardware/wiki#configure-the-linorobot2

@tbalatka
Copy link
Author

tbalatka commented May 1, 2024 via email

@tbalatka
Copy link
Author

tbalatka commented May 8, 2024

What version of ESP32 are you using? S2, S3?

@hippo5329
Copy link
Contributor

hippo5329 commented May 8, 2024

I use mostly esp32 on my robots. Because I have a lot of esp32 and I run micro-ROS wifi transport. The S3 and S2 are for testing only. S3 is better than S2. As you have pi 3B and use serial transport, if you want to buy a new micro-controller, you may consider Pico, too. I had a Mecanum drive robot using Pico and Pi 5. However, I think you may use your existing esp32.

  1. Please try disable the imu in the ekf filter, which fuses the wheel odometry and imu. Only vyaw of imu is used. The SLAM can go without imu. Please comment out the lines of imu in the file linorobot2_ws/src/linorobot2/linorobot2_base/config/ekf.yaml . Then in the linorobot2_ws dir, run "colcon build" . Bringup robot and test SLAM again.
        #x     , y     , z,
        #roll  , pitch , yaw,
        #vx    , vy    , vz,
        #vroll , vpitch, vyaw,
        #ax    , ay    , az
        odom0: odom/unfiltered
        odom0_config: [false, false, false,
                       false, false, false,
                       true, true, false,
                       false, false, true,
                       false, false, false]

#        imu0: imu/data
#        imu0_config: [false, false, false,
#                      false, false, false,
#                      false, false, false,
#                      false, false, true,
#                      false, false, false]
  1. On the other way. I enabled mpu6050 calibration in the pr-mag (for the linorobot2/linorobot_hardware) and master branch of my fork (hippo5329/linorobot2_hardware). You may try these patches. The reading of /imu/data should be normalized to around 0,0,9.8 .

Please let me know the test results.

Cheers,
Thomas

@hippo5329
Copy link
Contributor

I added another patch. Now, no need to modify the ekf as point 1 I said in previous message. Just disable mpu6050 in your configuration file.

// #define USE_MPU6050_IMU

@tbalatka
Copy link
Author

tbalatka commented May 12, 2024

2wd_properties.urdf.xacro.txt
To simplify troubleshooting I commented out the MPU6050 and QMC5883L in my ESP32_wifi.config file and uploaded it to my ESP32-E Wroom. I then launched "ros2 launch linorobot2_bringup bringup.launch.py micro_ros_transport:=udp4 micro_ros_port:=8888" and ran "ros2 run teleop_twist_keyboard teleop_twist_keyboard".

The real robot responded correctly to the keyboard commands ("I" for forward, "J" for left, etc.). I then launched RVIZ2 and added robot model, TF, and selected Global Options > Fixed Frame > Odom. As the real robot moves around on the floor, the RVIZ2 robot mimics the same movements on the grid, however the axis on the wheels don't rotate.

I attached my URDF xacro file for my 2WD robot. I noticed that it's not as complete as other robot descriptions I have come across. For example, there is no joint or base footprint link.

@hippo5329
Copy link
Contributor

hippo5329 commented May 13, 2024

I checked again. The wheels do not move in RVIZ on my robot. The wheels rotate on gazebo because gazebo publishes the wheels rotation tf. Real robot does not publish joint_state updates of the wheels for the joint_state_publisher. So the robot_state_publisher does not update the rotation and the wheels won't move in RVIZ. It is possible to publish the joint_state of the wheels on real robots to see the wheels rotating in RVIZ though.

@tbalatka
Copy link
Author

tbalatka commented May 13, 2024

Ok. Thanks for the update. I'll look into how I can modify the code so that joint states are published for the left and right wheels.

BTW, I ordered an LD19 and I'll let you know how that goes with navigation.

@aimethierry
Copy link

Hello Thomas, Here's the output from my MPU6050 when not moving. Not sure whether it's behaving correctly (linear_acceleration for Z seems odd???). Thanks, Thomas @.:~$ ros2 topic echo /imu/data header: stamp: sec: 1714345324 nanosec: 757715000 frame_id: imu_link orientation: x: 0.0 y: 0.0 z: 0.0 w: 0.0 orientation_covariance: - 9.999999747378752e-06 - 0.0 - 0.0 - 0.0 - 9.999999747378752e-06 - 0.0 - 0.0 - 0.0 - 9.999999747378752e-06 angular_velocity: x: 0.0 y: 0.0 z: 0.0 angular_velocity_covariance: - 9.999999747378752e-06 - 0.0 - 0.0 - 0.0 - 9.999999747378752e-06 - 0.0 - 0.0 - 0.0 - 9.999999747378752e-06 linear_acceleration: x: -0.5556445550173521 y: 0.8646020877640694 z: 11.045830550603569 linear_acceleration_covariance: - 9.999999747378752e-06 - 0.0 - 0.0 - 0.0 - 9.999999747378752e-06 - 0.0 - 0.0 - 0.0 - 9.999999747378752e-06 ---

On Sun, Apr 28, 2024 at 3:01 PM Thomas Chou @.
> wrote: Hi. I am the maintainer of esp32/pico port. I am new to ROS and robot, too. Your robot is awesome. 1. The required micro-ros serial baudrate for esp32 is 921600 to run the control loop at 50Hz. Would you check the control loop refresh rate with "ros2 topic hz /imu/data" ? It should be close to 50Hz. 2. The orientation of the IMU must be correct. X forward, Y left, Z up. Please check the ACC reading of "ros2 topic echo /imu/data". When the robot is not moving, the reading should be close to 0,0,9.8 . When the robot start to move forward, the accX should be positive. When the robot stop moving forward, the accX should be negative. 3. Have you updated the robot spec in esp32_config.h? WHEEL_DIAMETER,LR_WHEELS_DISTANCE etc. Have you updated the URDF in ros2_ws/src/linorobot2/linorobot2_description/urdf/2wd_properties.urdf.xacro ? 4. I maintain a wiki for linorobot2. Please check https://github.com/hippo5329/linorobot2_hardware/wiki . Cheers, Thomas Chou — Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN3ONSWJVHJSS4PNWBOSCUDY7VBOXAVCNFSM6AAAAABG3AVLCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGYYDENZUGQ . You are receiving this because you authored the thread.Message ID: @.***>

Hey @tbalatka,
Am also facing similar issue, am using IMU5060, and ESP32 Wroom. i have been struggling to solve this issue, let me know once you solve this problem.

@hippo5329
Copy link
Contributor

@aimethierry @tbalatka Hi, I looked into the covariance yesterday, which is important to fuse the sensors. I added parameters to fine tune the covariance. The goal is to fuse the wheel odometry and IMU at some proper "ratio". Please check the latest patches on master branch of my fork and pr-mag.

I would also suggest adding the battery voltage ADC and run the test_acc ( test acceleration). Make sure you have enough space to run the test_acc on the ground. Test_acc will find the limits of the robot motion. Sometime the heavy robot is slower than expected. Then reduce the values in velocity_smoother. The battery voltage drop from surge current of motors should be checked.

Please check the odometry error between the laser scan and map on rviz when the robot turns.

@hippo5329
Copy link
Contributor

hippo5329 commented May 14, 2024

@aimethierry Ubuntu 20.04 and ROS2 FOXY are both EOL. You'd better switch to 22.04 and Humble. Please post photos of your robot, control board and wiring. It is important to have 2K Ohm pull up to 3.3V on the SDA SCL lines. Most MPU6050 has onboard 3.3V LDO regulator. Add low ESR cap to the power.

@aimethierry
Copy link

@aimethierry Ubuntu 20.04 and ROS2 FOXY are both EOL. You'd better switch to 22.04 and Humble. Please post photos of your robot, control board and wiring. It is important to have 2K Ohm pull up to 3.3V on the SDA SCL lines. Most MPU6050 has onboard 3.3V LDO regulator. Add low ESR cap to the power.

Hey @hippo5329 ,
Thank you for a quick reply, this is a the design of my robot,
robot_design

I am unable to transition to ROS2 HUMBLE since my JETSON NANO does not support Ubuntu 22.04. Attached are images of my control board and wiring.

controlBOARD

WIRING_DESIGN

@hippo5329
Copy link
Contributor

hippo5329 commented May 15, 2024

@aimethierry Wow! What a beast. Odrive is very powerful. You don't need an esp32 / linorobot2_hardware. You should connect odrive to jetson with USB CDC. There are ROS2 drivers, such as odrive github or https://github.com/Factor-Robotics/odrive_ros2_control . At the level of cost of your robot, you should use BNO055 and connect it to jetson in UART mode or a serial USB bridge. Mount the BNO055 far away from battery, lidar and motors. There is Armbian 22.04 for jetson nano. https://www.armbian.com/jetson-nano/ . However, I wonder if the nvidia sdk works.

@aimethierry
Copy link

@aimethierry Wow! What a beast. Odrive is very powerful. You don't need an esp32 / linorobot2_hardware. You should connect odrive to jetson with USB CDC. There are ROS2 drivers, such as odrive github or https://github.com/Factor-Robotics/odrive_ros2_control . At the level of cost of your robot, you should use BNO055 and connect it to jetson in UART mode or a serial USB bridge. Mount the BNO055 far away from battery, lidar and motors. There is Armbian 22.04 for jetson nano. https://www.armbian.com/jetson-nano/ . However, I wonder if the nvidia sdk works.

Thank you for your critical feedback. I was considering using micro-ros with ESP32 as it works well. However, calibration of the IMU sensor and robot localization have challenges.

Do you think BN0055 is more promising?

@hippo5329
Copy link
Contributor

I'd never use a BNO055. I see a lot of people using and recommending BNO055. To me, the good point of BNO055 is the UART interface. We can bridge it to USB and mount it at proper location. USB helps to reduce interference. However, a cheap MPU6050 is good enough to do the job.
If you are new to ros2 navigation as I am, I would highly recommend starting with a light-weight and basic robot like I said in the beginning of my wiki. It is a learning tool. It helps to learn the essential. I have been working on this basic part. I won't move to bigger and more powerful robots until I am ready.

@hippo5329
Copy link
Contributor

The issue occurred when turning. There are errors in kinematics computed from wheels movement. The gyro meter yaw is used to correct the error. The EKF filter will fuse the wheels odometry and IMU to reduce the error. The covariance matrix is important. The EKF depends on the covariance matrix to compute the most likely pose of the robot. These are the things which we should check.

  1. decrease the maximum acceleration and velocity in velocity_smoother. F=m * a. The higher mass, the lower acceleration.
  2. reduce the kinematics error.
  3. reduce the IMU noise.
  4. adjust the covariance matrix.

@hippo5329
Copy link
Contributor

I have enabled the calibration of MPU6050. The MPU9250 might be able to use the MPU6050 driver. The MPU9250 integrates AK8963 magnetometer. The magnetometer will help the fusion after calibration. I have described the wiring, calibration and usage in my wiki.

@aimethierry
Copy link

aimethierry commented May 15, 2024 via email

@hippo5329
Copy link
Contributor

Please take a screen shot or video of your rivz.

@aimethierry
Copy link

Please take a screen shot or video of your rivz.

Hey @hippo5329 ,

These are the updates after making some test.

  1. These is my rviz small video [
rviz2.mp4

The tf part makes the robot keep rotating

  1. this is my tf view frames

frames.pdf

3.ros2 topic echo imu/data is giving the following result

header:
stamp:
sec: 1715862350
nanosec: 992000000
frame_id: imu_link
orientation:
x: 0.0
y: 0.0
z: 0.0
w: 0.0
orientation_covariance:

  • 9.999999747378752e-06
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-06
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-06
    angular_velocity:
    x: 0.0
    y: 0.0
    z: 0.027762059852655722
    angular_velocity_covariance:
  • 9.999999747378752e-06
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-06
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-06
    linear_acceleration:
    x: -1.0035132265184075
    y: 0.11256592278368771
    z: 9.515413004672155
    linear_acceleration_covariance:
  • 9.999999747378752e-06
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-06
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-06
    `

@hippo5329
Copy link
Contributor

hippo5329 commented May 16, 2024

@aimethierry Hi,

  1. Does the robot actually move in the video?
  2. the tf frame diagram is not useful.
  3. the IMU linear accel is not calibrated. accel is -1.0,0.1,9.5 while it should be close to 0,0,9.8. Anyways, accel is not used. Only gyro yaw is used.

The EKF (ekf.yaml) takes vx vy yaw of odom/unfiltered and yaw of /imu/data to compute the /odom. Please bringup the robot. Do not move the robot. Check the values of odom/unfiltered. pose.position should be 0,0,0. pose.orientation should close to 0,0,0,1. twist should be all zeros.

Your robot has four wheels. It looks like skid drive. But you have only two motors, right? How do you drive four wheels? What kinematic do you use? Have you tested the motors and encoders? Please post photos of your robot in whole and details.

@aimethierry
Copy link

aimethierry commented May 16, 2024

@aimethierry Hi,

  1. Does the robot actually move in the video?
  2. the tf frame diagram is not useful.
  3. the IMU linear accel is not calibrated. accel is -1.0,0.1,9.5 while it should be close to 0,0,9.8. Anyways, accel is not used. Only gyro yaw is used.

The EKF (ekf.yaml) takes vx vy yaw of odom/unfiltered and yaw of /imu/data to compute the /odom. Please bringup the robot. Do not move the robot. Check the values of odom/unfiltered. pose.position should be 0,0,0. pose.orientation should close to 0,0,0,1. twist should be all zeros.

Your robot has four wheels. It looks like skid drive. But you have only two motors, right? How do you drive four wheels? What kinematic do you use? Have you tested the motors and encoders? Please post photos of your robot in whole and details.

@hippo5329

Thanks for quick reply and constant help,

  1. after moving the robot and stop it the robot, then the tf start acting like in the video
  2. after checking odom/unfiltered i get the same result as you detailed (ros2 topic echo /odom/unfiltered
    `header:
    stamp:
    sec: 1715871216
    nanosec: 114000000
    frame_id: odom
    child_frame_id: base_footprint
    pose:
    pose:
    position:
    x: 0.0
    y: 0.0
    z: 0.0
    orientation:
    x: 0.0
    y: 0.0
    z: 0.0
    w: 1.0
    covariance:
  • 9.999999747378752e-05
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-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.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-05
    twist:
    twist:
    linear:
    x: 0.5
    y: 0.5
    z: 0.0
    angular:
    x: 0.0
    y: 0.0
    z: 0.5
    covariance:
  • 9.999999747378752e-06
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-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.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 0.0
  • 9.999999747378752e-06

`

Yes for the robot i have 4 wheels but am only driving using 2wd.

And this is the my ekf.yaml file

`
ekf_filter_node:
ros__parameters:
frequency: 50.0
two_d_mode: true
publish_tf: true

    map_frame: map             
    odom_frame: odom            
    base_link_frame: base_footprint 
    world_frame: odom 

    #x     , y     , z,
    #roll  , pitch , yaw,
    #vx    , vy    , vz,
    #vroll , vpitch, vyaw,
    #ax    , ay    , az
    odom0: odom/unfiltered
    odom0_config: [false, false, false,
                   false, false, false,
                   true, true, false,
                   false, false, true,
                   false, false, false]

    imu0: imu/data
    imu0_config: [false, false, false,
                  false, false, false,
                  false, false, false,
                  false, false, true,
                  false, false, false]

`

@hippo5329
Copy link
Contributor

@aimethierry
The twist is wrong.
twist:
linear:
x: 0.5
y: 0.5
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.5
They should be all zero when the robot does not move. Your encoders have problem. You have to run the test programs.

@hippo5329
Copy link
Contributor

@aimethierry It looks like a bug in your custom motor/encoder driver. . vy should be zero as the robot can move only in x direction. 0.5 is the speed sent by teleop. It is not the speed read from encoder.

@hippo5329
Copy link
Contributor

@aimethierry It might not worth the effort to debug the custom driver. I would suggest remove the esp32 and connect odrive to jetson via USB CDC as I wrote before. You may connect mpu8250 to I2C bus of jetson after you have the motor controller works. There are ros2 drivers.

@hippo5329
Copy link
Contributor

@aimethierry Connect encoders to the odrive.

@hippo5329
Copy link
Contributor

@aimethierry Better switch to discussion board on my fork to avoid interfere with @tbalatka issue. This is not quite related to linorobot or esp32.

@aimethierry
Copy link

aimethierry commented May 16, 2024 via email

@hippo5329
Copy link
Contributor

https://github.com/hippo5329/linorobot2_hardware/discussions

"issue" is for bug reporting.
"discussion" is for Q&A or anything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants