@mrawding was logged into wrong account for above, feel free to hit up email as well!
Posts made by modaltb
RE: VOXL2 Mini J10 UART
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.
RE: Voxl 2 IO and PWM outputs
@AP123 because we can't provide the bootloader binary as a download, any existing M0065 HW needs to be replaced.
You can use email@example.com to arrange a replacement.
It's technically possible to update in the field but we can't provide the bootloader binary so it needs to be sent into the modalai office.
RE: The qrb5165-kernel repository has disappeared.
Hi @dongsup-seo thanks for reporting, things should be up again here: https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel
RE: Integration of custom visual sensors
The Starling has this breakoutboard attached:
It has an apps proc UART available at
Perhaps you can use this UART, and voxl-mavlink-server has external FC support:
RE: kernel build
Hi @Enrico-Bandera ,
I've seen this to, and I believe my work around was to sort of remove the working output/or start from a clean git clone.
There's some bitbake/poky cache something or other that causes this problem that I'm not clear yet how to fix... holler if you are still stuck.
RE: VOXL IO and SDK 1.0.0 on VOXL 2
the px4io implementation changed in px4 1.12 to 1.14... SDK 1.0.0 moved to 1.14 and the protocol busted...
We are planning to support SBUS in a SDK 1.0.1 release (as an engineer, I will say it's coming out soon, but I'm optimistic always... so I can't put a date down just yet).
As far as PWM support, we are looking at ripping px4io totally out of the voxl2io board and putting our own FW inside so we aren't tied to px4io at all.
Sorry for the inconvenience here, the support matrix got way to out of control and we are trying to get PWM/RC support back going with voxl2io properly and not use px4io which we can't control...
We can provide updates as we have them, including swapping out voxl2io boards in case you can't reflash in the field.
RE: ESC (PWM) calibration for flight core v2
@Anubhav I believe use QGC should work, I would not try to use the method for FCv1 (since we couldn't power over USB, you weren't able to use the standard method in QGC).
If you are powered off USB on FCv2 and use the QGC method, what issue are you having?
RE: SDK V1.0.1 Beta
@Mastermind OK I think I'm seeing things a bit more now!
First, let's confirm, when you say LTE v2, you mean this right? https://docs.modalai.com/4G-LTE-Modems/
I ask because Tom brought up, our 5G Modem, has a real UART: https://docs.modalai.com/5G-Modems/
OK back to the question, I think what you are seeing now, if you go directly from a USB port (say LTE board or MH board) to a Flight Core, you will basically be doing what happens when you connect a Flight Core to QGC.
That USB port on FCv1/FCv2 J3 is used for QGC connections and not telemetry like we expect via a UART TELEM. (as far as I know).
So imagine if you had QGC installed on VOXL2 (this won't work!) and then you had the setup of FC straight into USB, you would then have a QGC USB connection like a host PC!
Now, if there is a USB to Serial adapter between the LTE or MH board and a Flight Core's TELEM UART port, then I would expect something similar to enumerate in LSUSB (like /dev/ttyXXX) that COULD act as a UART, and then this would be OK to try with voxl-mavlink-server, but we likely need to modify code as it expects /dev/ttyHSX at this point.
voxl2 --> add on board with USB --> straight to FC J3, not gonna work as we intended
voxl2 --> add on board with USB --> USB to Serial --> to FC TELEM port, should work as intended!
We are still pressing on with the DSP UART path and will get that online anyhow ASAP (but I'm kinda slow lately so bear with me)
RE: SDK V1.0.1 Beta
@Mastermind what are you wanting to use on VOXL2 to talk to the external flight controller SW wise, you own program, or voxl-mavlink-server?
I was about to start testing and I failed to realize we need to do some work to get voxl-mavlink-server to use this new interface... so more like EOW
RE: esc 4 in i issue
This is how we enable the driver in our board (e.g. FCv2):
The serial ports are kinda hard coded... e.g. FCv2
Quick glance here and the v6c doesn't use this driver... we don't make that board so can't mess with it really, but it would be enabled here:
So I think you'd need to rebuild the FW and add the
MODAL_IO_DEFAULT_PORTto what you need, and enable the driver in the v6c config
RE: SDK V1.0.1 Beta
Hi @Mastermind sorry I'm not following the USB Microhard request, but if we're talking about getting a UART exposed from the applications processor side to support an external flight controller from the J18 connector like Moderator said above, I can get you a pre-release to try out.
It uses this library that's still in a branch...
This will allow you to open a UART via the DSP, but from the Ubuntu side, so it will appear like a normal UART.
This response is soupy, so holler if you are confused !
RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)
Hey @John-Nomikos-0 , you'll need to know how things are wired up to "quickly" be able to use this guide: https://docs.modalai.com/modal-esc-px4-user-guide/#actuator-setup-using-qgc
If you don't know the wiring, it becomes a fun guess and check game....
To reverse, you could try these I believe:
MODAL_IO_SDIR1 MODAL_IO_SDIR2 MODAL_IO_SDIR3 MODAL_IO_SDIR4
RE: Camera orientation parameter
We're trying to improve customizability... our approach now is we're shipping various flavors of sensors/variants/HW locations....
TLDR: here's pre-release binaries to try, these go into
Longer version: we've started docs here: https://docs.modalai.com/voxl2-image-sensors/
Starting in SDK1.0, we began to put the sensor MODULE bin options in
These are the binaries that tie the HW location, and also is in charge of pulling in the appropriate sensor SO in
voxl2:/usr/share/modalai/chi-cdk$ ls imx214 imx214-flip imx335 imx377 imx412 imx678 irs1645 ov7251 ov7251-combo ov7251-combo-flip ov7251-fsin ov7251-fsout ov9782 ov9782-combo ov9782-combo-flip
For example, this is our preview release, there's
The idea is, you want to find the appropriate bin to use, for example my options:
voxl2:/usr/share/modalai/chi-cdk$ ls imx214-flip/ com.qti.sensormodule.imx214_flip_0.bin com.qti.sensormodule.imx214_flip_2.bin com.qti.sensormodule.imx214_flip_3.bin com.qti.sensormodule.imx214_flip_4.bin
The so that will be used by these bins is