I don’t know the details of the pixhawk. No doubt there is a specified setup for the serial port. If that setup is speed 115200, 8-bit, no parity, and one stop bit, then the defaults won’t need to be changed. If the physical wires used are to the pins normally used for serial console, then you will have to disable serial console (after which you have an ordinary port running by default at 115200 8N1).
On the Jetson side, assuming you use one of the integrated serial ports, any use of the UART after being fully booted would normally be one of the “/dev/ttyTHS*” files (which is really a driver interface). Optionally, sometimes a legacy port would be used, which is one of “/dev/ttyS*” (same hardware, different drivers).
I don’t know which driver interface (which “/dev/ttyTHS” or “/dev/ttyS” file) goes with which pins on the Jetson. However, if you know which file your software talks to at the Jetson end, just run “ls -l” against that file and see if it is group dialout (in which case you are in luck), or if it is group tty (in which case you must disable serial console).
If you need to disable serial console (and this is a very useful thing for debugging and other purposes, I would not disable it unless you truly need to do so), then do this:
sudo systemctl stop nvgetty.service
sudo systemctl disable nvgetty.service
Please note that this disables serial console within Linux, but boot stages might still have output during boot stages (boot is its own operating system).
That video is showing use of the Seeed Studio carrier board, which is not a dev kit. I don’t know the details of that carrier board, and some carrier boards use the same electrical layout as the dev kit, which would mean they use the same device tree, but many third party carrier boards use a different device tree. There are times when one changes a serial port via device tree (in addition to the nvgetty.service), so this might be part of the final answer. If you are using a true developer’s kit, versus a third party carrier board (such as Seeed) it is important to state that.
FYI, some serial ports use hardware flow control, which is what the video’s CTS and RTS wires are. By default Jetsons do not use this, which is why he is able to cut the CTS and RTS wires (one would typically change the device tree if you want to enable CTS/RTS flow control). He is able to cut the +5V wire because the UART is self-powered at the Jetson end. This leaves only the ground, TX, and RX wires. All of the exposed UART ports have a ground, TX, and RX, and the software setup is all that differs. I don’t know which device special file (“/dev/ttyTHS*”) to use, but it depends on which pins are connected to. The typical pin 9 and 10 plus ground is normally serial console on a dev kit, so I am betting you need to disable nvgetty.service to cause the permissions of the device special file to revert from group tty to group dialout.
And remember, if you talk to device special file as a regular user (versus sudo root), then this is when you need to add your user to the group dialout. To illustrate, if your user name is “nvidia”, then one would add group dialout to user nvidia as a supplemental group via:
sudo usermod -aG dialout nvidia
