Monash-Connected-Autonomous-Vehicle / ESDA

Software stack for MCAVs annual IGVC entry
0 stars 0 forks source link

Creating USB symlinks for sensors #62

Open AbBaSaMo opened 4 months ago

AbBaSaMo commented 4 months ago

Overview

3 devices are connected to the computer via USB: the piksi, the dynamixel servo and the Zed2i. Atm the piksi has a config file where you supply it's /dev/ which is something like /dev/ttyUSB0 but this sometimes changes depending on the order that devices are plugged in. Instead, what we want to do is create a symbolic link to the path and use the symbolic link which will be constant.

The Zed2i and servo don't really need this as of now (15/07/24) and so will not be prioritised but for the sake of completeness we can still implement this for them.

Atm the udev rule for the piksi has been written on the hive5 but there are permission issues wherein the symlink group must be dialout but is stuck as root. Additionally, instructions taken to achieve everything must be documented in the project README.md for future replication on other systems

Relevant resources

Acceptance criteria

Todo

AbBaSaMo commented 4 months ago

Doing the following to create predictable usb ref paths

# observe device deets
lsusb

# Bus <num> Device <num>: ID <vendor_id>:<product_id> <product_name>

# create udev to map a UUID to a specified path
sudo nano /etc/udev/rules.d/99-esda-usb.rules

#  Add rules as follows
# SUBSYSTEM=="tty", ATTRS{idVendor}=="<vendor_id>", ATTRS{idProduct}=="<product_id>", SYMLINK+="<custom_name>"

# Then reload the rules
sudo udevadm control --reload-rules
sudo udevadm trigger

# and finally double check it works
lsusb
AbBaSaMo commented 3 months ago

Run ls -a /dev/piksi and make sure the group is dialiout, if not fix it from root to dialout and record the steps taken for future reference

Jiawei-Liao commented 2 months ago

Alternative you guys can try if current method doesn't work

Image

aallendarmawan commented 2 months ago

Today in Ricky's and I's working session, we are able to manually set the group of piksi to dialout, but when unplugging and replugging, the group then resets to root.

At the moment still running into issues writing udev rules to automate the group to dialout but haven't been able to set piksi's group to dialout as of now.

Rikidink commented 2 months ago

Additionally, we were able to assign the group of "ttyUSB0" to dialout but not the /dev/piksi symlink but not sure if this has any effect.

Rikidink commented 2 months ago

/dev/piksi symlink now has dialout group but this fix is a bit hacky:

the udev rule is now:

SUBSYSTEM="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="piksi", GROUP+="dialout", RUN+="/usr/local/bin/piksi_group.sh"

Where piksi_group.sh is a bash script that runs when the udev rule is also run.

#!/bin/bash
sudo chown -h root:dialout /dev/piksi

The piksi_group.sh was given chmod +x piksi_group.sh. Hoping to get a more permanent less hacky fix though.

aallendarmawan commented 2 months ago

@AbBaSaMo @Jiawei-Liao "document steps into the project README.md in a readable format" is this the ESDA README.md? https://github.com/Monash-Connected-Autonomous-Vehicle/ESDA/blob/main/README.md

aallendarmawan commented 2 months ago

We're also wondering about the first point of the acceptance criteria "sensors launch must launch the piksi driver without issue while settings.yaml refers to the piksi symlink for connection as defined in the UDEV rule". How do we test this?

Jiawei-Liao commented 2 months ago

@AbBaSaMo @Jiawei-Liao "document steps into the project README.md in a readable format" is this the ESDA README.md? https://github.com/Monash-Connected-Autonomous-Vehicle/ESDA/blob/main/README.md

Yep its in this readme. Just list down the steps needed to do this symlink as if starting from scratch on a new pc

We're also wondering about the first point of the acceptance criteria "sensors launch must launch the piksi driver without issue while settings.yaml refers to the piksi symlink for connection as defined in the UDEV rule". How do we test this?

You can test this by following the steps in running it in the readme. If it works I think there should be a topic under /navsatfix that outputs messages?

Rikidink commented 1 month ago

Got the piksi driver to work with the symlink. Below are the complete steps taken to make it work.

It turns out that the problem was with a dependency within the piksi driver code. The driver uses the external library "libserialport" to open and configure serial ports but the library didn't support udev defined symlinks until the most recent version (0.1.2). This version can only be downloaded from the github repo and not through the apt-get command.

NOTE: it also seems like it doesn't actually matter if the piksi symlink is in dialout or not so the udev rule will not try and assign to the group.

  1. Create the udev rule to generate the symlink:
    
    # observe device deets
    lsusb

Bus Device : ID :

create udev to map a UUID to a specified path

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

Add rules as follows

SUBSYSTEM=="tty", ATTRS{idVendor}=="", ATTRS{idProduct}=="", SYMLINK+=""

Then reload the rules

sudo udevadm control --reload-rules sudo udevadm trigger


2. Download and build the piksi driver (optional if already installed).
Follow the steps in [this repo](https://github.com/swift-nav/swiftnav-ros2?tab=readme-ov-file#building-driver) EXCEPT the below command in step 4. We will instead install a different version of the libserialport library.
```bash
# DO NOT RUN THIS COMMAND
sudo apt-get install libserialport-dev
  1. Install the appropriate libserialport library (version 0.1.2).

    • Go to the libserialport repo
    • Under "releases" find "libserialport-0.1.2"
    • Download the libserialport-0.1.2.tar.gz file.
    • Extract it:
      tar -xzf libserialport-0.1.2.tar.gz
      cd libserialport-0.1.2
  2. Install the library (more details on the official page: link:

    ./configure
    make
    sudo make install
  3. The piksi driver should now work.