Skip to content

README.md

Latest commit

 

History

History
251 lines (160 loc) · 11.7 KB

README.md

File metadata and controls

251 lines (160 loc) · 11.7 KB

🤖 ORION Base

🌟 Overview

This directory contians the embedded codes for the ESP32s of the ORION robot. They were build by using PlatformIO and C/C++.

To check the robot electronic connections, review the Electronics and Schmatics on the Wiki.

📝 License

The source code is released under a BSD 3-Clause license.

Maintainer: Daniel Felipe López Escobar.

The ORION Commons packages have been tested under ROS Jazzy distribution.

📚 Table of Contents

⚡ µ-ROS codes

The usage of µ-ROS allows a microcontroller, like a ESP32, to be able to work on the ROS 2 ecosystem by using a agent for the communciation, which give the opportunity to work with topics, publishers, subscriber, services, nodes, among others on embedded devices.

For ORION, it has a two ESP32 application, shown as:

  • Actuators: The ESP32 located on the first floor of the robot and that is in charge of the control of the DC motors and servomotors, which is intended to be a base for communicating with a hardware interface of ros2_control that are defined on orion_control. For implementing this, check out the orion_ctl_micro_ros directory.

  • Interaction: The ESP32 on the top floor of the robot manage the screen and touch sensors which are mainly focused on interaction tasks with users. For the implementation, check out the orion_interaction_micro_ros directory.

Uploading the codes

For the embedded codes, it is required to use PlatformIO in your development machine (it can be your Raspberry Pi or you PC), consider the next:

  • VSCode and Platformio Extension: You can use it as an extension in VS Code, it will also install the dependencies and CLI tools, do not forget to check that you have venv installed for using the Python Virtual Environments.

  • CLI Tools only: If you prefer a terminal or you are using a RPi with a server installation for Ubuntu, you can proceed with the next steps:

    1. Make sure pip and venv are installed:

      sudo apt install python3-pip python3-venv

    2. Obtain the installation script:

      wget -O get-platformio.py https://raw.githubusercontent.com/platformio/platformio-core-installer/master/get-platformio.py

    3. Execute the installation script:

      python3 get-platformio.py

With this ready, let's proceed to specify the target of the installation:

  1. Connect both ESP32 to the RPi, determinate which device at /dev is the ESP32 for actuators and the ESP32 for interaction, for example, /dev/ttyUSB0 and /dev/ttyUSB1 respectively.

  2. Identify the attributes of the connection with:

    # Terminal 1
udevadm info --name=/dev/ttyUSB0 --attribute-walk
# Terminal 2
udevadm info --name=/dev/ttyUSB1 --attribute-walk

    And search for elements like:

    ATTRS{idVendor}=="10c4"
ATTRS{idProduct}=="ea60"
ATTRS{serial}=="0001"

    If you do not find them, as the output can be very long, you can use grep:

    udevadm info --name=/dev/ttyUSB0 --attribute-walk | grep idVendor

  3. Create a udev rule file and proceed to add the elements:

    sudo nano /etc/udev/rules.d/99-usb-serial.rules

    Inside of the file, add the next (based on your outputs):

    SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="0000", SYMLINK+="ttyESP32_1"
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c5", ATTRS{idProduct}=="ea61", ATTRS{serial}=="0001", SYMLINK+="ttyESP32_2"

  4. (Optional) If your attributes are the same for both ESP32 (probably they are from the same production slot), do not worry, you can use environmental attributes, this isn't recommended as they may change if you change the ESP32 of position or connect all the devices different, so keep this in mind. For this you can use:

    udevadm info --name=/dev/ttyUSB0 | grep ID_PATH
udevadm info --name=/dev/ttyUSB1 | grep ID_PATH

    Then create custom rules for this purpose, like:

    SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3.1:1.0", SYMLINK+="ttyESP32_1"
SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3.3:1.0", SYMLINK+="ttyESP32_2"

    NOTE: Avoid to generate rulse that may end adding the same name / symlink to multiple devices as this can mess up the robot software and the system of the RPi itself.

  5. Update the udev rules.

    sudo udevadm control --reload-rules
sudo udevadm trigger

  6. Check that the rules have been updated.

    ls -al /dev | grep USB
# Should output the /dev/ttyUSB devices and the symbolic links for the ESP32_1 and ESP32_2

Once the ESP32 naming has been done, we can proceed with the upload:

  1. Give the proper permissions to the devices.

    sudo chmod 777 /dev/ttyESP32_*
sudo chmod 666 /dev/ttyUSB0 # Or your first ESP32 port
sudo chmod 666 /dev/ttyUSB1 # Or your second ESP32 port

  2. Go to the PlatformIO workspace of you application.

    # In case you are using VS Code
code /path/to/orion_ctl_micro_ros
# or
code /path/to/orion_interaction_micro_ros
    # In case you just want the terminal
cd /path/to/orion_ctl_micro_ros
# or
cd /path/to/orion_itneraction_micro_ros

  3. Install the depdencies.

    In the case of VS Code, go to the platformio.ini file and save (Ctrl+S), it should start the configuration of the PlatformIO extension.

    # In case of terminal, use:
pio lib install
# or
platformio install

  4. Build the content.

    In the case of VS Code, press the Build button.

    # In case of terminal, use:
pio run
# or
platformio run

  5. If the building is successfully completed, upload (it will use the targets on the **platformio.ini). Otherwise, review the error before uploading the code.

    In the case of VS Code, press the Upload button.

    # In case of terminal, use
pio run --target upload
# or
platformio run --target upload

    NOTE: You may require to pulse the BOOT button if the upload seems to get stuck when recognizing the device.

    esp32_buttons

Known issues

  • µ-ROS agent not linking with the program: With the implementation provided, the ESP32 waits up to 2 minutes to connect with the µ-ROS agent. Otherwise, it will continue and will require a manual restart by using the EN button on the ESP32 which may cause problems as you may need to dismoun some of the robot walls to access to it. You can use the following alternatives:

    • Disconnect the ESP32 while the agent is active, when it restart it may be able to connect again.
    • Close the agent, reupload the code to the ESP32 and open the agent again.

  • ROS_DOMAIN_ID != 0: You communication with µ-ROS may not be possible if you are using a different ROS_DOMAIN_ID as it uses the default value (0) for it.

⚡ Serial codes

This implementation aims for the usage of serial communication with ESP32 as an alternative to the usage of µ-ROS.

This will be updated in the future.

⚠️ Trouble shooting

Screen flickering

This may be caused by two reasons:

  • NC pin that requires connection: In some models of the TFT ILI9225 Screen there is a NC (Not connected) pin that is really a LED pin which is related to the brightness of the screen, and if it is not connected it will produce the flickering.

  • Bad connection of the screen: Another reason can be a bad connection on the SPI ports when loading the code, as it may lead to send the information in the wrong pins, so double check the connection. Also, if you connected the screen in a wrong way, disconnect it and try it alone to check it still works as if you messed with the power supply ports it may broke.

You can check more info of the screen on TFT 22 ILI9225 Wiki.

Robot moving the in the wrong direction

This may be caused by the wiring of the motor according to its manufacturer or a mismatch in the cable connection. However, you do not require to dissambly the robot, you can go to the hardware constants and exchange the values.

For thsi purpose try to exchange the values of the Forward and Backward pins, do the test for each wheel individually to ensure the movement, you can even run the µ-ROS code and use the instructions in orion_ctl_micro_ros to move the motors manually.

Feedback of wheel rotation is inverse

Teh encoder lecture should increase when the wheels move forward, and dicrease otherwise. If the direction is wrong when checking RViz2 while the ros2_controllers are active or you read the output of the encoder of each motor and it is not the expected increment/decrement, go to hardware constants and exchange the encoder channels (A and B) pins and do a test.

Robot is going too fast

If the robot goes really fast it can mess the SLAM applications and Navigation, in case the default velocity PWM limit isn't enough, you can manually change it in the file motor.hpp in the constant attribute MAX_SPEED.

/dev/ttyESP32_n not found

This is caused as the ESP32 connection wasn't updated with the proper udev rules, check this above as the names managed are used in the bringup, the robot startup service and PlatformIO set ups.

The reasons you can consider for this are:

  • You changed the eSP32 and the attributes are therefore differnt.
  • You are using environmental attributes, like ID_PATH, and changed the order connecttions.
  • The device isn't connected, so the udev rules isn't applied. Check the cable and the element in case they are damaged.

/dev/ttyESP32_2 not uploading program

One possible reasons is the connections on the ESP32_2 (for interaction purposes), as the lower right touch sensor is mounted on the GPIO2. If the sensor is pressed while uploading the program, it may fail as in the documentation of the ESP32 Doit Dev Kit you have to avoid HIGH values on that pin in startup / uploading.

More info on ESP32 Pinout | Last Minute Engineering