@jmltt nvm solved - GPIO pin 46 needs to have direction set to in or else data won't get through for some reason
one of the more recent voxl2 kernel board support package updates in the system image went from initializing GPIO46 as input to just not initializing it at all
So I'm guessing this has to do with the following I noticed in the changelog:
1.7.4
(voxl2_SDK_1.1.3)
BSP:
voxl-fysnc-mod kernel modulevoxl-gpio-mod kernel modulevoxl-platform-mod kernel module/sys/module/voxl_platform_mod/parametersIn system image 1.7.1 (SDK v1.1.2) on the drone that has no rc issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi has:
&soc {
b2b_conn_gpio_init {
compatible = "modalai,voxl-b2b";
pinctrl-names = "default";
pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &j10_lvl_shf_ctrl_pin>;
status = "ok";
};
rc_in_enable_init {
compatible = "modalai,voxl-rc-in";
pinctrl-names = "default";
pinctrl-0 = <&rc_in_3v3_en_pin>;
status = "ok";
};
};
In image 1.7.4 (SDK 1.1.3), recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi:
&soc {
voxl_gpio {
compatible = "modalai,voxl-gpio";
pinctrl-names = "default";
pinctrl-0 = <&tck22912G_ctrl_pin
&b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40
&hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96
&j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4>;
modalai,gpio-init-output-high = <0 1 53 56 57 85 86 87 88 89 124 152 157 159>;
modalai,gpio-init-output-low = <36 37 46 54 55 67 82 83 84 131 153 154 155>;
modalai,gpio-init-input = <48 49 50 51 52>;
status = "ok";
};
voxl_fsync {
compatible = "modalai,voxl-fsync";
pinctrl-names = "default";
pinctrl-0 = <&camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>;
status = "ok";
};
};
And then in image 1.8.06 (SDK v1.6.3) that is on the drone with the bind issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi:
&soc {
voxl_gpio {
compatible = "modalai,voxl-gpio";
pinctrl-names = "default";
pinctrl-0 = <&tck22912G_ctrl_pin
&b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40
&hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96
&j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4
&camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>;
modalai,gpio-init-output-high = <0 1 53 56 57 67 85 86 87 88 89 124 152 157 159>;
modalai,gpio-init-output-low = <36 37 54 55 82 83 84 131 153 154 155>;
modalai,gpio-init-input = <48 49 50 51 52 110 111 112 113 114>;
status = "ok";
};
voxl_fsync {
compatible = "modalai,voxl-fsync";
pinctrl-names = "default";
status = "ok";
};
};
So the gpio initialization process changed and rc_in_enable_init was removed between SDK v1.1.2 and v1.1.3, and between SDK v1.1.3 and v1.6.3, GPIO pin 67 got moved from modalai,gpio-init-output-low to modalai,gpio-init-output-high and GPIO pin 46 got removed from modalai,gpio-init-output-low.
Idk which change is responsible for the binding issues. I'd like to avoid flashing v1.1.3 to narrow it down. Can someone explain how the pins are meant to function for my set-up (M0094 + M0054, rc already bound)?
@Vinny Can you explain how the J10/J19, M0094 and the spektrum receiver are meant to work together?
I have a dev drone w/ VOXL2 & spektrum satellite receiver. After flashing the latest SDK (1.6.3) the receiver and transmitter stay bound but I have to force a rebind to get RC data coming in to PX4 every time I power cycle the drone. No issue up to SDK 1.1.2 and I noticed the way kernel GPIO initialization is handled changed in 1.1.3. More details here:
https://forum.modalai.com/topic/5243/spektrum-rc-bind-issues-after-sdk-update
I'm guessing this has to do with GPIO pin settings for pins 46, 67 or 159 being set wrong on boot, but I don't know enough about the hardware to understand what's going on. If I have a spektrum receiver on a dev drone w/ M0054 that is already bound to a transmitter, what should the GPIO pin settings be on boot to enable rc data flow to px4?
Ok so I've been comparing the Sentinel I have on an older SDK with no issues after power cycling with the one I just updated to the latest SDK and I noticed for the sentinel on the older SDK (1.1.2), the /sys/class/gpio only has the following
voxl2:~$ ls /sys/class/gpio/
export gpiochip1076 gpiochip1094 unexport
gpiochip1072 gpiochip1085 gpiochip1100
where the sentinel with the latest SDK shows:
sentinel (D0006):~$ ls /sys/class/gpio/
export gpio1152/ gpio1184/ gpio1213/ gpio1259/
gpio1100/ gpio1153/ gpio1185/ gpio1214/ gpiochip1072/
gpio1101/ gpio1154/ gpio1186/ gpio1224/ gpiochip1076/
gpio1136/ gpio1155/ gpio1187/ gpio1231/ gpiochip1085/
gpio1137/ gpio1156/ gpio1188/ gpio1252/ gpiochip1094/
gpio1148/ gpio1157/ gpio1189/ gpio1253/ gpiochip1100/
gpio1149/ gpio1167/ gpio1210/ gpio1254/ unexport
gpio1150/ gpio1182/ gpio1211/ gpio1255/
gpio1151/ gpio1183/ gpio1212/ gpio1257/
Then I ran voxl-bind-spektrum -ds on both and get nearly identical output, the SDK 1.6.3 the spektrum bind GPIO pin for M0154 is set even thought I'm on M0054
SDK 1.6.3:
sentinel (D0006):~$ voxl-bind-spektrum -ds
Enabling debug mode
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
number of pulses: 7
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1120
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing in to /sys/class/gpio/gpio%d/direction for gpio pin 1146
read 0 from gpio pin 1146
Writing 1120 to /sys/class/gpio/export for gpio pin 1120
Writing in to /sys/class/gpio/gpio%d/direction for gpio pin 1120
read 0 from gpio pin 1120
An orange light should now be flashing on your receiver
If so, your receiver is successfully in binding mode
SDK 1.1.2
voxl2:~$ voxl-bind-spektrum -ds
Enabling debug mode
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1259 to /sys/class/gpio/export for gpio pin 1259
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1259
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
number of pulses: 7
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 1 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing 0 to /sys/class/gpio/gpio%d/value for gpio pin 1146
Writing 1146 to /sys/class/gpio/export for gpio pin 1146
Writing in to /sys/class/gpio/gpio%d/direction for gpio pin 1146
read 0 from gpio pin 1146
An orange light should now be flashing on your receiver
If so, your receiver is successfully in binding mode
Now the SDK1.1.2 quad shows:
voxl2:~$ ls /sys/class/gpio/
export gpio1259 gpiochip1076 gpiochip1094 unexport
gpio1146 gpiochip1072 gpiochip1085 gpiochip1100
And SDK1.6.3:
sentinel (D0006):~$ ls /sys/class/gpio/
export gpio1148 gpio1155 gpio1185 gpio1212 gpio1254 gpiochip1094
gpio1100 gpio1149 gpio1156 gpio1186 gpio1213 gpio1255 gpiochip1100
gpio1101 gpio1150 gpio1157 gpio1187 gpio1214 gpio1257 unexport
gpio1120 gpio1151 gpio1167 gpio1188 gpio1224 gpio1259
gpio1136 gpio1152 gpio1182 gpio1189 gpio1231 gpiochip1072
gpio1137 gpio1153 gpio1183 gpio1210 gpio1252 gpiochip1076
gpio1146 gpio1154 gpio1184 gpio1211 gpio1253 gpiochip1085
The pin settings after running voxl-spektrum-bind are the same for both vehicles in /sys/class/gpio/gpio1146 and /sys/class/gpio/gpio1259. After power cycling I'm right back where I started, but the settings for gpio1259 persist on the v1.6.3 quad.
I'm guessing I need to do something with the settings for gpio pin 46 or 159 to fix this. What should the gpio pin settings be on boot for a VOXL2 vehicle with an already bound spektrum receiver? Is the problem that /sys/class/gpio/gpio1259 settings persist between power cycles? Where are all these gpio settings getting written to on boot?
I have several Sentinels that were shipped with taoglas GPS/mag unit, ghost atto receiver, and orqa controllers with the ghost atto uberlite-24 transmitters. I also have some older sentinels that shipped with a different GPS/mag unit and the spektrum receiver/bind board.
Is there a way I could purchase the GPS/mag units, ghost atto receiver and transmitter/controller and cable assembly to the J19 connector that were used for the last iteration of the Sentinels? I don't even really care about the GPS/mag but I noticed on our newer quads there are wires from the ghost atto receiver board and the gps unit spliced together going into pin 1 of the J19 so I can't just hot swap the spektrum receiver with the ghost atto one.
I've got an older Sentinel that shipped with Spektrum RC satellite receiver and some SDK pre v1.0.0 (I think it's SDK v0.8). It hasn't been used since we got it and I was setting up for first flight. I flashed the lastest SDK (1.6.3) and went through the set up procedure, calibrated it and flew it with the same Spektrum Transmitter I've used for some other Sentinels we've been flying more regularly.
I noticed after power cycling the vehicle and transmitter (Spektrum SPM9900), the Spektrum receiver and transmitter appear to bind automatically as expected (solid orange light on transmitter and receiver light up at same time when powered on), but px4 never gets the RC data (px4-listener input_rc returns never published) until I force them to rebind by running voxl-bind-spektrum -s and setting the transmitter in bind mode.
Does anyone know what could be causing this? I don't know enough about how the spektrum bind board (M0094) works, but reading through voxl-spektrum-bind.c I'm guessing this has something to do with the GPIO pin direction settings. Did the default settings change between SDK versions? I don't have this problem with other Sentinels running SDK 1.1
@Vinny That's it! I don't know how I missed it.
I couldn't find the wifi adapters that shipped with the sentinels in your store so I'm assuming you don't sell them individually.
Does it matter what kind of adapter I get, are there any specs that I need to looks for or can I pretty much use anything?
Thanks!
@Alex-Kushleyev I just wanted to check back and see if you guys still have any of the longer cables or the entire assemblies that I could purchase. I haven't had a chance to troubleshoot the potentially bad cable, but we're just looking to replace it since we need to retrofit the older models anyways.
Again, if not no worries we make our own cables and buy the adapters it'd just be easier to buy ready-made sets.
@Alex-Kushleyev That is the type of cable I'd need but I've actually ordered that one (MCBL-00009-1) before for a separate application and just eyeballing it it's about half the length I'd need. Here's a picture of the set-up
Also, in addition to trying to troubleshoot this adapter/cable I need to retrofit four older Sentinel models (were only shipped with the microhard carrier board, no wifi adapter) with wifi adapters so if it's possible I'd like to just purchase five assemblies (usb to jst and wifi adapter shrink wrapped together). If you guys don't have any of that cabling already made or there's no mechanism for me to order them as a set that's totally fine. We can order the piece parts and make the cabling ourselves, it'd just be easier for us to order them if that's possible.
@jmltt This is still a problem. I reverted the changes for static IP set-up and am just using DHCP so the settings are the same as how the quad was shipped. Still getting cannot enable, usb cable bad? messages after the wifi adapter if recognized on start-up. I'm hoping the the wifi adapter or cabling is just bad and not the port on the carrier board.
[ 2.361738] usbcore: registered new interface driver 8188eu
[ 2.447119] usbcore: registered new interface driver rtl8821cu
[ 2.499469] usbcore: registered new interface driver rtl88XXau
[ 2.912052] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 3.048404] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[ 3.048410] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.220352] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 5.022237] f_cdev_alloc: port_name:at_usb0 (ffffffe44efe8000) portno:(0)
[ 5.024793] f_cdev_alloc: port_name:at_usb1 (ffffffe44c25f400) portno:(1)
[ 5.068782] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 5.069166] usb 1-1-port4: attempt power cycle
[ 6.208341] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 6.280130] usb 1-1.4: new high-speed USB device number 6 using xhci-hcd
[ 6.280207] usb 1-1.4: Device not responding to setup address.
[ 6.484149] usb 1-1.4: Device not responding to setup address.
[ 6.688146] usb 1-1.4: device not accepting address 6, error -71
[ 6.688417] usb 1-1-port4: unable to enumerate USB device
[ 7.673010] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 8.520477] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 8.520664] usb 1-1-port4: attempt power cycle
[ 9.660805] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 10.500523] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 10.500714] usb 1-1-port4: unable to enumerate USB device
When I take the lid off the and reseat the JST connector it starts working again. Maybe the problem is the lid clamping down on the wires and slowly pulling the connector out or maybe it's just bad wires.
Is there any way to order a replacement assembly? Like the way it's shipped, 4-pin JST to to USB to wifi adapter with the shrink wrap and everything? I know Sentinels EOL but I'm assuming you might have the same wifi adapter set-up for another platform
If this is more of a customer support question can someone point me to an email address to direct this to? Thanks
Looks the same bug as here: https://github.com/PX4/PX4-Autopilot/issues/22148
Added the change from this commit and it looks like it works now: https://github.com/PX4/PX4-Autopilot/pull/22194/commits/38f3c711084b349cb9ed82cf44ff181c6a40738a
@Zachary-Lowell-0 said in SITL using VOXL2 PX4 software:
That is correct it would only be able to support one vehicle. You can test SITL multi vehicles on your parent computer running SITL, however the modules and drivers running in that environment would differ from what is running on the voxl2.
I'm trying to do the same thing as the original poster (see https://forum.modalai.com/topic/4930/voxl-px4-vs-mainline-px4-sitl-questions)
Can you explain generally the differences between the code running on the vehicle vs a SITL build? Is the flight control stack (save sensor input) mostly the same if building the sitl from the px4-firmware branch that's on the quads? I'm going to try out HITL using modalai's docker image as well, but I'd like a SITL build that's going to be as close as possible to what's running on the quads so I can test multi-vehicle control via ros2
Background: I'm trying to set up a multi-vehicle sim environment using gazebo and px4 sitl. I've got 4 quads on SDK v1.3.5. I wanted to pull the voxl-px4/modalai px4-firmware version from that release to build px4_sitl on my local machine so I can test in sim against a version that's going to most representative of firmware on the quads.
I'm building inside a ubuntu 22 docker container after running ./px4-firmware/Tools/setup/ubuntu.sh. The px4_sitl build failed because of the bug mentioned here: https://forum.modalai.com/topic/3510/px4-build-broken-for-sitl-targets
I implemented the poster's fix (https://github.com/modalai/px4-firmware/pull/61) and was able to build px4-sitl but when I run it I get the following errors:
ERROR [gz_bridge] timed out waiting for clock message
ERROR [gz_bridge] Task start failed (-1)
ERROR [init] gz_bridge failed to start
ERROR [px4] Startup script returned with return value: 256
Are there extra steps I missed that are required to build px4_sitl from modalai's px4-firmware fork vs the mainline px4? Is it just not going to work if I try to build it on my laptop?
If I have to pull a mainline px4 branch to build sitl on my laptop, is there a specific release (e.g. 1.14.0-1.14.4) that would be most analogous to the past/current branches of modalai's px4-firmware? The voxl-px4 version I have installed on the quads is using the 1.14.0-2.0.85 firmware.
I'm doing multi-vehicle offboard control via ros2 w/ ext vision for state estimation, mostly testing code that publishes trajectory setpoints. I'd like to make sure at least the controller and estimator code is as close as possible to what's running on the quads.
Will SDK release testing end (or has it already) for EOL dev drones like the Sentinel?
I noticed on the release page that SDK v1.5.0 was the last release that was tested on the Sentinel platform. Does this mean future releases (1.6+) will no longer be tested for the Sentinels?
If so, are the platforms currently in production similar enough (given they all use VOXL2 but with different sensors/hardware) to the Sentinel platform such that I can continue updating with future SDK releases or should I stop at v1.5.0?
I have several Sentinel drones with ros2 foxy installed via voxl-ros2-foxy and I need to switch to running ros2 humble on the quads. From what I've seen there's no way to get around having to run it via docker, but I have a few questions:
Are there instructions on installing docker on target? The modalai guide (https://docs.modalai.com/docker-on-voxl/) references to just use the docker instructions to install via apt, but the docker install instructions linked to require an ubuntu o.s. newer than 20.04 so I wasn't sure if it would work.
In switching to ros2 humble onboard the voxl2 do I need to update the dds client module and rebuild voxl-px4 and rebuild the voxl-microdds-agent as well? I'm assuming that if they're built to work with ros2 foxy they're going to be dependent on older versions of fast-dds than what humble would be using and might not be compatible
Are there any example docker run commands that are recommended for running containers onboard voxl2 with proper permissions for using the networking interfaces and mounting whatever volumes ros2 would need to run and work with px4?
Basically if you guys are running ros2 humble out of docker on voxl2 what did your set-up look like and did you run into any compatibility issues?
Thanks!
@Aaron-Porter I'm sure the system id fix might have resolved the issue. I just find having separate ports for each vehicle to establish a connection over a cleaner option. This isn't an issue for me anymore, I was just responding to the question on the approach I used to resolve it
I just disconnected/reconnected the USB to 4-pin JST cable from the microhard carrier board and rebooted the vehicle. Now the wlan0 interface has been up the entire time the vehicle's on, but none of the other devices on the vLAN the wifi adapter is connected to can ping the vehicle over wifi.
Output from dmesg looks the same except the following output after the microhard interface is found:
[ 26.460342] usb 1-1.2: new high-speed USB device number 4 using xhci-hcd
[ 26.550901] usb 1-1.2: New USB device found, idVendor=1f94, idProduct=3002, bcdDevice= 4.14
[ 26.550915] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 26.550922] usb 1-1.2: Product: pMDDL2450AES256
[ 26.550929] usb 1-1.2: Manufacturer: Microhard
[ 26.550935] usb 1-1.2: SerialNumber: 1592348
[ 26.639101] rndis_host 1-1.2:1.0 usb0: register 'rndis_host' at usb-xhci-hcd.0.auto-1.2, RNDIS device, 16:4f:08:e4:e1:09
[ 26.643401] cdc_acm 1-1.2:1.2: ttyACM0: USB ACM device
[ 33.765387] vdd_tof: disabling
[ 33.765393] vdd_hap_boost: disabling
[ 37.240138] hrtimer: interrupt took 112083 ns
[ 101.412343] boot log copy done
[ 114.937520] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x41b08
[ 233.747906] perf: interrupt took too long (2778 > 2500), lowering kernel.perf_event_max_sample_rate to 72000
[ 339.990578] perf: interrupt took too long (3473 > 3472), lowering kernel.perf_event_max_sample_rate to 57500
[ 386.060248] perf: interrupt took too long (4425 > 4341), lowering kernel.perf_event_max_sample_rate to 45000
I have multiple Sentinels with microhard add-on boards and wifi adapters connected to the USB peripheral port on the microhard carrier board (not custom, this is how they were shipped). Wifi is working without issue on 3/4 of the vehicles, but for one of the vehicles the wifi adapter is either never recognized after booting up or it is detected and works for a few minutes but then disconnects and will not reestablish a connection.
I used the instructions here to configure dhcpcd to set a static ip adress for the wlan0 interface for all the vehicles:
https://forum.modalai.com/topic/4105/instruction-to-set-a-static-ip-for-wlan0-voxl2
It works without issue for the other vehicles so I don't think it's part of the problem. I've attached the output of dmesg following a boot experiencing these issues and filtered the output for lines that contain "usb". You can see the wifi adapter is detected around 7 seconds after boot, the microhard interface is detected around 26 seconds after boot, but around 281 s after boot the wifi adapter starts diconnecting and can't be enabled.
Can me someone help me troubleshoot this? I'm assuming at this point since the configurations are the same on all the other vehicles that this is most likely a hardware issue. How can I confirm whether it is or not?
[ 0.000000] Kernel command line: rcupdate.rcu_expedited=1 rcu_nocbs=0-7 kpti=off noinitrd earlycon=msm_geni_serial,0xa90000 androidboot.hardware=qcom androidboot.console=ttyMSM0 androidboot.memcg=1 lpm_levels.sleep_disabled=1 video=vfb:640x400,bpp=32,memsize=3072000 msm_rtb.filter=0x237 service_locator.enable=1 androidboot.usbcontroller=a600000.dwc3 swiotlb=2048 loop.max_part=7 cgroup.memory=nokmem,nosocket reboot=panic_warm net.ifnames=0 usbcore.autosuspend=-1 apparmor=1 security=apparmor root=/dev/sda9 androidboot.bootdevice=1d84000.ufshc androidboot.serialno=75caf339 androidboot.baseband=apq msm_drm.dsi_display0=qcom,mdss_dsi_ext_bridge_1080p: systemd.setenv="SLOT_SUFFIX=_a" skip_initramfs rootwait rw init=/sbin/init
[ 1.672769] usbcore: registered new interface driver usbfs
[ 1.672790] usbcore: registered new interface driver hub
[ 1.672883] usbcore: registered new device driver usb
[ 1.673141] usb_phy_generic soc:usb_nop_phy: soc:usb_nop_phy supply vcc not found, using dummy regulator
[ 1.673170] usb_phy_generic soc:usb_nop_phy: Linked as a consumer to regulator.0
[ 1.857352] usbcore: registered new interface driver r8152
[ 1.857366] usbcore: registered new interface driver lan78xx
[ 1.857374] usbcore: registered new interface driver asix
[ 1.857380] usbcore: registered new interface driver ax88179_178a
[ 1.857385] usbcore: registered new interface driver cdc_ether
[ 1.857391] usbcore: registered new interface driver cdc_eem
[ 1.857399] usbcore: registered new interface driver smsc75xx
[ 1.857406] usbcore: registered new interface driver smsc95xx
[ 1.857412] usbcore: registered new interface driver net1080
[ 1.857418] usbcore: registered new interface driver rndis_host
[ 1.857422] usbcore: registered new interface driver cdc_subset
[ 1.857428] usbcore: registered new interface driver zaurus
[ 1.857434] usbcore: registered new interface driver sierra_net
[ 1.857440] usbcore: registered new interface driver cdc_ncm
[ 1.857446] usbcore: registered new interface driver qmi_wwan
[ 1.857451] usbcore: registered new interface driver cdc_mbim
[ 1.857698] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.32
[ 1.857712] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.18
[ 1.857718] msm-usb-ssphy-qmp 88e8000.ssphy: failed to get phandle for msm_ssphy_qmp
[ 1.857744] msm-usb-ssphy-qmp 88e8000.ssphy: Dropping the link to regulator.18
[ 1.857759] msm-usb-ssphy-qmp 88e8000.ssphy: Dropping the link to regulator.32
[ 1.857837] msm-usb-ssphy-qmp 88eb000.ssphy: Linked as a consumer to regulator.32
[ 1.857847] msm-usb-ssphy-qmp 88eb000.ssphy: Linked as a consumer to regulator.18
[ 1.857999] msm-usb-hsphy 88e3000.hsphy: Linked as a consumer to regulator.13
[ 1.858021] msm-usb-hsphy 88e3000.hsphy: Linked as a consumer to regulator.10
[ 1.858034] msm-usb-hsphy 88e3000.hsphy: Linked as a consumer to regulator.21
[ 1.858211] msm-usb-hsphy 88e4000.hsphy: Linked as a consumer to regulator.13
[ 1.858222] msm-usb-hsphy 88e4000.hsphy: Linked as a consumer to regulator.10
[ 1.858232] msm-usb-hsphy 88e4000.hsphy: Linked as a consumer to regulator.21
[ 1.858778] msm-dwc3 a600000.ssusb: Linked as a consumer to 15000000.apps-smmu
[ 1.859004] iommu: Adding device a600000.ssusb to group 13
[ 1.859152] msm-dwc3 a600000.ssusb: Linked as a consumer to regulator.66
[ 1.860588] msm-dwc3 a600000.ssusb: unable to get ssphy device
[ 1.861600] msm-dwc3 a600000.ssusb: Dropping the link to regulator.66
[ 1.861655] msm-dwc3 a800000.ssusb: Linked as a consumer to 15000000.apps-smmu
[ 1.861848] iommu: Adding device a800000.ssusb to group 14
[ 1.862001] msm-dwc3 a800000.ssusb: Linked as a consumer to regulator.67
[ 1.863002] register_client_adhoc:Client handle 36 usb1
[ 1.863723] usbcore: registered new interface driver cdc_acm
[ 1.863732] usbcore: registered new interface driver cdc_wdm
[ 1.863741] usbcore: registered new interface driver usb-storage
[ 1.863756] usbcore: registered new interface driver cp210x
[ 1.863761] usbserial: USB Serial support registered for cp210x
[ 1.863767] usbcore: registered new interface driver ftdi_sio
[ 1.863771] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 1.863778] usbcore: registered new interface driver option
[ 1.863782] usbserial: USB Serial support registered for GSM modem (1-port)
[ 1.863787] usbcore: registered new interface driver qcserial
[ 1.863791] usbserial: USB Serial support registered for Qualcomm USB modem
[ 1.863797] usbcore: registered new interface driver sierra
[ 1.863801] usbserial: USB Serial support registered for Sierra USB modem
[ 1.863807] usbcore: registered new interface driver usb_ehset_test
[ 1.863813] usbcore: registered new interface driver lvs
[ 1.864094] qpnp-pdphy c440000.qcom,spmi:qcom,pm8150b@2:qcom,usb-pdphy@1700: Linked as a consumer to regulator.10
[ 1.864626] qpnp-pdphy c440000.qcom,spmi:qcom,pm8150b@2:qcom,usb-pdphy@1700: usbpd_create failed: -517
[ 1.864693] qpnp-pdphy c440000.qcom,spmi:qcom,pm8150b@2:qcom,usb-pdphy@1700: Dropping the link to regulator.10
[ 1.864840] usbcore: registered new interface driver xpad
[ 1.864847] usbcore: registered new interface driver usb_acecad
[ 1.864852] usbcore: registered new interface driver aiptek
[ 1.864858] usbcore: registered new interface driver gtco
[ 1.864864] usbcore: registered new interface driver hanwang
[ 1.864868] usbcore: registered new interface driver kbtab
[ 1.871415] ssusb redriver 3-001c: Could not get usb power_supply
[ 1.871420] ssusb redriver 3-001c: failed to get phandle for redriver
[ 1.877138] usbcore: registered new interface driver uvcvideo
[ 1.893434] usbcore: registered new interface driver usbhid
[ 1.893436] usbhid: USB HID core driver
[ 1.907420] usbcore: registered new interface driver snd-usb-audio
[ 1.907510] uaudio-qmi soc:usb_audio_qmi_dev: Linked as a consumer to 15000000.apps-smmu
[ 1.907534] iommu: Adding device soc:usb_audio_qmi_dev to group 20
[ 1.920303] msm-dwc3 a800000.ssusb: DWC3 exited from low power mode
[ 1.921251] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[ 1.921264] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.921274] usb usb1: Product: xHCI Host Controller
[ 1.921281] usb usb1: Manufacturer: Linux 4.19.125 xhci-hcd
[ 1.921288] usb usb1: SerialNumber: xhci-hcd.0.auto
[ 1.922122] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 4.19
[ 1.922134] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.922145] usb usb2: Product: xHCI Host Controller
[ 1.922152] usb usb2: Manufacturer: Linux 4.19.125 xhci-hcd
[ 1.922160] usb usb2: SerialNumber: xhci-hcd.0.auto
[ 1.959048] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.32
[ 1.959075] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.18
[ 1.959080] msm-usb-ssphy-qmp 88e8000.ssphy: failed to get phandle for msm_ssphy_qmp
[ 1.959099] msm-usb-ssphy-qmp 88e8000.ssphy: Dropping the link to regulator.18
[ 1.959109] msm-usb-ssphy-qmp 88e8000.ssphy: Dropping the link to regulator.32
[ 1.959186] msm-dwc3 a600000.ssusb: Linked as a consumer to regulator.66
[ 1.960319] usb_bam_init: setting SPS_BAM_SMMU_EN flag with (a704000.qcom,usbbam)
[ 1.960427] msm-dwc3 a600000.ssusb: unable to get ssphy device
[ 1.961090] msm-dwc3 a600000.ssusb: Dropping the link to regulator.66
[ 1.961154] qpnp-pdphy c440000.qcom,spmi:qcom,pm8150b@2:qcom,usb-pdphy@1700: Linked as a consumer to regulator.10
[ 1.961704] qpnp-pdphy c440000.qcom,spmi:qcom,pm8150b@2:qcom,usb-pdphy@1700: usbpd_create failed: -517
[ 1.961777] qpnp-pdphy c440000.qcom,spmi:qcom,pm8150b@2:qcom,usb-pdphy@1700: Dropping the link to regulator.10
[ 1.967371] ssusb redriver 3-001c: Could not get usb power_supply
[ 1.967375] ssusb redriver 3-001c: failed to get phandle for redriver
[ 1.977320] SMB5 status - usb:present=0 type=0 batt:present = 1 health = 1 charge = 1
[ 1.989400] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.32
[ 1.989413] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.18
[ 1.989418] msm-usb-ssphy-qmp 88e8000.ssphy: failed to get phandle for msm_ssphy_qmp
[ 1.989433] msm-usb-ssphy-qmp 88e8000.ssphy: Dropping the link to regulator.18
[ 1.989441] msm-usb-ssphy-qmp 88e8000.ssphy: Dropping the link to regulator.32
[ 1.989517] msm-dwc3 a600000.ssusb: Linked as a consumer to regulator.66
[ 1.990404] usb_bam_init: setting SPS_BAM_SMMU_EN flag with (a704000.qcom,usbbam)
[ 1.990508] msm-dwc3 a600000.ssusb: unable to get ssphy device
[ 1.991138] msm-dwc3 a600000.ssusb: Dropping the link to regulator.66
[ 1.991202] qpnp-pdphy c440000.qcom,spmi:qcom,pm8150b@2:qcom,usb-pdphy@1700: Linked as a consumer to regulator.10
[ 1.997331] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.32
[ 1.997345] msm-usb-ssphy-qmp 88e8000.ssphy: Linked as a consumer to regulator.18
[ 1.997349] msm-usb-ssphy-qmp 88e8000.ssphy: No separate ID extcon device
[ 1.997392] msm-dwc3 a600000.ssusb: Linked as a consumer to regulator.66
[ 1.998227] usb_bam_init: setting SPS_BAM_SMMU_EN flag with (a704000.qcom,usbbam)
[ 1.998632] register_client_adhoc:Client handle 63 usb0
[ 1.998672] msm-dwc3 a600000.ssusb: Linked as a consumer to regulator.86
[ 2.056179] msm-dwc3 a600000.ssusb: DWC3 exited from low power mode
[ 2.056930] msm-dwc3 a600000.ssusb: DWC3 in low power mode
[ 2.287804] usbcore: registered new interface driver 8188eu
[ 2.327455] usbcore: registered new interface driver rtl8821cu
[ 2.346036] usbcore: registered new interface driver rtl88XXau
[ 2.656045] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 2.792395] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[ 2.792401] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.184140] usb 1-1.4: new high-speed USB device number 3 using xhci-hcd
[ 4.016323] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 4.852415] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 4.852644] usb 1-1-port4: attempt power cycle
[ 5.018757] f_cdev_alloc: port_name:at_usb0 (ffffffe38c15a800) portno:(0)
[ 5.021717] f_cdev_alloc: port_name:at_usb1 (ffffffe38c158400) portno:(1)
[ 6.016434] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 6.088053] usb 1-1.4: new high-speed USB device number 6 using xhci-hcd
[ 6.088136] usb 1-1.4: Device not responding to setup address.
[ 6.297149] usb 1-1.4: Device not responding to setup address.
[ 6.500946] usb 1-1.4: device not accepting address 6, error -71
[ 6.501376] usb 1-1-port4: unable to enumerate USB device
[ 6.921975] usb 1-1.4: new high-speed USB device number 7 using xhci-hcd
[ 7.029686] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=0811, bcdDevice= 2.00
[ 7.029695] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7.029700] usb 1-1.4: Product: 802.11ac WLAN Adapter
[ 7.029705] usb 1-1.4: Manufacturer: Realtek
[ 7.029709] usb 1-1.4: SerialNumber: 00e04c000001
[ 7.274284] usb 1-1.4: 88XXau 00:c0:ca:b5:ab:9c hw_info[107]
[ 26.444557] usb 1-1.2: new high-speed USB device number 8 using xhci-hcd
[ 26.534908] usb 1-1.2: New USB device found, idVendor=1f94, idProduct=3002, bcdDevice= 4.14
[ 26.534925] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 26.534934] usb 1-1.2: Product: pMDDL2450AES256
[ 26.534942] usb 1-1.2: Manufacturer: Microhard
[ 26.534951] usb 1-1.2: SerialNumber: 1592348
[ 26.634655] rndis_host 1-1.2:1.0 usb0: register 'rndis_host' at usb-xhci-hcd.0.auto-1.2, RNDIS device, 06:f2:15:a9:a5:b2
[ 281.219466] usb 1-1.4: USB disconnect, device number 7
[ 281.515539] usb 1-1.4: new high-speed USB device number 9 using xhci-hcd
[ 281.605319] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=0811, bcdDevice= 2.00
[ 281.605329] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 281.605333] usb 1-1.4: Product: 802.11ac WLAN Adapter
[ 281.605337] usb 1-1.4: Manufacturer: Realtek
[ 281.605341] usb 1-1.4: SerialNumber: 00e04c000001
[ 281.932340] usb 1-1.4: 88XXau 00:c0:ca:b5:ab:9c hw_info[107]
[ 297.859348] usb 1-1.4: USB disconnect, device number 9
[ 298.159693] usb 1-1.4: new high-speed USB device number 10 using xhci-hcd
[ 298.249415] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=0811, bcdDevice= 2.00
[ 298.249426] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 298.249432] usb 1-1.4: Product: 802.11ac WLAN Adapter
[ 298.249437] usb 1-1.4: Manufacturer: Realtek
[ 298.249442] usb 1-1.4: SerialNumber: 00e04c000001
[ 298.574671] usb 1-1.4: 88XXau 00:c0:ca:b5:ab:9c hw_info[107]
[ 300.419153] usb 1-1.4: USB disconnect, device number 10
[ 300.684351] usb 1-1.4: new high-speed USB device number 11 using xhci-hcd
[ 301.534222] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 301.607787] usb 1-1.4: new high-speed USB device number 12 using xhci-hcd
[ 302.440236] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 302.440408] usb 1-1-port4: attempt power cycle
[ 303.580855] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 304.428990] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[ 304.430266] usb 1-1-port4: unable to enumerate USB device