Hi,

You'll want to make your own project that builds a package that can be deployed to a voxl. Our projects generally follow a four-script system.

install_build_deps.sh The script that install the build dependencies of a project. If you're writing an opencv process for voxl you'll probably need voxl-opencv and libmodal-pipe at the very least to get your code to work. (If you haven't already, check out our docs on our pipe architecture to see how to grab camera frames in userspace).

build.sh The script that actually builds the codebase that you're using, will set up a cmake toolchain to make sure that you're building with the right architecture/gcc version and put all of the build files in a build directory for packaging.

make_package.sh The script that bundles all of the built files, as well as any config/other files that your project will use into a standard debian or opkg package (opkg for voxl1 or debian for voxl2/rb5)

All three of those scripts should be run inside of the voxl-cross docker image that we've built as our primary build environment; it has all of the toolchains that you may need baked in, as well as the correct gcc versions for our different platforms.

Finally, Since you're building an opencv project, I'd strongly recommend that you look at our voxl-camera-calibration package. This is a very good example of how to use libmodal-pipe to get camera images, and then pass them off to opencv (in this case the calibration routines) for processing. The project also have fully flushed out versions of all of the aforementioned scripts that you can copy into your project as a good starting point.

@modaltb
please if you can give me some info it will be much appreciate

@Taylor-Presley Right. Some cables work some don't.

@modaltb Thanks a lot . I have updated to system image 1.3+. The device can be find on /dev

Best Wishes

Thanks, @modaltb! yes, that seems to be the cause; we received two sentinel drones yesterday and for the same reason they have not had GPS signal available either. But that's ok, we don't need GPS for indoor flight tests.

could you please comment on the odometery problem which I mentioned in the first post? I have two odemetry components with id=1 and id=197 in MAVLink Inspector in QGC. The odometry component with id=1 works fine and voxl-inpsect-imu outputs correct values in the VIO-enabled, GPS-disabled setting. But I get invalid local position for ekf2 status in MAVlink console and "reject position mode" message when try to fly the drone with RC in position mode.

do I need to reset the PX4 firmware?

thanks

Hi Xeno,

We are not familiar with that sensor. The Flight Core portion of m500 is stock PX4.

You could look at the connectors found on the Flight Core datasheet and see if there is an appropriate connection. Then you could see if PX4 supports that sensor. If it does not, you will need to develop the driver on your own. You can find details on building PX4 for Flight Core on the Flight Core Firmware page

Update: I've tried again and the licenses are now available. Seems like Qualcomm needed a day or so to propagate licenses.

Thanks again for your help Eric.

@Steve-Turner
Thanks for your information and I will check it.
Dan

Hi @Ed-Sutter,

A platform release just includes the latest sdk along with the system image build. As for voxl-configure-opkg, this was replaced by voxl-configure-pkg-manager with the same functionality.

@張為超 You are correct about the Original Order Number. In your case it would be 2838.

First step for the RMA process is to fill out the RMA form and send it to rma@modalai.com
Second is to purchase the RMA diagnostic (In this case you would choose drone diagnostic).
Third would be to ship the drone back to ModalAI Headquarters.
When we receive it we will look it over and email you a report of our findings and how to proceed.
Step five usually is only after the team has looked over the RMA and we have discussed how to proceed.

Hi @SHofmeester ,

Sorry this message got lost on my side, any luck making progress on this?

Hi @shlee853 ,

Sorry this is a super old post that got missed, checking in to see if you were able to resolve the issue or not?

this is a standard linux networking system. Have you googled how to manage the network interfaces?

Maybe make sure your routing tables are properly configured for what you are trying to do? https://opensource.com/business/16/8/introduction-linux-network-routing

yes, it sounds like a cable is not connected or was damaged somehow

@Chad-Sweet got it, thanks

@Chad-Sweet said in Change Altitude of Take-off mode:

MIS_TAKEOFF_ALT

I am able to set this value with the desired height. The issue is that why is it that the takeoff service height is ignored?

Thanks, I will try that

@Chad-Sweet I believe this is what I need. Thanks.