Hi @jake_eizy,
3. voxl-px4 1.18.0-1.0.12 in a stable SDK
Yes, it will be in SDK 1.8.1. The first alpha is being built now, and the full release is planned for the next couple of weeks. SDK 1.8 ships 1.0.9. If you need it before then, you can install voxl-px4 from the dev section on SDK 1.8, but mixed package versions are not a supported configuration, so use it for bench work and build production units on 1.8.1.
https://docs.modalai.com/configure-pkg-manager/
Hi @jake_eizy, answers for 5 and part of 6.
5. M0224 on SDK 1.8
Not with the stock SDK 1.8 build. The M0224 uses an ST Teseo receiver, and voxl-px4 1.18.0-1.0.9 (the version in SDK 1.8) always starts the GPS driver with the u-blox protocol, so it will not see the M0224. voxl-px4 1.18.0-1.0.12 and newer probe for the M0224's BMM150 magnetometer and start the GPS driver with the Teseo protocol when it is found. That build is in the dev package repository now. There is also an M0224 parameter set in voxl-px4-params.
Details: https://docs.modalai.com/accessories/m0224/#px4-support
Startup logic: https://github.com/modalai/px4-firmware/blob/voxl-dev/boards/modalai/voxl2/target/voxl-px4-start
6. J10 on M0154
A shipped M0154 boots with J10 in SPI mode. The stock kernel drives GPIO_67 (the J10 level shifter select) high and exposes /dev/spidev14.0 and /dev/spidev14.1. The mode is set in the kernel device tree, so UART mode needs a custom kernel build.
In SPI mode, GPIO_46 is the CS1 line (active low). On the SoC side, before the SN74LVC2T45 level shifter Vinny described, it is configured for 6 mA drive with no pull, and it is held high once the kernel SPI driver loads. The ±24 mA figure at the J10 pin comes from the level shifter.
Details: https://docs.modalai.com/voxl2-connectors/#j10---external-spi
On the Wi-Fi questions:
The -M36 option ships with an Alfa Network AWUS036EACS (802.11ac AC600, dual band 2.4/5 GHz, Realtek chipset, made in Taiwan). It is listed on the Starling 2 Max datasheet.
Yes, you can use a different USB adapter, as long as the VOXL 2 kernel has a driver for its chipset. You cannot install arbitrary vendor drivers without rebuilding kernel modules, so pick an adapter based on one of the Realtek chipsets we support: RTL8812AU or RTL8821CU / RTL8811CU. The adapters we have tested are listed on the VOXL 2 WiFi Setup page. If you find a Japan-certified (Giteki) adapter with one of those chipsets, it should work with voxl-wifi in both Station and SoftAP mode.
If you cannot find a certified adapter with a supported chipset, another option is a USB-to-Ethernet adapter on VOXL 2 connected to a small Japan-certified Wi-Fi bridge or travel router on the drone. VOXL 2 only sees Ethernet, so there are no driver constraints.
In SoftAP mode the default hostapd country code is US. For use in Japan, set country_code=JP in /data/misc/wifi/hostapd.conf after running voxl-wifi so the radio uses Japanese channel and power rules.
Hi @james-garito it's likely easiest if you dump your questions here so our whole team can get eyes on and address.
@simiken1234 Thanks for the detailed report and logs.
The images are correct. Your saved mach.var of 1.0.1 means M0054-1 hardware running the var00.1 (M0173) kernel, so the SDK 1.8.0 installer picked the right kernel and M0054(154)-1.zip is the right flat build. See VOXL 2 HW Versions.
The firehose reset timeout is expected and not a problem. See the note in Flash Flat Build.
A full factory flat build that still shows no USB device on a bare, cold-booted board, plus USB 3 resetting on two different hosts, points to a hardware problem on this board rather than SDK 1.8.0 or the -1 revision. Please do one more clean QDL flash of M0054(154)-1.zip over the USB 2 connection that worked. If it still does not come up as 05c6:901d, follow this section and request an RMA with the board serial (3f621d35), a link to this thread, and your support zip. Please hold off on further flash-system-image.sh or fastboot boot attempts in the meantime.
Hi @Dylan-Gresham,
Starling 2 Max ships with cameras in both directions already. The C28 config is two IMX412 4K color cameras and two AR0144 tracking cameras, one of each facing forward and one of each facing downward, so you get a front and a down view at the same time without moving anything. The camera names in the config are hires_front, hires_down, tracking_front, and tracking_down: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/master/misc_files/usr/share/modalai/voxl-camera-server/standard_configs/voxl2/platform_config_1/28 - M0173 Starling 2 Max dual IMX412 %2B dual AR0144
If you are asking about something different, can you point to the product image you are looking at and describe what you want to do? For example, physically re-mounting the front 4K camera to point down, or tilting it. That will help us give you a precise answer.
Front end board with the camera connector layout: https://docs.modalai.com/M0173/
Hi @rozner88,
Some context first. On VOXL 2 the estimator, controllers, sensor drivers, and ESC driver run on the DSP, not the apps processor. The CPU usage you see for voxl-px4 is only the apps processor side of PX4 (MUORB bridge, MAVLink, logging), so a heavy apps-side process is not expected to throttle the rate controller directly. The DSP has its own load figure, which is recorded in the PX4 log as the cpuload topic. See https://docs.modalai.com/voxl-px4-system-architecture/#cpu-load. The MAVLink "drops" in the log are not real drops; as Eric notes below, they come from the DSP and the apps processor keeping separate event numbering sequences. The logger does run on the apps processor, so it is still worth checking whether the "throttle drops to zero" are real actuator output gaps or gaps in the log itself.
That said, I do not have a confident explanation for the control degradation yet, and I would like our PX4 and ESC folks to look at the log. To help with that, please upload the ulog to https://logs.px4.io and post the link, and answer a few questions:
Does the stack publish anything into PX4 at all, even in altitude mode, such as odometry through voxl-vision-hub, setpoints, or parameter changes? VIO is disabled in your service list, so if the stack brings its own odometry source that matters.
Does the stack open any cameras or change camera-server streams when it starts? camera-server is already the heaviest service before the stack runs.
Does the same behavior happen on the bench with props off, and does it change if you run voxl-set-cpu-mode perf before starting the stack?
Is the stack in a Docker container, and does it pin cores or set real-time priority?
Once we have the log we can check DSP load, actuator outputs, and ESC status together.
Hi @alraj,
05c6:900e QUSB_BULK is not EDL (that is 9008). It is the SoC crash-dump mode, so the board is attempting to boot and failing before the OS comes up. Since Sahara/Firehose completed with the correct M0054-2 image, the flash contents are unlikely to be the problem. In past cases a board that returns to 900e after a successful QDL has not been recoverable by reflashing (https://forum.modalai.com/topic/1468 and https://forum.modalai.com/topic/3263), and a similar Sentinel case came back from RMA as a damaged main board (https://forum.modalai.com/topic/2131).
Two things worth ruling out first. Pull the VOXL 2 out of the drone and boot it bare with every camera and add-on disconnected, since a mis-seated camera connector produced this same 900e state once (https://forum.modalai.com/topic/3230). Then re-check the steps at https://docs.modalai.com/voxl2-unbricking/#if-the-device-still-shows-900e-or-boot-loops-after-a-successful-flash and repeat the flash once.
If it still comes back as 900e, an RMA is the next step: https://www.modalai.com/pages/rma. Include the serial number and QDL log. Keep the crash dump private, support can request it if needed.
Hi @kristi ,
Not a known issue. error -71 on the descriptor read happens before the WiFi driver loads, and getting worse over weeks with only a power cycle recovering it points to a failing part in the USB path rather than software.
Working on a PC does not rule out the dongle, since we have seen these Alfa dongles fail in service
(https://forum.modalai.com/topic/4538).
On Starling 2 Max the dongle sits in the M0141 breakout on VOXL 2 J3, so the likely fix is replacing one of them:
Posting voxl-version and dmesg | grep -i usb from a failing boot would help us confirm.
Please reach out here: https://www.modalai.com/pages/blue-uas-cleared-fpv-customer-intake-form
@Jetson-Nano Given the crash and hardware issues I'd recommend sending this board in for an RMA
@RoyAzriel 1.6.4 release is tested on Starling 2 now, go ahead and use that from the link I emailed you.
@RoyAzriel I'll send you an email with a link to the latest SDK. It is largely untested on starling2-max which is why it isn't available on our public downloads page yet.
@PatkirkMartin In order to toggle power via PX4 you can do the following:
Set GPIO_CTL_CH to the AUX channel you'd like to use for this feature, e.g., 3 for RC_MAP_AUX3.
Set the corresponding RC_MAP_AUX# to the button/switch you want to use. e.g. 10 for channel 10 on your RC transmitter.
@jmltt Apologies, context was lost. For clarity, sentinel was the last dev drone in which spektrum rc was supported and SDK 1.5.0 was the last SDK tested on said platform. Later SDKs have different gpio defaults which is why you're running into this issue
@jmltt The last ModalAI supported SDK on the Sentinel platform is SDK 1.5.0. Which doesn't mean that you won't success with newer SDKs, we just haven't tested with it.
@nl_vdi Here is a link to the latest beta: https://storage.googleapis.com/platform-beta-releases/voxl2/voxl2_SDK_1.6.4-beta8.tar.gz
