Topics created by Tjark

@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?

@Alex-Kushleyev I tested it and it works nice (I didn't test the 255 but I expect that should work). I already figured that the frequencies are now multiples of 10Hz with some minimum value (I don't know which one but at least below -p 10 I don't hear the frequency drop anymore). So it ranges up to 2550Hz. And I think you also adjusted the duration to be multiples of 10ms to match with the format of the ESC parameters?

Regarding the usage change, I understand if you don't want to create a breaking change. But I think it would be good when the print_usage matches with the actual use. It took me some trial and error to get it working. Maybe also an idea to use -f for the frequency because -p refers to period which is not correct anymore and it is now already changing the functionality of the tone generation (you could even let -p in it to keep it backwards compatible but that maybe makes it unnecessarily complicated). And also good to allow the ESC mapping to go up to 15.

For us it is sufficient to use the startup tone. But I played around a little bit with the tone generation and if you use it using the qshell commands you need to wait the duration of the tone to send a new tone (as the qshell command immediately returns and it doesn't accept a command while the sound is still playing) which makes it difficult to get the timing right in playing a tune. I don't know what the end goal should be of this but if it is playing custom tunes using the commands this is something to keep in mind I think. I had some fun trying to play the Imperial March on the ESCs which kind of works but not as smooth as the startup sound can play.

@James-Strawson Thanks for your reply! It made me realise what the error must be. We use a locally cloned repository for libmodalpipe because we want to build our software directly on the drone. This is then used in the build and link process of our software. This happened to be on the 'master' branch and not the 'SDK-1.0.0' branch. So the pipe clients use a different version than the pipe servers which is likely the cause of our errors.

@Tjark I would estimate 2 months although we may do an intermediate release that only supports RC options (Not PWM) on the IO board in about a month.

@Tjark

Thanks for pointing this out! I applied your fix in voxl-vision-hub v1.6.7 which is now up on the staging repository and will be included in SDK 1.0.1

Best Regards,
James

@ModalAI could you answer this question?

@tom Yes, thanks! That is a good idea. I will do that.
I was looking at the release page of the system image and saw this line with 1.5.3 internal release:

HLOS Added service file that changes SLPI restart level to avoid board crash when SLPI crashes

What is SLPI and could you describe a little bit more what kind of issues you saw when SLPI crashed?
I also sometimes saw px4io io_reg_get(4,0,15): data error -5 in the logging so maybe that could be related?

Thanks, I will try that

Hi,

We're still not sure what caused the scheduler issue, it was a new feature we were hoping to integrate into the stack when you found this bug but aren't able to right now. In the meantime we've pushed updated packages with these calls removed so that all of the packages can run as intended. If you update the packages via OPKG to latest there should be no issues with the scheduler.