Hi @Matthew-Howlett ,
No the m500 currently has a BMP388.
Engineer at ModalAI
Hi @Matthew-Howlett ,
No the m500 currently has a BMP388.
The official product documentation is located at https://docs.modalai.com/
The purpose of this forum is to supplement that documentation, and to update the official docs when we find information missing.
Hi @rapit ,
OK we validated that a USB3 device can show up, here's a "guide", but there's no new info really, just an example: https://docs.modalai.com/voxl-as-usb-host/
-Travis
Hi @mrawding ,
The current early release on the EVT hardware relies on gstreamer.... for example:
cd /data/misc/camera
rm *
gst-launch-1.0 -e qtiqmmfsrc camera=0 name=tracker ! video/x-h264,format=NV12,width=640,height=480,framerate=30/1 ! queue ! h264parse ! avdec_h264 ! videoconvert ! pngenc ! multifilesink enable-last-sample=false location="/data/misc/camera/cam0_img_%d_.png"
This will save images to the path specified. We're actively working on getting the same interfacing as VOXL up on this ;). Next few weeks should have some good PUBLIC REPO updates.
Hi @gauravshukla914,
If voxl-vision-px4 is setup for VOA it will connect to the stereo and 'take over', if that's the case can you try the following before launching?
systemctl stop voxl-vision-px4
FYI for the future, the MPA architecture (https://gitlab.com/voxl-public/modal-pipe-architecture) will provide 'fan out' and allow multiple clients for a given camera.
@Gaurav-Borade , we have one in the works that should be ready shortly, I'll send a link once we get it posted!
Hi @mrawding ,
You are correct, there's something wrong, and I'm investigating this now.
The UART is active after bootup but then something fishy is happening.
When used with PX4 (ran on bootup) there's no issue.
I'll post here when there's an update to fix.
Hi @gauravshukla914 ,
Our flight controller is a little unique in that it can't be powered off USB so yes, it will lose power and connection during the standard process. (The reason being our Flight Controller shares the 5V rail with the companion computer and 500mA off USB won't suffice!)
To get around this, we have a tool that has a user guide here:
https://docs.modalai.com/flight-core-pwm-esc-calibration/
This allows you to keep the battery connected during the ESC calibration process.
This is for the STM32 based FlightCore.... not SLPI which I think you're super aware of but making sure!
Hi @Kevin ,
The VOXL2 (M0054) and RB5 Flight (M0052) images aren't compatible as they have different kernel and rootfs. So flashing the VOXL2 onto the RB5 leads to bricking.
But, on the RB5, you can get to a 'factory state' following this:
https://docs.modalai.com/Qualcomm-Flight-RB5-QDL/
That image is a factory image that is pretty old and not fully useable, so we need to flash an update.
You then have two choices.... reflash the same (9.1 based) image and use the RB5 Flight software (now in maintenance mode).
Or, use the ModalAI maintained VOXL SDK. To use the VOXL SDK, you need to update your RB5 Flight hardware with this from downloads.modalai.com :
We are currently working on an improved update guide and will post shortly.
OK got it. You alluded to this, modifying something like hub.c
(Generally if it's not showing up, we need to find some flags to add. For example, we added some USB modems like this:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/patches/005-telit-option.patch
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/patches/004-quectel-usb-wwan.patch
)
We'll likely need to find similar for TUSB8041 and then try to add if it's not showing up by default.
Are you plugging this TUSB8041 hub into a USB port or using custom hardware?
Have you located anything from TI that tells us what flags to enable? That's where I'd go next, see if vendor has clues and then we can try it out.
Does this device (TUSB8041) enumerate normally in the 'stock' kernel/rootfs? E.g. if you have our production SDK release loaded does it show up?
Thanks,
Travis
I think it's because the kernel is built as a 'debug' kernel, whereas the KO is not, in this case. To build the perf kernel, see usage here:
https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel-build-docker/-/blob/qrb5165-ubun1.0-14.1a/bin/qrb5165-build.sh?reef_type=heads#L136
Alternatively, you can rebuild voxl-gpio-mod with debug flags, namely replace:
bitbake qti-ubuntu-robotics-image -fc do_make_bootimg
with
bitbake voxl-gpio-mod
When the build is finished, find / -name voxl-gpio-mod.ko
to locate and you can replace the one on target.
--- another approach for me --- is likely to see how to build these modules IN TREE to avoid this.... I will begin to research this.
Hi @enrico-bandera-0 ,
We've done some work in this area in both the user space application and kernel/rootfs, can you let me know what version you are on?
From our downloads, thisi s the latest:
VOXL2 SDK 1.1.3 voxl2_SDK_1.1.3.tar.gz 2/26/2024, 9:28:46 AM
The voxl-gpio-mod out of tree kernel module is handling initialization, can you grep status?
dmesg | grep voxl-gpio-mod
Thanks,
Travis
Hi @이광철
Sorry for missing guidance, I do think an alias is also needed like this:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/e97a22de6b4e5582fc276a963b958d01a478d56b#999b45d40c8aafd81669d788073c2ea1315dac66_66_62
Also for this to work, I believe you will want to use the older devcfg.mbn file as well from SDK 1.0.0 as that has trustzone setup for SPI, and the new devcfg.mbn is setup for UART.
If trustzone isn't configured correctly I do think the kernel halts on bootup.
Flashing devcfg.mbn is like this, which is likely needed once alias is setup, to convert back to SPI from UART.
fastboot flash devcfg_a devcfg.mbn
fastboot flash devcfg_b devcfg.mbn
For hires/tracking config C4, use J7 as shown in docs:
https://docs.modalai.com/voxl2-camera-configs/#c-04-hires-and-tracking
Hi @mlarsen ,
(I'm still a Bitbake/Yocto/Poky padawan but can report what I know!)
Our production VOXL2 build uses:
https://git.codelinaro.org/clo/ype/external/yoctoproject.org/poky/-/blob/f5a57e939e626a5b7c6de5b51799ca602ed355ed/meta-poky/conf/distro/poky.conf#L4
DISTRO_VERSION = "2.6.1"
DISTRO_CODENAME = "thud"
(I'm also pushing towards a new build with ubun20/kernel5.4, ~alpha level right now)
https://git.codelinaro.org/clo/ype/external/yoctoproject.org/poky/-/blob/yocto-upstream.lnx.4.0.r13-rel/meta-poky/conf/distro/poky.conf?ref_type=heads#L4
DISTRO_VERSION = "3.1.14"
DISTRO_CODENAME = "dunfell"
@mrawding was logged into wrong account for above, feel free to hit up email as well!
There's a directional level shifter on the RX pin, and it seems like our default state isn't what I have documented, and I need to investigate that!
As temporary work around, you can set the pin state with onboard utility:
voxl2-mini:/$ voxl-gpio -w 67 0
For others, you can check loopback if you have it (between pins 4/5 of J10):
voxl2-mini:/$ qrb5165io-uart-test -d 0
[INFO]: success!
Sorry for the confusion! We'll fix.
Hi @JoeC , this IMX377 is a bit of a dormant binary that we've not put any active support or testing into and aren't planning on putting anytime into at this point. We have put time into IMX412 though so that's a valid path!