Posts made by Morten Nissov

@Alex-Kushleyev Thanks for getting back to us so quickly.

We removed all the com.qti.sensormodule.ov7251_*.bin and the com.qti.sensormodule.irs2975c_*.bin files.
Then we ran, as you suggested, the command: voxl-camera-server -l. The output was:

existing instance of voxl-camera-server found, attempting to stop it
DEBUG:   Attempting to open the hal module
DEBUG:   SUCCESS: Camera module opened on attempt 0
DEBUG:   ----------- Number of cameras: 2
DEBUG:   Cam idx: 0, Cam slot: 0, Slave Address: 0x00E2, Sensor Id: 0x7750
DEBUG:   Cam idx: 1, Cam slot: 2, Slave Address: 0x007A, Sensor Id: 0x2975
DEBUG:   Note: This list comes from the HAL module and may not be indicative
DEBUG:          of configurations that have full pipelines
DEBUG:   Number of cameras: 2
====================================
Stats for camera: 0
ANDROID_SCALER_AVAILABLE_RAW_SIZES:
These are likely supported by the sensor
 640 x  480
 640 x  480
 640 x  480
ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS:
These are NOT necessarily supported by the sensor
 640 x  480 HAL_PIXEL_FORMAT_YCbCr_420_888
 640 x  480 HAL_PIXEL_FORMAT_BLOB
 640 x  400 HAL_PIXEL_FORMAT_YCbCr_420_888
 640 x  400 HAL_PIXEL_FORMAT_BLOB
 640 x  360 HAL_PIXEL_FORMAT_YCbCr_420_888
 640 x  360 HAL_PIXEL_FORMAT_BLOB
 352 x  288 HAL_PIXEL_FORMAT_YCbCr_420_888
 352 x  288 HAL_PIXEL_FORMAT_BLOB
 320 x  240 HAL_PIXEL_FORMAT_YCbCr_420_888
 320 x  240 HAL_PIXEL_FORMAT_BLOB
 240 x  320 HAL_PIXEL_FORMAT_YCbCr_420_888
 240 x  320 HAL_PIXEL_FORMAT_BLOB
 176 x  144 HAL_PIXEL_FORMAT_YCbCr_420_888
 176 x  144 HAL_PIXEL_FORMAT_BLOB
 640 x  480 HAL_PIXEL_FORMAT_RAW10
 640 x  480 HAL_PIXEL_FORMAT_RAW12
 640 x  480 HAL_PIXEL_FORMAT_RAW16
 640 x  480 HAL_PIXEL_FORMAT_RAW_OPAQUE
ANDROID_SENSOR_INFO_SENSITIVITY_RANGE
        min = 54
        max = 3451
ANDROID_SENSOR_MAX_ANALOG_SENSITIVITY
        3451
ANDROID_SENSOR_INFO_EXPOSURE_TIME_RANGE
        min = 0ns
        max = 1266732525ns
====================================
Stats for camera: 1
ANDROID_SCALER_AVAILABLE_RAW_SIZES:
These are likely supported by the sensor
 240 x 1629
ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS:
These are NOT necessarily supported by the sensor
 240 x  320 HAL_PIXEL_FORMAT_YCbCr_420_888
 240 x  320 HAL_PIXEL_FORMAT_BLOB
 176 x  144 HAL_PIXEL_FORMAT_YCbCr_420_888
 176 x  144 HAL_PIXEL_FORMAT_BLOB
 240 x 1629 HAL_PIXEL_FORMAT_RAW10
 240 x 1629 HAL_PIXEL_FORMAT_RAW12
 240 x 1629 HAL_PIXEL_FORMAT_RAW16
 240 x 1629 HAL_PIXEL_FORMAT_RAW_OPAQUE
ANDROID_SENSOR_INFO_SENSITIVITY_RANGE
        min = 54
        max = 0
ANDROID_SENSOR_MAX_ANALOG_SENSITIVITY
        0
ANDROID_SENSOR_INFO_EXPOSURE_TIME_RANGE
        min = 0ns
        max = 0ns
====================================
Number of cameras detected: 2
====================================

Given the output, we copied the files com.qti.sensormodule.ov7251_0.bin and com.qti.sensormodule.irs2975c_2.bin into /usr/lib/camera folder.
Then we ran: camera-server-config-helper tracking:ov7251:0 tof:pmd-tof:2 and got the following output:

successfully wrote this camera config to disk:
=================================================================
configuration for 2 cameras:
cam #0
    name:                tracking
    sensor type:         ov7251
    isEnabled:           1
    camId:               0
    camId2:              -1
    fps:                 30
    en_rotate:           0
    en_rotate2:          0
    en_preview:          1
    pre_width:           640
    pre_height:          480
    en_raw_preview:      1
    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1
    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1
    en_misp:             0
    misp_width:          -1
    misp_height:         -1
    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000
    ae_mode:             lme_msv
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           1
    independent_exposure:0
cam #1
    name:                tof
    sensor type:         pmd-tof
    isEnabled:           1
    camId:               2
    camId2:              -1
    fps:                 5
    en_rotate:           1
    en_rotate2:          0
    en_preview:          1
    pre_width:           224
    pre_height:          1557
    en_raw_preview:      1
    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1
    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1
    en_misp:             0
    misp_width:          -1
    misp_height:         -1
    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000
    ae_mode:             off
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           5
    independent_exposure:0
fsync_en:            0
fsync_gpio:          109
=================================================================
camera_server_config_helper is done

Finally, we ran: voxl-camera-server, and we got:

existing instance of voxl-camera-server found, attempting to stop it
=================================================================
configuration for 2 cameras:
cam #0
    name:                tracking
    sensor type:         ov7251
    isEnabled:           1
    camId:               0
    camId2:              -1
    fps:                 30
    en_rotate:           0
    en_rotate2:          0
    en_preview:          1
    pre_width:           640
    pre_height:          480
    en_raw_preview:      1
    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1
    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1
    en_misp:             0
    misp_width:          -1
    misp_height:         -1
    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000
    ae_mode:             lme_msv
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           1
    independent_exposure:0
cam #1
    name:                tof
    sensor type:         pmd-tof
    isEnabled:           1
    camId:               2
    camId2:              -1
    fps:                 5
    en_rotate:           1
    en_rotate2:          0
    en_preview:          1
    pre_width:           224
    pre_height:          1557
    en_raw_preview:      1
    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1
    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1
    en_misp:             0
    misp_width:          -1
    misp_height:         -1
    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000
    ae_mode:             off
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           5
    independent_exposure:0
fsync_en:            0
fsync_gpio:          109
=================================================================
thread is locked to cores: 4 5 6 7
connected to mavlink pipe
Connected to cpu-monitor
Starting Camera: tracking (id #0)
gbm_create_device(156): Info: backend name is: msm_drm
setting ov7251 BLC register for cam id 0
Starting Camera: tof (id #2)
WARNING: cam tof (id 2) does not seem to be alive
------ voxl-camera-server: Started 1 of 2 cameras
------ voxl-camera-server: Camera server is now running

Just to make sure that only one camera was working, we ran: voxl-inspect-cam -a and got:

| Pipe Name |  bytes  | wide |  hgt |exp(ms)| gain | frame id |latency(ms)|  fps |  mbt
|  tracking |  307200 |  640 |  480 |  5.04 |  111 |      179 |     11.6  | 30.0 |   73.7 | RAW8

What do you think?

Additional debugging:

Moreover, we test some other configurations:

• J7 <-> M0135 (JL) <-> M0014
• J6 <-> M0172 (J1L) <-> M0170 <-> tof

We copied the files: com.qti.sensormodule.ov7251_*.bin and com.qti.sensormodule.irs2975c_*.bin into the folder: /usr/lib/camera
We used the command: camera-server-config-helper tracking:ov7251:0 tof:pmd-tof:2 giving the following output:

successfully wrote this camera config to disk:
=================================================================
configuration for 2 cameras:

cam #0
    name:                tracking
    sensor type:         ov7251
    isEnabled:           1
    camId:               0
    camId2:              -1
    fps:                 30
    en_rotate:           0
    en_rotate2:          0

    en_preview:          1
    pre_width:           640
    pre_height:          480
    en_raw_preview:      1

    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1

    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1

    en_misp:             0
    misp_width:          -1
    misp_height:         -1

    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000

    ae_mode:             lme_msv
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           1
    independent_exposure:0

cam #1
    name:                tof
    sensor type:         pmd-tof
    isEnabled:           1
    camId:               2
    camId2:              -1
    fps:                 5
    en_rotate:           1
    en_rotate2:          0

    en_preview:          1
    pre_width:           224
    pre_height:          1557
    en_raw_preview:      1

    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1

    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1

    en_misp:             0
    misp_width:          -1
    misp_height:         -1

    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000

    ae_mode:             off
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           5
    independent_exposure:0

fsync_en:            0
fsync_gpio:          109
=================================================================
camera_server_config_helper is done

Then we run voxl-camera-server giving the following output:

existing instance of voxl-camera-server found, attempting to stop it
=================================================================
configuration for 2 cameras:

cam #0
    name:                tracking
    sensor type:         ov7251
    isEnabled:           1
    camId:               0
    camId2:              -1
    fps:                 30
    en_rotate:           0
    en_rotate2:          0

    en_preview:          1
    pre_width:           640
    pre_height:          480
    en_raw_preview:      1

    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1

    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1

    en_misp:             0
    misp_width:          -1
    misp_height:         -1

    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000

    ae_mode:             lme_msv
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           1
    independent_exposure:0

cam #1
    name:                tof
    sensor type:         pmd-tof
    isEnabled:           1
    camId:               2
    camId2:              -1
    fps:                 5
    en_rotate:           1
    en_rotate2:          0

    en_preview:          1
    pre_width:           224
    pre_height:          1557
    en_raw_preview:      1

    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1

    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1

    en_misp:             0
    misp_width:          -1
    misp_height:         -1

    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000

    ae_mode:             off
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           5
    independent_exposure:0

fsync_en:            0
fsync_gpio:          109
=================================================================
thread is locked to cores: 4 5 6 7
connected to mavlink pipe
Connected to cpu-monitor
Starting Camera: tracking (id #0)
gbm_create_device(156): Info: backend name is: msm_drm
setting ov7251 BLC register for cam id 0
Starting Camera: tof (id #2)
WARNING: cam tof (id 2) does not seem to be alive

------ voxl-camera-server: Started 1 of 2 cameras

------ voxl-camera-server: Camera server is now running

And running voxl-inspect-cam -a still gives the following output:

| Pipe Name |  bytes  | wide |  hgt |exp(ms)| gain | frame id |latency(ms)|  fps |  mbps  | format
|  tracking |  307200 |  640 |  480 |  2.28 |   51 |      294 |     11.5  | 30.0 |   73.7 | RAW8

To be sure that all the parts were working, we tested two M0172 and 2 ToF sensors, which were actually working on VOXL 2. We also swapped the tracking camera and the ToF sensor (J6 <-> J7), copying the .bin files according to and adjusting the ID numbers.

@Vinny @Alex-Kushleyev

Hi,

We are trying to configure Voxl 2 Mini with the ToF sensor and a tracking camera with the , and we're having trouble with getting the ToF sensor to work. This is with the new ToF sensor and the new interposer you suggested for us to use.

The cameras are attached in the following way:
J7 <-> M0135 (JL) <-> M0014
J6 <-> M0172 (J1L) <-> M0170 <-> tof
The voxl suite we have on the board is: voxl-suite: 1.5.0

To configure the cameras we run:
voxl-configure-sku
choosing options 23 (voxl-configure-sku) and 5 (pmd-tof ov7251 tracking).
The output was the following:

Your answers would construct the following SKU:

family code:   MCCA-M0104 (voxl2-mini-board-only (MCCA-M0104))
compute board: 6 (voxl2-mini)
hw version:    1
cam config:    05
modem config:   ()
tx config:      ()
extras config:  ()
SKU:           MCCA-M0104-C05-T0-M0-X0

This sku will be saved to persistent memory so VOXL
will remember what it is installed in, even between
system image flashes.

So we run: voxl-configure-mpa and reboot

To inspect the cameras, we run voxl-inspect-cam -a , but we were able to see only the tracking camera:

| Pipe Name |  bytes  | wide |  hgt |exp(ms)| gain | frame id |latency(ms)|  fps |  mbps  | format
|  tracking |  307200 |  640 |  480 |  2.51 |   51 |      204 |     11.5  | 30.0 |   73.7 | RAW8

So we restarted the service voxl-camera-server , but we got the following error + warnings:

existing instance of voxl-camera-server found, attempting to stop it
=================================================================
configuration for 2 cameras:

cam #0
    name:                tof
    sensor type:         pmd-tof
    isEnabled:           1
    camId:               0
    camId2:              -1
    fps:                 5
    en_rotate:           1
    en_rotate2:          0

    en_preview:          1
    pre_width:           224
    pre_height:          1557
    en_raw_preview:      1

    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1

    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1

    en_misp:             0
    misp_width:          -1
    misp_height:         -1

    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000

    ae_mode:             off
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           5
    independent_exposure:0

cam #1
    name:                tracking
    sensor type:         ov7251
    isEnabled:           1
    camId:               1
    camId2:              -1
    fps:                 30
    en_rotate:           0
    en_rotate2:          0

    en_preview:          1
    pre_width:           640
    pre_height:          480
    en_raw_preview:      1

    en_small_video:      0
    small_video_width:   -1
    small_video_height:  -1

    en_large_video:      0
    large_video_width:   -1
    large_video_height:  -1

    en_misp:             0
    misp_width:          -1
    misp_height:         -1

    en_snapshot:         0
    snap_width:          -1
    snap_height:         -1
    exif_focal_length:   0.000000
    exif_focal_len_35mm_format:0
    exif_fnumber:        0.000000

    ae_mode:             lme_msv
    msv_exposure_min_us: 20
    msv_exposure_max_us: 33000
    gain_min           : 54
    gain_max           : 8000
    standby_enabled:     0
    decimator:           1
    independent_exposure:0

fsync_en:            0
fsync_gpio:          109
=================================================================
thread is locked to cores: 4 5 6 7
connected to mavlink pipe
Connected to cpu-monitor
Starting Camera: tof (id #0)
ERROR:   Camera 0 failed to find supported preview config: 224x1557
WARNING: Failed to start cam tof due to invalid resolution
WARNING: assuming cam is missing and trying to compensate
Starting Camera: tracking (originally id #1) with id offset: 1
gbm_create_device(156): Info: backend name is: msm_drm
setting ov7251 BLC register for cam id 0

------ voxl-camera-server: Started 1 of 2 cameras

------ voxl-camera-server: Camera server is now running

Note, we also tried to modify the preview resolution, as well as disabling the preview entirely. But making these changes to the /etc/modalai/voxl-camera-server.conf file didn't seem to change the actual configuration used, as reported when running voxl-camera-server in terminal.

Do you have any suggestions for how we can get this working?

@Vinny Sorry thought I had responded, thanks!

@Alex-Kushleyev Hi again Alex, sorry for disturb just wanted to hear if you had seen the previous message? And if you could make the M0172 available?

@Alex-Kushleyev Thanks for getting back so quickly! We just have a couple of follow-up questions:

If we use this M0172 are we still able to have a tracking camera running? Such that the total setup looks something like: VOXL2 mini w/ M0178 ToF and M0014 tracking camera. If yes, then it would be great if the M0172 could be made available in the shop

Hi

We're wanting to interface our voxl2 mini board with a time of flight sensor. We had a time of flight sensor we bought from when we first got the VOXL2 mini, but it seems the exact same unit is no longer available.

Looking now, it seems our options are this tof sensor and [this adapter board](https://www.modalai.com/products/mdk-m0076-1modalai forus). Will these work together with the VOXL2 mini?

Morten

@tom Sorry about that, I thought I had answered this.

Would you be able to tell me what the default state is? I really can't recall if they've been moved since we got it.

Hi,

We wanted to start using the ethernet expansion board for the SD card slot and additional USB ports. But I notice there is nothing written in the user guide (link). Namely we're curious how we should be setting the switches in the SW1 component, among other uncertainties which can arise when we begin to use the product.

@Alex-Kushleyev Sorry for the delay, didn't notice the alert. But great, thanks!

Hi,

I see here that the voxl 4-in-1 mini ESC is rated for 2-4s (i.e. up to 16.8V at max charge). Maybe this is a stupid question, but is it possible to run LiHV 4s batteries with this ESC? The max voltage would then be 4.35*4 = 17.4.

I realize this is above the rated specs, but I was curious if the difference was small enough that it was still within tolerable margins?

Thanks

@Alex-Kushleyev Thanks for getting back to me, I must've missed reading the part regarding the CPU frequencies, now that you say it seems obvious.

the IMU frequency is not exactly 1Khz because the IMU is running using its own internal oscillator, which is does not perfectly align with 1000Hz output frequency, so the closest frequency the IMU can achieve is about 976Hz or so.

This is interesting actually, because the dt and sampling rate seems to consistently be slightly higher than 1kHz, approximately 1.03kHz. Can this make sense for the IMU?

Finally, you are absolutely right that the ROS publisher queue size being set to 1 is causing the messages to be dropped because they are published too quickly and are simply discarded when queue overflows.

I really don't see the down side of increasing the buffer size and i agree it should be set to at least the sample_rate / fifo_poll_rate , which is the number of samples that would be published at a time.
I will discuss this with the team.. thank you for pointing out the issue and good job figuring it out!

I didn't see a major change in CPU consumption, at least of the two solutions increasing the FIFO queue cost much more CPU than changing the queue size did. I would offer to make a PR if the change was more complicated than just changing a number

Anyway thanks. I'm a bit curious about the IMU, but otherwise I think this is solved.

Morten

@Alex-Kushleyev Hi again, Sorry to keep spamming. I just wanted to make sure this is up-to-date as I progress.

A bit silly I didn't realize before, but I think the problem lies in the FIFO buffer reading vs IMU queue size in the voxl-mpa-to-ros, that being said the conversion from pipe to ros also costs some latency it seems.

In voxl-mpa-to-ros, there is the following

    m_rosPublisher = m_rosNodeHandle.advertise<sensor_msgs::Imu>(topicName, 1);

Given that the FIFO buffer (with default settings) reads 10 IMU messages at a time, I think this should be changed to

    m_rosPublisher = m_rosNodeHandle.advertise<sensor_msgs::Imu>(topicName, 25);

so it has a little extra depending on what happens. This results in a very large improvement:

Getting data from log0004 and data_incr_queue.bag
voxl-logger
	mean: 0.9766417070988479 ms
	std dev: 0.0014018018261035131 ms
	total messages: 61363
rosbag record
	mean: 0.9766411567432235 ms
	std dev: 0.02937541759378401 ms
	total messages: 59305

although you can see there are still some dropped measurements and still a worsening of the standard deviation. I realized the IMU reading can also directly publish to ros from the voxl-imu-server, and this seems a little more benefit as well

rosbag record
	mean: 0.9768075697417741 ms
	std dev: 0.012558722853297727 ms
	total messages: 61147

still not totally without message dropping. This also still has some worsening about the standard deviation, I wonder if that's simply due to the conversion in _clock_monotonic_to_ros_time.

@Morten-Nissov Note, although this does make things look better, there still is a pretty significant difference between the voxl logger and recording a rosbag, with a relatively non-insignificant performance difference between the two.

Also, not really sure why the voxl-logger doesn't manage a clean 1kHz, following the configuration. Seems to be consistently off the commanded value.

@Alex-Kushleyev Followup, I can change the fifo_poll_rate_hz parameter and this has significantly increased the performance at the cost of significantly increase CPU load on the slow cores. Maybe you can advise how we should proceed.

"imu0_enable":	true,
	"imu0_sample_rate_hz":	1000,
	"imu0_lp_cutoff_freq_hz":	92,
	"imu0_rotate_common_frame":	true,
	"imu0_fifo_poll_rate_hz":	500,

Name   Freq (MHz) Temp (C) Util (%)
-----------------------------------
cpu0       1804.8     41.7    44.95
cpu1       1804.8     41.7    33.94
cpu2       1804.8     42.0    46.88
cpu3       1804.8     42.4    44.00
cpu4       2419.2     40.5     0.00
cpu5       2419.2     40.5     0.00
cpu6       2419.2     39.7     0.00
cpu7       2841.6     40.1     0.00
Total                 42.4    21.22
10s avg                       15.10
-----------------------------------
GPU         305.0     38.6     0.00
GPU 10s avg                    0.00
-----------------------------------
memory temp:       39.0 C
memory used:   746/7671 MB
-----------------------------------
Flags
CPU freq scaling mode: performance
Standby Not Active
-----------------------------------

Note even with this change some IMU messages are still dropped:

Getting data from log0003 and data_perf_fifo500.bag
voxl-logger
	mean: 0.9766390443514245 ms
	std dev: 0.001688066415815054 ms
	total messages: 61397
rosbag record
	mean: 1.0005186426507142 ms
	std dev: 0.15095098578685434 ms
	total messages: 59599

@Alex-Kushleyev Sorry for the delay, some data for you in different configurations:

Getting data from log0000 and data.bag
voxl-logger
	mean: 0.9766542020947352 ms
	std dev: 0.0013052458028126252 ms
	total messages: 61393
rosbag record
	mean: 3.230353079590143 ms
	std dev: 2.992801413066607 ms
	total messages: 18361
----------
Getting data from log0001 and data_nodelay.bag
voxl-logger
	mean: 0.9766513801209619 ms
	std dev: 0.0013052148029740315 ms
	total messages: 61342
rosbag record
	mean: 3.2565453276935123 ms
	std dev: 3.0139953610144303 ms
	total messages: 17860
----------
Getting data from log0002 and data_perf.bag
voxl-logger
	mean: 0.976641095612789 ms
	std dev: 0.001267007877929727 ms
	total messages: 61384
rosbag record
	mean: 3.73874577006071 ms
	std dev: 3.513557787123189 ms
	total messages: 15819
----------

Note significant differences in messages for each, indicating lots of message drop by the ros node.

Considering the sampling rate and standard deviation for different configurations. Logging was done with voxl-logger -t 60 -i imu_apps -d bags/imu_test/ and rosbag record /imu_apps -O data --duration 60. I tried setting the rosbag to record with --tcpnodelay, but this seems to have no effect. During the performance run, the cpu usage was as follows:

Name   Freq (MHz) Temp (C) Util (%)
-----------------------------------
cpu0       1804.8     40.1    22.33
cpu1       1804.8     39.7    18.10
cpu2       1804.8     40.1    17.82
cpu3       1804.8     39.7    16.16
cpu4       2419.2     39.0     0.00
cpu5       2419.2     38.6     0.00
cpu6       2419.2     37.8     0.00
cpu7       2841.6     39.0     0.00
Total                 40.1     9.30
10s avg                       12.26
-----------------------------------
GPU         305.0     37.4     0.00
GPU 10s avg                    0.00
-----------------------------------
memory temp:       37.8 C
memory used:   734/7671 MB
-----------------------------------
Flags
CPU freq scaling mode: performance

The only thing which seems out of the ordinary here is that many CPUs are operating consistently at low frequency. Maybe you have a comment on why that could be? Otherwise, it seems the transfer from the voxl-imu-server to ros causes quite a bit of loss in messages. Here is some voxl 2 mini install information:

--------------------------------------------------------------
system-image: 1.7.8-M0104-14.1a-perf
kernel:       #1 SMP PREEMPT Sat May 18 03:34:36 UTC 2024 4.15
--------------------------------------------------------------
hw platform:  M0104
mach.var:     2.0.0
--------------------------------------------------------------
voxl-suite:   1.3.3
--------------------------------------------------------------

with this IMU config:

        "imu0_enable":  true,
                "imu0_sample_rate_hz":  1000,
                "imu0_lp_cutoff_freq_hz":       92,
                "imu0_rotate_common_frame":     true,
                "imu0_fifo_poll_rate_hz":       100,
                "aux_imu1_enable":      false,
                "aux_imu1_bus": 1,
                "aux_imu1_sample_rate_hz":      1000,
                "aux_imu1_lp_cutoff_freq_hz":   92,
                "aux_imu1_fifo_poll_rate_hz":   100,
                "aux_imu2_enable":      false,
                "aux_imu2_spi_bus":     14,
                "aux_imu2_sample_rate_hz":      1000,
                "aux_imu2_lp_cutoff_freq_hz":   92,
                "aux_imu2_fifo_poll_rate_hz":   100,
                "aux_imu3_enable":      false,
                "aux_imu3_spi_bus":     5,
                "aux_imu3_sample_rate_hz":      1000,
                "aux_imu3_lp_cutoff_freq_hz":   92,
                "aux_imu3_fifo_poll_rate_hz":   100
        

@Alex-Kushleyev Thanks! I'll try this, note I should have mentioned this is with a voxl2 mini computer and on the ROS side the only thing happening is recording to rosbag.

Morten

Hi,

We've lately been noticing a lot of inconsistency in the publishing frequency and sample rate (from time stamp) of the IMU when publishing to ROS with the voxl-mpa-to-ros tool using SDK 1.1.3. This error is showing similar symptoms as other people (like this but doesn't seem to be fixed by setting CPU to performance mode. Using voxl-inspect-imu shows a dt of about 1ms, corresponding well to 1kHz (with the default IMU config).

We diagnose this problem primarily using rostopic hz as well as with the following plot of IMU sampling rate we noticed while doing VIO calibrations. We tried also setting the sampling rate to 200z instead, to see if this would alleviate some pressure, but still there is quite a lot of inconsistency (of course worse with 1kHz).

This has been tested with very few other services running in the background, so compute usage when this occurs is minimal. The only thing running with any noticeable compute usage is voxl-px4

I was curious if this is expected behavior or if you had any suggestions for how to troubleshoot/debug/solve this problem?

@Alex-Kushleyev Do you think it is possible to reuse params between drivers? E.g. those which shouldn't be different between the too like baud, rpm min, rpm max, etc?
I was tempted to implement the extra serial read in the voxl_esc driver for this reason, to avoid doubly defining parameters which should be the same, but this is probably more complicated overall.

Also, the mini ESC does not have the jumper to modify the IDs, sorry!

Ah unlucky, but thanks for checking.

@Alex-Kushleyev Sorry for not responding, and thanks for getting back to me.

I was curios if this jumper functionality was available on the mini? I'm guessing no?

Otherwise we'll proceed with your recommendations, it doesn't seem so challenging to implement these changes.

Edit: Just a quick question for a bug we found early on. I've made a copy of the driver and am trying to build it, but I am running into the following error message:
Duplicate parameter definition: VOXL_ESC_FUNC1+
I have removed entries from the params.c to make sure things are not doubly defined, but this one is not even defined there:

// The following are auto generated params from control allocator pattern, put here for reference

// Default ESC1 to motor2
//PARAM_DEFINE_INT32(VOXL_ESC_FUNC1, 102);

//PARAM_DEFINE_INT32(VOXL_ESC_FUNC2, 103);

//PARAM_DEFINE_INT32(VOXL_ESC_FUNC3, 101);

//PARAM_DEFINE_INT32(VOXL_ESC_FUNC4, 104);

I've looked for other references to VOXL_ESC_FUNC1 but I am not finding the right place, would you have any idea why this is now getting doubly defined.