Agent does not start on Pi 4 UART5

Arnatious commented 3 years ago

Issue template

Hardware description: Raspberry Pi Pico running micro_ros, RPi 4B+ running Ubuntu 20.04
RTOS: N/A
Installation type: micro_ros_setup
Version or commit hash: 003cb38ef (Current foxy HEAD)

Steps to reproduce the issue

Install Ubuntu 20.04 on Pi 4
Install ROS 2 Foxy, build the micro_ros_agent using the setup script.
Enable UART5 in /boot/firmware/usercfg.txt (add dtoverlay=uart5 to file) and reboot
Connect Pi 4 to pico using UART5 pins: GPIO 12/13
Adjust the example in the micro ROS pico sdk https://github.com/micro-ROS/micro_ros_raspberrypi_pico_sdk/ to use UART instead of USB (flip booleans in https://github.com/micro-ROS/micro_ros_raspberrypi_pico_sdk/blob/74a9028e795ad6fd6fe7a885ec3e4bc849a7e2d2/CMakeLists.txt#L29-L30)
Program the pico using USB or SWD
(Optional) set ownership of UART5 serial port (e.g. /dev/ttyAMA1)
Verify serial communication is occuring using minicom: minicom -b 115200 -o -D /dev/ttyAMA1 - can see micro ros comms

Expected behavior

Starting micro_ros_agent using ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyAMA1 -v6 starts and connects the agent.

Alternatively, if configuration steps are missing,

[1620270716.773237] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1620270716.773929] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 6

or similar prints followed by an error message

Actual behavior

Agent produces no text output and never connects. Connection on the pico end times out.

Additional information

[1620270716.773237] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1620270716.773929] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 6

does appear if minicom is open in another window on the same port, but the device still never connects to the pico. Closing minicom reverts to the aforementioned behavior.

Configuration steps may be missing? I'm not terribly familiar with the steps for serial comms on Linux. It appears the agent defaults to using a baud of 115200, which is correct, and checking with stty -F /dev/ttyAMA1 shows this setting is set by minicom and persists after minicom closes, so the above behavior doesn't line up.

pablogs9 commented 3 years ago

Verify serial communication is occurring using minicom: minicom -b 115200 -o -D /dev/ttyAMA1 - can see micro ros comms

Can you share the output of this?

Arnatious commented 3 years ago

Verify serial communication is occurring using minicom: minicom -b 115200 -o -D /dev/ttyAMA1 - can see micro ros comms

Can you share the output of this?

@pablogs9 in hex output mode:

7e 00 00 10 00 80 00 00 00 02 01 08 00 00 09 ff fd 02 00 00 00 fc 12

Repeated until the ping times out.

pablogs9 commented 3 years ago

Try to remove:

rcl_ret_t ret = rmw_uros_ping_agent(timeout_ms, attempts);

    if (ret != RCL_RET_OK)
    {
        // Unreachable agent, exiting program.
        return ret;
    }

and just init the micro-ROS RCLC.

pablogs9 commented 3 years ago

Any update on that?

Arnatious commented 3 years ago

Update: the issue appears to be centered around minicom. While using minicom does work, it seems to not clean up after itself and will leave in such a state that the agent will not display any output and hang when attempting to access the device if started after minicom.

Using screen to view the device seems to be safe, and interestingly, will fix the device so the agent will subsequently start up like normal. This is a workaround, but does not address what minicom does that conflicts with the agent.

micro-ROS / micro-ROS-Agent