@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
Posts made by John Nomikos
-
RE: Require Password (or encryption key) to ADB into VOXL2
-
RE: Require Password (or encryption key) to ADB into VOXL2
I was able to "disable adb" by simply changing the name of the adbd executable to .adbd
-
RE: Require Password (or encryption key) to ADB into VOXL2
@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.
-
RE: Require Password (or encryption key) to ADB into VOXL2
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?
-
Require Password (or encryption key) to ADB into VOXL2
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.
-
RE: Problems connecting to VOXL2 with Doodle Radio on SDK 1.0 and 1.1, but not 0.9.5
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
-
Problems connecting to VOXL2 with Doodle Radio on SDK 1.0 and 1.1, but not 0.9.5
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.
-
Issue connecting to voxl-streamer RTSP stream on sdk 1.0.0
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
-
RE: Issue With VOXL 2 When Connected To Microhard Modem Add-on
Hello @Vinny
Seems like the issue was a mixture of both things. Because there were times when the microhard was 100% touching J5 and that was the issue, but our cables are also finnicky, and cause problems as well. The solution was to make sure the microhard was not touching J5, and to mess with the MCBL wire a bit.
Thank you for the help, I very much appreciate it.
John Nomikos.
-
RE: Issue With VOXL 2 When Connected To Microhard Modem Add-on
Hi Tom,
It could very well be the issue. I am aware of that problem, and I have 3 separate of those cables that I was trying, but perhaps all of them could be faulty. What is interesting is the fact that this restarting only happens after I have the microhard add-on attached. It is strange that there are no restart loops without it attached at all.
-
Issue With VOXL 2 When Connected To Microhard Modem Add-on
Good afternoon,
Recently, I have been trying to get a microhard modem attached to our VOXL 2. I have the M0048 add-on that works on the VOXL 1. But there is an interesting issue when I plug it into the VOXL 2. The VOXL 2 will constantly reboot, and the modem will as well, which makes me unable to adb in or do anything. But, when I don't have the add-on attached, there are no issues. The interval that the VOXL 2 restarts is very regular, and there is a weird (but annoying) method I've discovered to get it to work. Sometimes, if you plug in the USB-C at the exact moment before the VOXL 2 restarts, it won't restart and you can adb in and stuff. But after I turn the VOXL 2 off and on again, the issue will come back.
I was thinking maybe this could be a hardware issue with the specific VOXL 2 that I have. So I tried it on a different VOXL 2. Same problem. Then I thought maybe it was the add-on. I tried multiple different microhard add-ons (all M0048) and the same thing happened. One of the add-ons had a microhard attached to it, another didn't. But the same thing happened.
As a note, the voxl-platform on the main VOXL 2 I use is 0.9, and the other one I tested it on was 1.3, so I don't think it's a problem with the platform.
Also, sometimes, it just randomly works and doesn't restart, but the problem comes back after a little bit.
As another note, there are no other components on this VOXL 2. It is just the board and the microhard.
I am wondering if the microhard board is supported on the VOXL 2. If not, are there any alternatives I can try to get microhard working on the board?
After doing some digging, I think this might be the same issue: https://forum.modalai.com/topic/1273/voxl2-resetting-microhard-usb-chip-after-disconnecting-all-downstream-devices?_=1673379539228
Thank you,
John Nomikos.
-
Partition is larger than filesystem; issue resizing filesystem
Good afternoon,
On two of the VOXLs we have, the amount of space partitioned for /dev/sda9 is 23.9G.
However, the filesystem only has 15G available. I am not sure why the filesystem is so much smaller than the partition.
voxl:/$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 24.2G 0 disk |-sda1 8:1 0 8K 0 part |-sda2 8:2 0 32M 0 part /persist |-sda3 8:3 0 256M 0 part /cache |-sda4 8:4 0 1M 0 part |-sda5 8:5 0 512K 0 part |-sda6 8:6 0 128K 0 part |-sda7 8:7 0 128K 0 part |-sda8 8:8 0 512K 0 part `-sda9 8:9 0 23.9G 0 part /data sdb 8:16 0 4M 0 disk `-sdb1 8:17 0 4M 0 part sdc 8:32 0 4M 0 disk `-sdc1 8:33 0 4M 0 part sdd 8:48 0 128M 0 disk |-sdd1 8:49 0 32K 0 part |-sdd2 8:50 0 4K 0 part `-sdd3 8:51 0 1M 0 part sde 8:64 0 4G 0 disk |-sde1 8:65 0 512K 0 part |-sde2 8:66 0 512K 0 part |-sde3 8:67 0 2M 0 part |-sde4 8:68 0 2M 0 part |-sde5 8:69 0 512K 0 part |-sde6 8:70 0 512K 0 part |-sde7 8:71 0 2M 0 part |-sde8 8:72 0 16K 0 part |-sde9 8:73 0 512K 0 part |-sde10 8:74 0 512K 0 part |-sde11 8:75 0 95M 0 part /firmware |-sde12 8:76 0 16M 0 part /dsp |-sde13 8:77 0 1M 0 part |-sde14 8:78 0 32M 0 part |-sde15 8:79 0 1M 0 part |-sde16 259:0 0 1M 0 part |-sde17 259:1 0 64M 0 part |-sde18 259:2 0 3G 0 part / |-sde19 259:3 0 64M 0 part |-sde20 259:4 0 150M 0 part |-sde21 259:5 0 4K 0 part |-sde22 259:6 0 1M 0 part |-sde23 259:7 0 512K 0 part |-sde24 259:8 0 512K 0 part |-sde25 259:9 0 256K 0 part |-sde26 259:10 0 256K 0 part |-sde27 259:11 0 512K 0 part |-sde28 259:12 0 512K 0 part |-sde29 259:13 0 256K 0 part |-sde30 259:14 0 256K 0 part |-sde31 259:15 0 4K 0 part |-sde32 259:16 0 32.7M 0 part `-sde33 259:17 0 2M 0 part sdf 8:80 0 1.5G 0 disk |-sdf1 8:81 0 2M 0 part |-sdf2 8:82 0 2M 0 part `-sdf3 8:83 0 4K 0 part voxl:/$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 2.8G 1.9G 892M 68% / devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 17M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /var/volatile /dev/sda2 2.2M 80K 2.0M 4% /persist /dev/sde11 95M 33M 63M 35% /firmware /dev/sda3 58M 40K 57M 1% /cache /dev/sde12 12M 4.1M 7.4M 36% /dsp /dev/sda9 15G 744M 15G 5% /data
After doing some research, I know entering the command
sudo resize2fs /dev/sda9
should resize the filesystem to be as large as the partition. But, when I enter this command, I get a very strange error.voxl:/$ sudo resize2fs /dev/sda9 resize2fs 1.42.9 (28-Dec-2013) Filesystem at /dev/sda9 is mounted on /data; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 2 resize2fs: Invalid argument While checking for on-line resizing support voxl:/$ sudo resize2fs /dev/sda9 resize2fs 1.42.9 (28-Dec-2013) Filesystem at /dev/sda9 is mounted on /data; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 2 Performing an on-line resize of /dev/sda9 to 6261171 (4k) blocks. resize2fs: Invalid argument While trying to add group #125
The only info I could find about the same issue is here, and it's not really helpful: https://debian-bugs-dist.debian.narkive.com/ysLUbdet/bug-805716-resize2fs-invalid-argument-while-checking-for-on-line-resizing-support
On another drone we have, the difference in filesystem size to partition size is much greater. They only have 4.6 G of space on /dev/sda9 while the partition of sda9 is 24 G.
Any insights would be appreciated. Thank you.
-
How To Set VIO Position Offset?
The drone I'm working on has an interesting issue that when I'm flying in VIO mode and apply a yaw, the drone will move around a point in the front rather than just moving around the middle. It is kind of hard to describe through text, but imagine the drone moving around a point in front of it instead of just applying a yaw from the center of the drone. I believe the issue is because the drone does not have the correct VIO position offset. The first place I looked was on the PX4 parameters, and I noticed the EKF2_EV_POS_X, EKF2_EV_POS_Y and EKF2_EV_POS_Z parameters. But there was information that the VIO position offsets are handled by voxl-vision-px4 here: https://gitlab.com/voxl-public/flight-core-px4/px4-parameters/-/blob/master/platforms/v1.13/M500/M500_v1_param_rev_A.params
I was wondering what values I would have to change in voxl-vision-px4.conf to set the VIO position offset. In the ModalAI technical documentation here, it gives "T_imu_wrt_body", and "T_stereo_wrt_body" options, but I am using the tracking camera for VIO. Would I change those to affect the VIO position offset of the drone?
Or is there a T_tracking_wrt_body option that is not listed?
-
voxl-modem version 0.15.1 does not change eth0 inet address (voxl_platform_3.8.0-0.7)
I am writing this post to inform everyone that if you are using the new voxl_platform_3.8.0-0.7, it will have voxl-modem 0.15.1 on it, which has some issues.
I am running the new voxl_platform_3.8.0-0.7 on a VOXL and I had an issue with the voxl-modem 0.15.1 provided on the package.
Upon entering the voxl-configure-modem command and choosing the option 4 for microhard and then 1 for default, doing ifconfig would only show an inet6 address for eth0. I believe somebody faced a similar issue here:
https://forum.modalai.com/topic/1065/sentinel-voxl2-microhard-not-running/3?_=1664301927946I solved this problem by manually updating the voxl-modem version from 0.15.1 to 0.16.0. Newer versions of voxl-modem appear to not have this issue.
-
GPS Error And Issues Setting Up Obstacle Avoidance
When I set COM_OBS_AVOID to 1, the drone will immediately go into Not Ready mode. After doing some looking, I think it's because GPS shows as ERROR. I am not quite sure why the GPS has an error, but it's been like this for a couple of days, even before I tried to setup obstacle avoidance. The logs show a 'No known GPS device found' error which could be substantial:
The GPS model is MATEKSYS M8Q-5883 GPS Module, and the light on it is solid red. Apparently a flashing blue light means it is 3D fixed, but I'm not sure if that means anything.
I am not sure if this is a hardware issue or if there is something specific I need to do to setup the GPS so that it is not in error state. When I bring the drone outside, it does show that it gets GPS connection, even though GPS is in error state.
Any suggestions?
-
RE: VOXL Flightcore Camera Calibration Reprojection Error Reported By calibrateCamera
We managed to fix the intrinsic file not generating by deleting the already existing extrinsic file
-
RE: VOXL Flightcore Camera Calibration Reprojection Error Reported By calibrateCamera
We managed to get it to work once after changing the lighting in the room, but we cannot get the intrinsics file to generate for some reason
-
VOXL Flightcore Camera Calibration Reprojection Error Reported By calibrateCamera
Hello again.
So I've been trying to calibrate the cameras on a VOXL Flightcore and everytime the calibration is finished, a max reprojection error happens. I am not sure what this is caused by.
Is it due to the camera quality? It's strange because it has happening on both of the drones I'm working with.
-
RE: Calibrating Stereo Cameras on VOXL Flightcore is Super Finicky
@Chad-Sweet Yeah connecting it to ethernet fixed it. Also the video helped a lot. Thank you very much!