@Maxwell-Schaefer Thank you! I was able to set the model match to off using the controller screen.

@Eric-Katzfey

Thank you for reverting back. I am trying to proceed with the same approach.
I am facing some errors while going with this approach , I am trying to debug them.

Another approach :-
I am also thinking to hardcode the joystick based turtle mode to the voxl_esc.cpp.
The manual control values will be monitored and once the value of the assigned button is clicked, the turtle mode will be enabled.
Do you think it is a good approach?

@Eric-Katzfey
hey,
I observed something while the above behaviour still persists.
The modem and the camera server is showing not running while checking through the inspect services command.
I do not know whether this is related to this issue, but the voxl 2 is rebooting after sometime, the reboot is not constant and I am not able to able to find the reason for the reboot. Can everything be related to each other.
I am using the Microhard modem

Screenshot from 2025-11-10 15-27-45.png

Screenshot from 2025-11-10 15-30-27.png

@ravi I'm suspecting you have a bad cable or the cable is subject to some interference. Can you try this on a benchtop with just a VOXL 2 and an FC v2 and no other components? Is it currently integrated into a custom drone? Can you look at the signal quality on the TX and RX UART lines with an oscilloscope?

@jeremyrbrown5 we figured it out, we just changed the name of the model to yolov8n_float16.tflite. Pretty spot on now!

@Cliff-Wong Thanks! I will try this as soon as possible and report how it works out.

@Eric-Katzfey interesting, think you for this information. Once i demo this drone for a couple weeks in its current BNF w/ ndaa add ons configuration I will be looking to move to a smart system and incorporating optical hold and other gps denied search features.

@taiwohazeez Can you post a video of it trying to fly?

@Eric-Katzfey Thanks for your update. We tried it on one of our drones but we had some strange issues regarding invalid setpoints afterwards and we think it may be caused by a voxl-px4 version mismatch. We were running version 1.14.0-2.0.98 of voxl-px4 and the version you provided is 1.14.0-2.0.116. Would it be difficult to provide a patch for version 1.14.0-2.0.98?

We also had our first log of that it occurred again with our forked voxl-mavlink-server. The drone continued its flight now which is good. This is the changed function:

void mavlink_services_handle_system_time(mavlink_message_t* msg) { // collect and consolidate information int64_t time_now_ns = my_time_realtime_ns(); int64_t time_now_s = time_now_ns / 1e9; int64_t gps_time_us = mavlink_msg_system_time_get_time_unix_usec(msg); int64_t gps_time_s = gps_time_us / 1e6; // check gps time is valid if(gps_time_s == 0) return; bool within_10_seconds_original = abs(time_now_s - gps_time_s)<10; bool within_10_seconds_correct = llabs(time_now_s - gps_time_s)<10; if (within_10_seconds_original != within_10_seconds_correct) { printf( "WARNING! The check if we are within 10 seconds gives an incorrect result due to wrong usage of abs.\n" "Original: %s, Correct: %s (time_now_s=%lld, gps_time_s=%lld, diff_original=%d, diff_correct=%lld)\n", within_10_seconds_original ? "true" : "false", within_10_seconds_correct ? "true" : "false", (long long)time_now_s, (long long)gps_time_s, abs(time_now_s - gps_time_s), // truncated 32-bit diff llabs(time_now_s - gps_time_s) // correct 64-bit diff ); } // if we are within 10 seconds, good enough if(within_10_seconds_correct){ if(time_needs_setting){ printf("detected system time has already been set\n"); } time_needs_setting = 0; return; } else time_needs_setting = 1; if(!time_needs_setting) return; struct timespec ts_now; ts_now.tv_sec = time_now_s; ts_now.tv_nsec = 0; struct timespec ts_gps; ts_gps.tv_sec = gps_time_s; ts_gps.tv_nsec = 0; printf("WARNING! System wants to use GPS system time message to set UTC clock from %s to: %s", asctime(gmtime(&ts_now.tv_sec)), asctime(gmtime(&ts_gps.tv_sec))); printf("We will ignore this system time message and we won't update the clock"); // if (clock_settime(CLOCK_REALTIME, &ts) < 0) { // perror("Failed to set system time to GPS time"); // return; // } time_needs_setting = 0; return; }

And we got log lines like this:

Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:29 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:29 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:30 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:30 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:31 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:31 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:32 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:32 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:33 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:33 2025

but I don't yet understand why it is triggering this log because both timestamps seem to be identical. Maybe you have an idea?

Hi @SKA ,

I believe i fixed this issue with full-follow mode in the camera server. Now EIS has a body->imu transform, which is read from the extrinsics file and is used to properly rotate the image, instead of hi-jacking the cam->cam_eis transform.

So now your cam->cam_eis transform should work. Please make sure the imu_apps->cam transform is correct, if your camera is rotated 90 degrees.

Please check the commits from Nov 10 : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commits/dev

Alex

@l05 can you try running the ./make_package.sh script inside docker? also if you are just trying to deploy your app, you can copy it directly from voxl-mpa-tools/build64/tools, to voxl2 using adb or ssh (assuming the build itself succeeded).

Alex

@jeremyrbrown5 Ah, yes, that'll do it.

@Muqing-Cao Here you go: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-vision-hub/-/blob/dev/src/vio_manager.c?ref_type=heads#L450

@Hunter-Scott If you delete all logs then fly you don't see any log files afterwards?

@Jakub-Tvrz said in Starling 2 Max for indoor:

We haven't bought anything yet, but we are deciding what will be the best for our warehouse inventory application. Of course, we considered the ToF option. But you still say: "however, it is not... great" - does that mean that Starling 2 is better for our application? Or does Dual vs Triple camera for Visual Inertial Odometry also have an impact?

Reply

Depends fully on your use case. I will say that PX4's instance of obstacle avoidance is not fantastic, but it is better than nothing. In my opinion I would go w/ the model that has all the bells and whistles in case you need the hardware and decide to develop your own collision avoidance or somethign of that nature.

@lhermosillo
That is harsh. Do you have a bare board, or one with some additions? If you can use the bare voxl2, try that. If you have been using the bare board all along, I'm stumped here. I'd maybe try to reinstall the modalai-qdl env, or use another image. Maybe the qdl command itself instead of the webUI. Hope you'll be able to save your board!

@aspen The landing detector in PX4 isn't perfect (obviously) so in this case it didn't detect the landing. I would map one of the switches to toggle between arm and disarm so that when the drone lands you can disarm via switch. Did you try the v1.16 package?

@N-Chen
To anyone reading this, maybe encountering the same issue in the future.
I've tested the board with a guy that has a lot of experience with the voxl2 board,
According to him, the board was faulty, probably some electrical issue, the amperage did not cross 0.1, and the board usually runs on something like 0.5.
I've replaced my board as well as my power-supply cables (which were also under par).

@alan123 If it keeps reporting changing to a new UART baudrate then that's an indication that it isn't connecting at all to the GPS unit. You could also put an oscilloscope on the lines to see if you can detect traffic from the GPS and from VOXL 2.

@latif @Moderator , is it possible to get any help from ModalAI on this?