Posts made by Tjark

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

@brycek That's great!

@Modalai could you still answer the question if this is a good way of handling this?

@ModalAI could you answer this question?

We are trying to get a drone working with SDK 1.0.0 but we are unable to get a RC controller properly connected. It worked with SDK 0.9.5.

We have a RadioLink RC controller connected to the VOXL2 IO board similar to the Graupner setup: https://docs.modalai.com/voxl2-io-user-guide/#using-sbus-graupner-gr-16 but we don't get RC signals through in QGroundControl. This topic seems to suggest that the VOXL2 IO board is not yet supported for SDK 1.0.0 but that is for an ESC: https://forum.modalai.com/topic/2429/voxl2-io-m0065-support-on-px4-1-14-in-sdk-1-0-0. Should it be possible to connect our RC with VOXL2 IO?

@brycek We had the same issue but we managed to get it working. We have the following setup with 3 cameras:

Camera name: hires2
Camera type: imx412
Camera id: 0
Camera slot: 2

Camera name: hires
Camera type: imx214
Camera id: 1
Camera slot: 3

Camera name: tracking
Camera type: ov7251
Camera id: 2
Camera slot: 4

We added an extra option to /usr/bin/qrb5165-configure-cameras:

17) # Hires(imx214) + Hires2(imx412) + Tracking(ov7251)
		CAM_LIST+=("hires2:imx412:0")
		CAM_LIST+=("hires:imx214:1")
		CAM_LIST+=("tracking:ov7251:2")
		BIN_LIST+=("/usr/share/modalai/chi-cdk/ov7251/com.qti.sensormodule.ov7251_4.bin")
		BIN_LIST+=("/usr/share/modalai/chi-cdk/imx412/com.qti.sensormodule.imx412_2.bin")
		BIN_LIST+=("/usr/share/modalai/chi-cdk/imx214/com.qti.sensormodule.imx214_3.bin")
		;;

So the camera name, type and id are used in the CAM_LIST+= part and the camera type and the camera slot are used in the BIN_LIST+= part.

Then we can execute voxl-configure-cameras 17 which places the camera drivers in the correct places and creates a default voxl-camera-server.conf file. Then when we do voxl-camera-server --list, all the cameras will appear.

Also small note that you need to update the file /usr/bin/qrb5165-print-camera-configs if you want the option to be shown when executing voxl-configure-cameras --help

@ModalAI, is this the correct way to approach this or is this not recommended because problems are expected when using it this way?

@brycek I think you can adjust it to match your situation

I installed SDK 1.0.0 on a VOXL2 and during compiling of our own code I get the following error:

fatal error: voxl_vision_hub.h: No such file or directory
 #include <voxl_vision_hub.h>
          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

I checked the folder /usr/include/ and the file is missing over there:

voxl2:~$ ls /usr/include/voxl_*
/usr/include/voxl_common_config.h  /usr/include/voxl_imu_server.h  /usr/include/voxl_qvio_server.h                 /usr/include/voxl_vision_px4.h
/usr/include/voxl_cutils.h         /usr/include/voxl_io.h          /usr/include/voxl_slpi_uart_bridge_interface.h

/usr/include/voxl_io:
i2c.h  other.h  spi.h

/usr/include/voxl_trajectory:
setpoint_position.h  trajectory_evaluation.h  trajectory_interface.h  trajectory_protocol.h  trajectory_utils.h  voxl_trajectory.h

I believe this is caused because the new header file is not set as public header in this file: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-vision-hub/-/blob/master/src/CMakeLists.txt#L32

I would expect that when that is changed to

set_target_properties(voxl-vision-hub PROPERTIES PUBLIC_HEADER "../include/voxl_vision_px4.h;../include/voxl_vision_hub.h")

it will work.

Is that correct?

I'm installing the new SDK 1.0.0 which has voxl-suite 1.0.0. When trying to install ros-melodic-tf2-geometry-msgs I get the following error:

voxl2:~$ apt install -y ros-melodic-tf2-geometry-msgs
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ros-melodic-tf2-geometry-msgs : Depends: ros-melodic-orocos-kdl but it is not going to be installed
                                 Depends: ros-melodic-python-orocos-kdl but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

I dove into it a little bit more and the issue is that ros-melodic-tf2-geometry-msgs depends on ros-melodic-orocos-kdl which in turn depends on libeigen3-dev.

But voxl-suite now depends on voxl-feature-tracker which depends on voxl-eigen3 and voxl-eigen3 conflicts with libeigen3-dev:

voxl2:~$ apt show voxl-eigen3
Package: voxl-eigen3
Version: 3.4.0
Priority: optional
Section: base
Maintainer: matt.turi@modalai.com
Installed-Size: unknown
Conflicts: libeigen3-dev
Replaces: libeigen3-dev, lib32-libeigen
Download-Size: 1014 kB
APT-Manual-Installed: yes
APT-Sources: file:/data/voxl-suite-offline-packages ./ Packages
Description: Eigen3 Library packaged up for APQ

What is the recommended way to get ros-melodic-tf2-geometry-msgs installed? In our case we don't need voxl-feature-tracker. Is there a way to combine it with voxl-eigen3? Or should we just not use voxl-suite?

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

Hi,

We have an issue where sometimes the drone drops out of the air. Looking at the journalctl logging we see a WARNING: PX4 Mavlink Disconnected message at the time when it drops. Also, a few seconds before it has disconnected we see the message kernel: ==> rtl8188e_iol_efuse_patch. Has anyone else experienced this or has an idea what could be causing this?

Also, I saw that there are two ways to get the WARNING: PX4 Mavlink Disconnect. One with a disconnect callback and one with a timeout. Would it be an idea to tell in the logging message of the timeout that the disconnect is caused by a timeout?

This is the software we have running:

--------------------------------------------------------------------------------
system-image: 1.5.2-M0054-14.1a-perf-nightly-20221219
kernel:       #1 SMP PREEMPT Mon Dec 19 02:17:54 UTC 2022 4.19.125
--------------------------------------------------------------------------------
hw version:   M0054
--------------------------------------------------------------------------------
voxl-suite:   0.9.5
--------------------------------------------------------------------------------


PHIL:~$ voxl-inspect-services -v
 Service Name         |  Version  |  Enabled  |   Running   |  CPU Usage
---------------------------------------------------------------------------
 docker-autorun       |    1.2.4  | Disabled  | Not Running |  
 docker-daemon        |    1.2.4  | Disabled  | Not Running |  
 modallink-relink     |   0.16.1  | Disabled  | Not Running |  
 voxl-camera-server   |    1.3.7  |  Enabled  |   Running   |     0.0
 voxl-cpu-monitor     |    0.3.0  |  Enabled  |   Running   |     0.0
 voxl-dfs-server      |    0.1.0  | Disabled  | Not Running |  
 voxl-imu-server      |    0.5.0  |  Enabled  |   Running   |     0.0
 voxl-mavlink-server  |    0.3.0  |  Enabled  |   Running   |     0.0
 voxl-modem           |   0.16.1  | Disabled  | Not Running |  
 voxl-portal          |    0.5.0  | Disabled  | Not Running |  
 voxl-px4-imu-server  |    0.1.2  | Disabled  | Not Running |  
 voxl-px4             |  1.12.31  |  Enabled  |   Running   |     0.0
 voxl-qvio-server     |    0.8.2  |  Enabled  |   Running   |     0.0
 voxl-remote-id       |    0.0.5  | Disabled  | Not Running |  
 voxl-softap          |    0.1.5  | Disabled  | Not Running |  
 voxl-static-ip       |    0.1.5  | Disabled  | Not Running |  
 voxl-streamer        |    0.4.1  | Disabled  | Not Running |  
 voxl-tag-detector    |    0.0.4  | Disabled  | Not Running |  
 voxl-tflite-server   |    0.3.1  | Disabled  | Not Running |  
 voxl-time-sync       |    1.2.2  | Disabled  | Not Running |  
 voxl-vision-px4      |    1.4.0  |  Enabled  |   Running   |     0.0
 voxl-wait-for-fs     |    1.2.2  |  Enabled  |  Completed  |  

Thanks, I will try that

As I understand we need to use the modified PX4 firmware provided by modalai on https://docs.modalai.com/flight-core-firmware/. That is currently based on version 1.11. Is there already an estimate of when version 1.12 or 1.13 will be released? I need to use a parameter which was introduced in version 1.12 so I'm curious to know.

Also, what is expected if the original PX4 firmware (1.12 or 1.13) is used? I see some people on this forum using it and sometimes it is disregarded but sometimes you seem to be interested in the results. Could it work? Would be great to have a little bit more information on that.

And if you are still in the testing phase of a new firmware version, is it possible to use some beta versions?