@Alex-Kushleyev Understood.

We were thinking of the mini ESSC: https://www.modalai.com/products/voxl-esc-mini?variant=47206467371312. But that's not necessarily a hard requirement, is it written which ones have this jumper? Sorry if I missed it.

We're not opposed to doing some of this ourselves either, if it's not a feature you were planning on or wanted to add. Before seeing this message we were brainstorming re-purposing the GNSS UART for this instead, and other such more "hacky" solutions.

Morten

Hi,

As a followup to this, we've made an I2C driver for our magnetometer, which seems to work. Though reading X, Y, and Z values is taking a bit long for purposes (approx 2ms for all three at 400KHz I2C clock) given that we want to read from 4 of such sensors.

We tried playing with a teensy microcontroller and found increasing the I2C rate to 1MHz clock worked well. Trying to increase the I2C clock speed in the voxl 2 mini we find that px4 crashes after loading the mag driver.

I haven't been able to find anything online, but do you have information about the max i2c frequency for this device? We're repurposing the J19 MAG pins (bus 1) for this.

@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