ModalAI Forum

4G / LTE is a cellular protocol. The range and performance is determined by the cellular carrier whose service you are paying for. You can use your smartphone as a good proxy for performance. It would be best if you were comfortable with VPN and networking technologies before you try to build a cellular connected drone. There is know how and work involved.

The Sentinel and VOXL 2 are open development platforms. ModalAI does not use or support Matlab UAV toolbox. So, if you need that feature you will need to figure out how to implement on VOXL 2. VOXL 2 is a Debian Linux system, so it is very flexible

Coral advertises 4 TOPS with tensorflow lite and VOXL 2 should achieve 15 TOPS with tensorflow lite.

Thanks for the replies. The use case is low-bandwidth, short range communication to the VOXL using low-energy devices, which only have BLE.

LuxF7HD is a betaflight flight controller. https://rpg.ifi.uzh.ch/docs/IROS18_Falanga.pdf developers from the university at zurich were able to bridge the betaflight controller to the onboard computer. we think we have the wiring portion done, but we need to somehow send the parameters changes from the voxl to the betaflight controller via a serial port. we are using serial port j10012 currently. please let us if you have any ideas on how to bridge the two

It sounds like QGC is buffering, have you reached out to the QGC team? The VOXL is a Linux device with standard Linux networking. You should be able to use standard Linux routing techniques to route your IP traffic

We will have to look into this, we don't have any good answer

Has someone already solve this?

@Hammas-Ali Yes, those would all be great features but we have not implemented them at this time. However, we may be able to provide guidance on the streaming re-connection issue. I'll ask some of our team members to take a look.

@amitga Yes you can. That code shouldn't be there since it prevents the exact use case that you are trying to run.

There should not be any difference in wifi performance between the two images. We only have the wifi driver as binary and do not have access to the source code. WiFi issues are almost always interference related. Maybe the channel changed? Can you look at a wifi analyzer app using your smartphone to see that it's on an open channel?

Thanks so much!! This is super easy solution

Hi, We did a bit of digging and this was an issue with portal's handling of YUV422 images (which is a supported feature but we hadn't tested since we rarely see images in this format). If you look at the image from the uvc camera in voxl-streamer everything should look fine, and if you update your portal to >=v0.4.2 (this will be included in our next software release) everything should look fine.

@Eric-Katzfey Yes, it works. I am not sure if changing the settings on the GCS side will affect the connection to other copter. But now it seems fine. Thanks.

Also note that usb file transfers are much faster dealing with a single large file than hundreds of smaller ones, and the logging of camera images through voxl-logger currently saves each image in it's own file, so it's usually much faster to tar/zip a log folder and then pull the tarball.

Scratch that. We tested more in a GPS rich environment and are seeing similar yaw features. This might just be an issue with the hardware pitch. Will investigate level horizon in air calibration seen here: https://docs.modalai.com/calibrate-px4-horizon/

added note here: https://docs.modalai.com/microhard-add-on-manual/ [image: 1664305893043-35caac2f-8a47-4fa0-86c1-5bef5b249e25-image.png]

@Alex-Gardner that did it! We definitely need to update the docs. I was going over all the Voxl Vision docs I could find and I don't recall seeing anything about voxl-mavlink-server. A flowchart might be nice, I ran into a similar issue with Voxl Camera Streamer and the camera server service, but I figured that one out thanks to the docs.

@Rowin-Leemeijer Oops forgot to stop the link: https://www.cablecreation.com/collections/usb-2-0-3-0/products/usb-ethernet-adapter

Hi @Anubhav , That's very odd that J8 is not working. It's a hard short to the 5V power subsystem that feeds the board. There is no limitation I can see that would prevent that. I know for Spektrum based receivers, there is a specific 3.3V power sequence and bit-wiggling that occurs for binding (through Flight Core J12), so I'm not sure if your receiver is expecting something similar and does not like the "always on" 5V on M0018 J8 and J9. The 4G LTE modem M0030 ports J5 and J6 are safe to use. They expose a 500mA limited 5V to those pins. They are USB2 ports @500ma, with USB HS data on pins 2/3, and DGND on Pin 4. They are turned on sometime after power-on once the hub enumerates with Voxl, so I wonder if that delay ON time is what is helping your receiver bind and communicate properly. You might be venturing into a Software domain which I am not an expert in, so if just knowing that J5 and J6 are "safe" and this works for you, then great! If not, we may need to pull in some SW folks to dig deeper. Thanks! Vinny