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

@Alex-Kushleyev Thanks for the update! Sorry for my slow response. I was away since last Thursday. Sounds great to use the 0 values for the startup tone. That is really helpful. I will test this as soon as I can. Did you also change the frequency mapping (although I don't think I need this if I use the startup tone)?

Will you still make the change from qshell voxl_esc [arguments...] <command> to qshell voxl_esc <command> [arguments...]? If not, can you update the print_usage: https://github.com/modalai/px4-firmware/blob/main/src/drivers/actuators/voxl_esc/voxl_esc.cpp#L1350 to match with the actual usage?

@Alex-Kushleyev Thanks for your response. Sounds good.

For some background, we currently only put power on the ESC when we are about to fly. When the ESC is powered, the startup sound can be heard which is an audio notification to anybody closeby that this drone can soon start spinning up his motors. With the new PX4 firmware in sdk-1.3, there is a version check in the ESC initialization which now fails because we haven't powered the ESC at that moment. We're now thinking of keeping the ESC always powered but we still want to have this audio notification when the drone is about to fly. So that's why I was looking into this and also wanted to mimic our startup tone with the same frequencies. It would be nice if we could also send a sequence of tones or reference to preconfigured sounds but else I will just send multiple commands after each other. The python script looks nice but it doesn't work for us because it requires voxl-px4 to be not running. If you have a better suggestion of playing the tones I would be interested to hear it.

I can play tones on the ESC via the following command (after running px4-alias.sh) :

qshell voxl_esc -i 1 -p 50 -d 30 -v 20 tone

This should actually be qshell voxl_esc tone -i 1 -p 50 -d 30 -v 20 but that will fail because voxl_esc will take the last command as verb but it should take argument index 2 as verb.

https://github.com/modalai/px4-firmware/blob/f9d249f170d15c34217c849980cd8ecd4b0a17ad/src/drivers/actuators/voxl_esc/voxl_esc.cpp#L673:

const char *verb = argv[argc - 1];

should be

const char *verb = argv[2];

If you put the tone in front you get the following usage message:

Aug 06 10:10:11 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:
Aug 06 10:10:11 SPOT voxl-px4[11774]: ### Description
Aug 06 10:10:11 SPOT voxl-px4[11774]: This module is responsible for...
Aug 06 10:10:11 SPOT voxl-px4[11774]: ### Implementation
Aug 06 10:10:11 SPOT voxl-px4[11774]: By default the module runs on a wor
Aug 06 10:10:11 SPOT voxl-px4[11774]: INFO  [muorb] SLPI: Usage: voxl_esc <command> [arguments...]
Aug 06 10:10:11 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:  Commands:

which says the <command> (tone) should be in front of the arguments.

I have a question about the usage. The documentation says this:

Aug 06 10:10:28 SPOT voxl-px4[11774]:    tone          Send tone generation request to ESC
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -i <val>    ESC ID, 0-3
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -p <val>    Period of sound, inverse frequency, 0-255
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -d <val>    Duration of the sound, 0-255, 1LSB = 13ms
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -v <val>    Power (volume) of sound, 0-100

I want to know how the period relates to the tone frequency in Hz. The documentation is not correct or incomplete because I can hear a sound with period=0 which should be an infinitely high frequency. When I want to play a tone of 2110 Hz, the inverse is 0,0004739 seconds. I thought there is maybe a scaling factor of 1e5 to make it within the range of 0-255 but the sounds I hear do not match up with the frequencies I expect. How does it work?

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

@James-Strawson Any comment on this?

I have the same issue. If you try it multiple times sometimes it will work but most of the times it will crash like shown.

@James-Strawson I still haven't found the root cause but I wanted to share some of my findings. Maybe you can help my understanding. A little bit of background: we don't want to power off the drone but when we are not flying we go into a sleep state where we shut down some of the voxl programs and our own programs. Then when we wake up we start up the programs and everything should work again. It is after about 6 of these cycles where we have this issue (so it also takes a while to reproduce).

Here is some logging of where the problem just kicked in:

Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write to ch: 0 id: 14 result: -1 errno: 32
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write error: Broken pipe
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: previous client state was 2
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: Client voxl_pipe_handler-232508 (id 14) disconnected from channel 0
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write to ch: 0 id: 15 result: -1 errno: 32
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write error: Broken pipe
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: previous client state was 1
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: Client voxl_pipe_handler695511 (id 15) disconnected from channel 0
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: ERROR in pipe_server_write_to_client, client_id should be between 0 & 15
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write to ch: 1 id: 14 result: -1 errno: 32
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write error: Broken pipe
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: previous client state was 2
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: Client voxl_pipe_handler672850 (id 14) disconnected from channel 1
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write to ch: 1 id: 15 result: -1 errno: 32
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: write error: Broken pipe
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: previous client state was 1
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: Client voxl_pipe_handler507424 (id 15) disconnected from channel 1
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: ERROR in pipe_server_write_to_client, client_id should be between 0 & 15
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: ERROR in pipe_server_write_to_client, client_id should be between 0 & 15
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: ERROR in pipe_server_write_to_client, client_id should be between 0 & 15
Aug 19 20:15:14 QUAD voxl-vision-hub[1524]: ERROR in pipe_server_write_to_client, client_id should be between 0 & 15

voxl_pipe_handler is our own program. When this was logged we weren't properly closing the pipe when our program was terminated so that could explain the write errors. But after handling that correctly, we still have the issue of client_id should be between 0 & 15.

A few questions. The id behind the client name seems to be a random number although the commit which adds the random number is after SDK-1.0.0. (https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/commit/b5fc28c9fc41184e0bbeee09c7f1867f9dbc1121). How is that possible? Did you deploy it well? This is the version we use:

QUAD:~$ apt show voxl-vision-hub 
Package: voxl-vision-hub
Version: 1.6.6
Priority: optional
Section: base
Maintainer: James Strawson <james@modalai.com>
Installed-Size: unknown
Provides: voxl-vision-px4
Depends: librc-math,libmodal-pipe(>=2.4.0),libmodal-json,voxl-mpa-tools(>=0.2.5),voxl-mavlink-server,libmodal-cv(>=0.3.1)
Conflicts: voxl-vision-px4,voxl-mavlink-server(<<1.0.0)
Replaces: voxl-vision-px4
Download-Size: 88.4 kB
APT-Manual-Installed: yes
APT-Sources: file:/data/voxl-suite-offline-packages ./ Packages
Description: main hub managing communication between VOXL MPA services and autopilots

In https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/blob/master/library/src/misc.c?ref_type=heads#L168, I think you're taking the modulo of a possible negative number. The modulo can then also be a negative number (https://stackoverflow.com/questions/7594508/modulo-operator-with-negative-values) so your result is not within the specified range. See also the logging above containing a negative number.

I think that reconnecting a pipe with the same name makes that a new client id is used, possibly due to the random number in the name and then no two client names will be the same. I also saw that you changed something in that part of the code in this commit: https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/commit/773de63cb73000c08df1b04bc4e2f1e78e700816 Do you think that that could be the case? I will try to test that.

I was looking through the libmodal_pipe code because we have some issues with an error ERROR in pipe_server_write_to_client, client_id should be between 0 & 15 and I'm not sure what is causing this. We are restarting voxl programs often and I think something goes wrong with connecting/disconnecting pipes but I haven't figured it out yet.

But when I looked through the code I saw that here all file descriptors are closed: https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/blob/master/library/src/server.c?ref_type=heads#L1611. But a few lines above that (https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/blob/master/library/src/server.c?ref_type=heads#L1568), c[ch].n_clients is set to 0 so I think the code at line 1611 isn't doing anything. I don't know if it gives problems and it is probably not related to my problem but I wanted to point it out to you.

@Eric-Katzfey thanks for the update, although it is a pity since it used to work. Do you have an idea when support will be added again?