Doc Bug: Connecting to Systems (Vehicles) · MAVSDK Guide
hamishwillee opened this issue · 7 comments
@JonasVautherin This problem has come up a few times - people do not know how to format the strings, and all our examples use SITL.
What we need to do is add connection string info for common cases. Probably in Connecting to Systems (Vehicles) · MAVSDK Guide, and either linked or reproduced in http://mavsdk-python-docs.s3-website.eu-central-1.amazonaws.com/#run-the-examples
Also add the info about how you can get it on linux using dmesg.
Some of the options to cover:
- Linux computer connected to the vehicle via Serial port - presumably for a companion like RaPi? - "serial:///dev/ttyACM0" [as above - do we need these three forward slashes at start?]
- Linux computer via USB - "serial /dev/ttyUSB0"? [Can we see this via dmesg?]
- SITL connected to the vehicle via UDP -
- SITL connected to the vehicle via TCP -
- OSX computer connected to the vehicle via USB -
- Windows computer connected to the vehicle via USB (in this case on COM1) |- ?
- Windows computer connected to the vehicle telemetry radio?
- Any more.
Upshot, let's have a link that people can find this one.
Can you fill in the table, and show me an example output of using dmesg?
@hamishwillee, thanks for opening this issue. Being a noob, I was having trouble connecting to an actual drone (as opposed to the SITL). This issue and the links above were all I could find, but were not very clear. After a few hours of trial and error, I made the connection. I think an example using a live drone over telemetry would be helpful. In the mean time, anyone who is trying to connect using Python and Windows 10 the syntax is:
await drone.connect(system_address="serial:///COMn") where n = your COM port
the three slashes is where I got tripped up.
the three slashes is where I got tripped up.
Oh! That's a bug. It should be 2 slashes, on Linux it's 3 because the path starts with a slash.
a-ha, seemed odd, but I'm a hardware guy just learning to code, so it could have been a smiley face for all I know. :)
@julianoes Can you guys show me what each of the above should be: #206 (comment) so I can integrate this as a table?
So for windows I assume you will fix the bug and it will be ...
| Connection type | String |
|---|---|
| Windows connected to the vehicle via USB (includes USB-connected Telemetry radios). | serial://COMn, where n = the COM port (e.g. serial:///COM1) |
@hamishwillee I think it's still serial:///COM1 until we fix it.
(I'm hoping to get back to this soon).
@julianoes @JonasVautherin So I updated the table. Is this correct?
| Connection type | String |
|---|---|
| Windows connected to the vehicle via USB (includes USB-connected Telemetry radios). | serial:///COMn, where n = the COM port (e.g. serial:///COM1) |
| Linux (e.g Raspberry Pi) connected to the vehicle via Serial port | serial:///dev/ttyACMn, where n = the port (e.g. serial:///dev/ttyACM0) |
| Linux connected to the vehicle via USB | serial:///dev/ttyUSBn, where n = the port (e.g. serial:///dev/ttyUSB0) |
| SITL connected to the vehicle via UDP | udp://:14540 |
I'd like to integrate this. Can you confirm:
- I think we don't support TCP connections for SITL, so no need for "SITL connected to the vehicle via TCP"
- How are ports reference in macOS? Same as linux for USB and serial ports?
- are there any other cases.
Thanks @hamishwillee.
I think we don't support TCP connections for SITL, so no need for "SITL connected to the vehicle via TCP"
Correct.
How are ports reference in macOS? Same as linux for USB and serial ports?
I think they are usually /dev/tty.usbserial-... or /dev/tty.usbmodem-...