** This repo is deprecated and read-only **

** Please use ess_imu_driver instead **

README for Epson IMU Driver using UART interface for ROS

• README for Epson IMU Driver using UART interface for ROS
  • What is this repository for?
  • What kind of hardware or software will I likely need?
  • How do I use the driver?
  • How do I use the driver if usleep() is not supported for time delays?
  • How do I use the driver with GPIOs to control IMU RESET#, DRDY, EXT pins?
  • How do I build, install, run this ROS1 package?
    • Example console output of catkin_make build for G366PDG0:
    • Example console output of launching ROS1 node for G366PDG0:
  • What does this ROS1 IMU Node Publish as messages?
    • Without Quaternion Output
      • ROS Topic Message data_raw
    • With Quaternion Output
      • ROS Topic Message data
  • Why am I seeing high latencies or slower than expected IMU data rates when using USB-UART bridges?
    • Modifying latency_timer by sysfs mechanism
    • Modifying low_latency flag using setserial utility
  • Package Contents
  • License
  • References

What is this repository for?

• This code provides interface between Epson IMU and ROS using the UART interface.
• The UART connection can be either direct or by USB-serial converter such as FTDI bridge ICs.
• The src/epson_imu_uart_driver_node.cpp is the ROS C++ wrapper used to communicate with ROS
• The other source files in src/ are based on the Linux C driver originally released by Epson: Epson IMU UART-only Linux User-space Driver Example
• Information about ROS, ROS packages, and tutorials can be found: ROS.org

What kind of hardware or software will I likely need?

This will likely require the following:

• Epson USB evaluation board or equivalent FTDI USB-Serial interface to connect to ROS host (tty/serial) See Evaluation Boards
• Epson IMU (G320/G330/G354/G364/G365/G366/G370/V340) IMU models
• ROS Indigo or later (via download) ROS.org

How do I use the driver?

• This code assumes that the user is familiar with building ROS packages using the catkin build process.
• NOTE: This is NOT detailed instructions describing step by step procedures on how to build and install this ROS driver.
• Please refer to the ROS.org website for more detailed instructions on configuring the ROS environment & the ROS package build process. ROS.org
• NOTE: At bare minimum, you must modify the CMakeLists.txt, or any time you change to a different IMU model, then build this package running “catkin_make”.
• If the IMU model is unchanged, then subsequent changes to IMU settings can be done by instead editing the IMU model specific .launch file located in the launch/ folder.
• The IMU model specific launch file should only be used in conjunction with the same catkin-built executable of the same matching the IMU model.
• NOTE: Do not just switch .launch files without modifying the CMakeList.txt & rebuilding the executable to match the IMU model. Do not mix IMU model launch files without the matching IMU model catkin built binaries.

How do I use the driver if usleep() is not supported for time delays?

• NOTE: In the hcl_linux.c, there are empty functions for time delays in millisecond and microseconds using seDelayMS() and seDelayMicroSecs(), respectively.
• On embedded Linux platforms, the user may need modify and redirect to platform specific delay routines if usleep() is not supported.
• For example on RaspberryPi, the time delay functions for millisecond and microseconds can be redirected to WiringPi library delay() and delayMicroseconds(), respectively.
• If a hardware delay is not available from a library, then a software delay loop is possible but not preferred.

How do I use the driver with GPIOs to control IMU RESET#, DRDY, EXT pins?

• Because this driver connects to the IMU using the UART interface, the use of GPIO pins for connecting to the IMU RESET#, EXT, or DRDY is purely optional, and mainly intended for embedded Linux platforms (non-PC based).
• When possible, connecting the RESET# is recommended to force Hardware Reset during every IMU initialization, for better robustness.
• Although this code does not implement GPIO functions, this code is structured for the user to easily redirect GPIO control to low-level hardware GPIO function calls for ease of implementation.
• There is no standard method to implement GPIO connections on embedded Linux platform, but the following files typically need changes:

  src/hcl_linux.c
  src/hcl_gpio.c
  src/hcl_gpio.h

• Typically, an external library needs to be invoked to initialize & enable GPIO HW functions on the user’s embedded platform.

• This typically requires changes to hcl_linux.c

  • add #include to external library near the top of hcl_linux.c
  • add the initialization call inside the seInit() function in hcl_linux.c

For example on an Raspberry Pi, the following changes can be made to hcl_linux.c:

``` …

#include #include #include // <== Added external library

int seInit(void) { // Initialize wiringPi libraries // <== Added printf(“\r\nInitializing libraries…”); // <== Added if(wiringPiSetupGpio() != 0) { // <== Added external library initialization printf(“\r\nError: could not initialize wiringPI libraries. Exiting…\r\n”); // <== Added

File truncated at 100 lines see the full file