@Moderator Yep, I got routing through the VOXL2 working. The problem was actually in my host and the device I was pinging. I would have to setup static routing on both devices. But I ended up using a NAT on the VOXL2
Thank you for the help!
@Moderator Yep, I got routing through the VOXL2 working. The problem was actually in my host and the device I was pinging. I would have to setup static routing on both devices. But I ended up using a NAT on the VOXL2
Thank you for the help!
Good afternoon,
For the past few days, I have been running around in circles trying to make it so my computer with a microhard can ping a device connected to the voxl2 via Ethernet.
Essentially, I have a camera connected to the VOXL2 via Ethernet and the microhard is on usb0. This camera hosts it's own rtsp stream, and does not need to be streamed from the voxl2. From my host computer, I want to be able to connect to the camera connected to the voxl2 and directly ping it's IP. I know to do this, I need to have the VOXL2 route from usb0 to eth0 in some way to make it so when the GCS pings the camera's ip, it goes through the usb0 interface to eth0.
I am pretty new overall to networking, so please correct me if my idea is wrong.
bond0: flags=5123<UP,BROADCAST,MASTER,MULTICAST> mtu 1500
ether 0e:ae:7a:d3:cb:54 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500
inet6 fe80::aee5:90ba:7fd5:a0ed prefixlen 64 scopeid 0x20<link>
ether f2:fa:36:1f:17:83 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 15670 (15.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.144.21 netmask 255.255.255.0 broadcast 192.168.144.255
ether 5c:85:7e:3e:94:33 txqueuelen 1000 (Ethernet)
RX packets 2577 bytes 154620 (154.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 83 bytes 21341 (21.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 95 bytes 8224 (8.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 95 bytes 8224 (8.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.168.100 netmask 255.255.255.0 broadcast 192.168.168.255
inet6 fe80::3b33:ef4a:4410:1470 prefixlen 64 scopeid 0x20<link>
ether 96:dc:72:9d:a5:01 txqueuelen 1000 (Ethernet)
RX packets 5661 bytes 324594 (324.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3874 bytes 456769 (456.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The first thing I did was enable forwarding on the VOXL2 by uncommenting this line on /etc/sysctl.conf
net.ipv4.ip_forward=1
Then I tried pinging the device from my home computer while connected via microhard.
From my home computer:
I was able to ping 192.168.168.100, which is expected since that is the microhard.
I was able to ping 192.168.144.21 which is the eth0 interface.
However, I have been unable to ping 192.168.144.52, which is the address of the camera, despite being able to ping it successfully on the VOXL2.
john@john-desktop:~$ ping -R 192.168.168.100
PING 192.168.168.100 (192.168.168.100) 56(124) bytes of data.
64 bytes from 192.168.168.100: icmp_seq=1 ttl=64 time=3.06 ms
RR: 192.168.168.146
192.168.168.100
192.168.168.100
192.168.168.146
64 bytes from 192.168.168.100: icmp_seq=2 ttl=64 time=3.59 ms (same route)
64 bytes from 192.168.168.100: icmp_seq=3 ttl=64 time=2.68 ms (same route)
64 bytes from 192.168.168.100: icmp_seq=4 ttl=64 time=3.31 ms (same route)
^C
--- 192.168.168.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.680/3.159/3.585/0.332 ms
john@john-desktop:~$ ping -R 192.168.144.21
PING 192.168.144.21 (192.168.144.21) 56(124) bytes of data.
64 bytes from 192.168.144.21: icmp_seq=1 ttl=64 time=3.14 ms
RR: 192.168.168.150
192.168.144.21
192.168.144.21
192.168.168.150
64 bytes from 192.168.144.21: icmp_seq=2 ttl=64 time=2.81 ms (same route)
64 bytes from 192.168.144.21: icmp_seq=3 ttl=64 time=2.99 ms (same route)
64 bytes from 192.168.144.21: icmp_seq=4 ttl=64 time=2.84 ms (same route)
64 bytes from 192.168.144.21: icmp_seq=5 ttl=64 time=2.85 ms (same route)
64 bytes from 192.168.144.21: icmp_seq=6 ttl=64 time=2.77 ms (same route)
^C
--- 192.168.144.21 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5009ms
rtt min/avg/max/mdev = 2.771/2.900/3.137/0.126 ms
I've tried changing the routing table to allow for connections over usb0 that point to 192.168.144.52 to go over eth0, but I haven't had luck. I am unsure if there is something I'm doing wrong here.
Here is my routing table:
voxl2:/etc/modalai$ ip route
default via 192.168.168.1 dev usb0 src 192.168.168.106 metric 209
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.208.31 metric 208
192.168.144.0/24 dev eth0 proto kernel src 192.168.144.21 metric 202
192.168.168.0/24 dev usb0 scope link src 192.168.168.100
I've also tried this routing table to enforce that we should be routing pings to 192.168.144.52 to eth0 :
default via 192.168.168.1 dev usb0 src 192.168.168.106 metric 209
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.208.31 metric 208
192.168.144.0/24 dev eth0 proto kernel scope link src 192.168.144.21
192.168.144.52 dev eth0 scope link src 192.168.168.100
192.168.168.0/24 dev usb0 scope link src 192.168.168.100
The outcome is the same when changing the routing table. However, I know that changing the routing table is doing SOMETHING because if I remove all eth0 entries, I cannot ping any eth0 device.
Am I thinking of this wrong? Is there anything I should try? Does the VOXL2 handle routing differently, or is there anything custom going on?
@Alex-Kushleyev I mean, since it is a static service, disabling it does not actually disable it. It appears to do nothing. Upon rebooting, adb still works
I was able to "disable adb" by simply changing the name of the adbd executable to .adbd
@Alex-Kushleyev Thank you for the advice.
Since adbd is a static service (the usb service depends on it), it cannot be disabled through a systemctl disable.
I am going to take a look at other methods to disable it.
Tried what that article suggested and did some research. I think adb encryption is not a feature on adb daemon for linux devices, and is only available on actual android devices. I could be wrong, but it appears that way. Could also be a feature on newer adb daemon.
Regardless, I think it might be possible for me to open up a USB port on an extension board for ssh. That way I could have password protected serial access while having adb disabled. Am I wrong in thinking this?
Good afternoon,
I was wondering if there was a built-in method to require the user to input a password or have a correct adb encryption key to ADB into the VOXL2.
I could not find documentation relating to this on ModalAI website, and a lot of advice online seems to be only applicable to android devices.
Is there an area on the VOXL2 where the adb server is hosted so I can tinker around with it? Or is the adb functionality baked into the firmware itself?
The goal is to make the system more secure by only allowing authorized users to adb in.
If there is no way to require a password for adb on the VOXL2, is there a way to disable adb?
I have been able to change the ssh password which is nice.
Thank you,
John Nomikos.
Thank you so much, that forum post basically describes the exact same issues I was running into. Going to test it out soon and see if that fix works on my end.
Yeah we always used attenuators and/or had long range. And I've tested this with like 5 different doodle radios and they all gave the same results
Good afternoon,
In the last month, I have been integrating doodle radios onto the VOXL2. There is one problem that is always consistent. Whenever I connect to the VOXL2 with the doodle radio on SDK 1.0 or 1.1, the connection will fail to complete. It will start connecting, freeze in the middle, take like 10 extra seconds, and then give "Parameters failed to download" errors on QGC. Sometimes it will successfully connect, but it takes minutes, and after it does, MAVLink appears to be very "choppy". As an example, if I move the VOXL2 around, the compass indicator will show it moving, but it is super laggy.
On QGC when I go to application settings -> Mavlink, I observe that the messages sent and received constantly freeze every second. The loss rate is only around 3% though.
This issue does not appear on 0.9.5. This issue also does not appear on 1.0 or 1.1 if I switch from using voxl-mavlink-server to mavlink-router (well the download stopping on QGC after taking too long does not appear. But it still takes forever to load up on QGC using mavlink-router).
This issue appears to be specific to doodle radios. I do not see similar problems when using a Microhard or WIFI adapter.
Moreover, this problem happens regardless of the bitrate between the radios. I've observed 30-50 mbps bitrate between the radios with a stable video stream, and still connection issues.
I know this problem isn't related to the bitrate being too high, because I've successfully connected to the VOXL2 via ethernet with no issues.
I did not observe any errors on voxl-mavlink-server or voxl-vision-hub. I also have the default configuration settings with both, but have toyed around a bit to try to see if this is a configuration issue.
I have observed this issue both with and without an external flight controller. The consistent thing is the doodle radio being in the equation and MAVLink being "choppy". My instinct is that the doodle is causing the issues here, but I am not sure because 0.9.5 works well. It loads up super fast when I am on 0.9.5 and MAVLink does not appear choppy.
Here is my voxl-mavlink-server config on 0.9.5:
/**
* voxl-mavlink-server Configuration File
* UART fields are for APQ8096 VOXL1 or QRB5165 VOXL2 with external fc
* UDP fields are for PX4 on SDSP on QRB5165 only
* External FC field is for QRB5165 only. Set to true to enable UART
* communication to an external flight controller, otherwise a UDP interface
* will be started to talk to voxl-px4 on localhost which is the default behavior.
*
*/
{
"px4_uart_bus": 1,
"px4_uart_baudrate": 921600,
"udp_port_to_px4": 14556,
"udp_port_from_px4": 14557,
"external_fc": false
}
Here is it on 1.1.0
/**
* voxl-mavlink-server Configuration File
*
* primary_static_gcs_ip & secondary_static_gcs_ip
* These configure voxl-mavlink-server to automatically try to connect to
* up to two known static GCS units. Set to empty or NULL if you don't want
* to use this and you want the GCS to initialize the connection instead.
* Note the default IP for the primary link is 192.168.8.10 which is the
* first IP that VOXL DHCP serves when connecting in wifi softap mode.
*
*
* Settings for running voxl-px4 on SLPI:
* onboard_port_to_autopilot - UDP port to send high-rate onboard data to SLPI
* onboard_port_from_autopilot - UDP port to receive high-rate onboard data from SLPI
* gcs_port_to_autopilot - UDP port to send normal-rate gcs data to SLPI
* gcs_port_from_autopilot - UDP port to receive normal-rate gcs data from SLPI
*
* Settings for running an external autopilot connected via UART:
* en_external_uart_ap - set to true to enable an external flight controller
* autopilot_uart_bus - uart bus, default 1 for VOXL2
* autopilot_uart_baudrate - default 921600
* en_external_fc_timesync - enable responding to timesync messages
* (enabled by default)
* en_external_ap_heartbeat - enable automatic sending of heartbeat
* gcs_timeout_s - time without heartbeat to consider GCS disconnected
*
* udp_mtu - maximum transfer unit for UDP packets back to GCS. voxl-mavlink-server
* will bundle up backets for the GCS into a single UDP packet with
* a maxium size of this. This saves network traffic drastically.
* Set to 0 to disable this feature and send one UDP packet per msg.
*
*
* External FC field is for QRB5165 only. Set to true to enable UART
* communication to an external flight controller, otherwise a UDP interface
* will be started to talk to voxl-px4 on localhost which is the default behavior.
* Select UART port 1 to go through the legacy B2B connector, that's the port exposed by the
* M0125 and M0141 accessory boards. Use port 12 to go through the ESC port (J18).
*
*/
{
"primary_static_gcs_ip": "192.168.8.10",
"secondary_static_gcs_ip": "192.168.8.11",
"onboard_port_to_autopilot": 14556,
"onboard_port_from_autopilot": 14557,
"gcs_port_to_autopilot": 14558,
"gcs_port_from_autopilot": 14559,
"en_external_uart_ap": false,
"autopilot_uart_bus": 1,
"autopilot_uart_baudrate": 921600,
"en_external_ap_timesync": 1,
"en_external_ap_heartbeat": 1,
"udp_mtu": 4000,
"gcs_timeout_s": 4.5
}
The annoying thing is that OCCASIONALLY, on SDK 1.0 and above, it connects fine on QGC without stalling. So it is really hard for me to tell if this is a radio problem or a VOXL2 problem. Moreover, I've observed this problem on every doodle I've worked on.
Good afternoon!
I was running into an odd issue where I could not successfully connect to an RTSP stream on sdk 1.0.0. It seems like it kept adding clients repeatedly and disconnecting them when I tried connecting. I tried this on both VLC and QGC and the output was the same:
Mar 02 13:05:33 m0054 voxl-streamer[1803]: A new client has connected to the RTSP server
Mar 02 13:05:33 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:45922(null) has connected
Mar 02 13:05:33 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 1Camera server Connected
Mar 02 13:05:37 m0054 voxl-streamer[1803]: A new client has connected to the RTSP server
Mar 02 13:05:37 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:45938(null) has connected
Mar 02 13:05:41 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 2A new client has connected to the RTSP server
Mar 02 13:05:41 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:44512(null) has connected
Mar 02 13:05:45 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 3A new client has connected to the RTSP server
Mar 02 13:05:45 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:44522(null) has connected
Mar 02 13:05:49 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 4A new client has connected to the RTSP server
Mar 02 13:05:49 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:44534(null) has connected
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 5A new client has connected to the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:43914(null) has connected
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 6An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 5An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 4An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 3An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 2An existing client has disconnected from the RTSP server
I switched back to 0.9.5 and was able to successfully connect without running into this issue. Makes me suspect that some change in voxl-streamer might be causing this. Also, I did not copy the last line of this, but I remember client 1 also disconnected from RTSP server as well as the rest.
I don't know if it is expected to have multiple clients connect when trying to connect once.
Next week, I'm going to try flashing platform 1.0.0 again to see if I run into the same problem on a different VOXL2.
Any help would be much appreciated!
Best regards,
John Nomikos