@dlee ,

Yes the new TOF sensor (IRS2975C) is more powerful that the previous generation. What I mean by that is that it can emit more IR power but also heats up more. Emitting more power allows the sensor detect objects at larger distances or objects that are not as reflective.

In current operating mode, the auto exposure control is enabled inside the sensor itself, which modulates the emitted IR power based on the returns that the sensor is getting. That is to say, the power draw will vary depending on what is in the view of the sensor. If there are obstacles nearby, the output power should be low, otherwise it can be high. At full power, the module can consume close to 0.8-0.9W

So the first solution, if design allows, is to add a heat spreader to dissipate the heat, which you already started experimenting with. The sensor has a large exposed copper pad in the back for heat sinking purposes for this exact reason. Just be careful not to short this pad to anything, use non-conducting (but heat transfering) adhesive pad between the sensor and heat spreader.

In terms of a software solution to the issue, we can query the temperature of the emitter. We can also control the maximum emitted power used by the auto exposure algorithm. That is to say, still leave the auto exposure running in the sensor, but limit the maximum power that it is allowed to use.

We are planning to add some software protection that limits the maximum output power as a function of the emitter temperature. This will require some implementation and testing.

Meanwhile, please consider using a heat spreader, which will be the best solution if you want to make use of the full sensor's operating range and not have our software limit the output power in order to prevent overheating.

Hello @Kashish-Garg-0

we have a curve that is "motor voltage vs rpm", meaning that for a desired RPM, it tells the ESC what average motor voltage should be applied. The average motor voltage is defined as battery_voltage * motor_pmw_duty_cycle. The battery voltage in this curve is in millivolts. Since you are typically controlling the desired RPM, as a user you do not need to worry about what "throttle" or voltage to apply - the ESC does this automatically in order to achieve the desired RPM. this calibration curve is used as a feed-forward term in the RPM controller. The ESC does support an "open loop" type of control where you specify the power from 0 to 100%, which is similar to a standard ESC, but PX4 does not use that ESC control mode.

By the way, you can test the ESC directly (not using PX4) using our voxl-esc tools (https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/tree/master/voxl-esc-tools) which works directly on VOXL2 or a standalone linux PC (or mac). voxl-esc-spin.py has a --power argument where you specify the power from 0 to 100, which translates directly to the average duty cycle applied to the motor.

Here is the calibration for the Starling V2 motor / propeller that we use:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/mavic_mini_2/mavic_mini_2.xml?ref_type=heads#L63

Also, you can take a look at this post to see how to interpret those parameters a0, a1, a2 : https://forum.modalai.com/topic/2522/esc-calibration/2

We also have some dyno tests for this motor / propeller : https://gitlab.com/voxl-public/flight-core-px4/dyno_data/-/blob/master/data/mavic_mini2_timing_test/mavic_mini2_modal_esc_pusher_7.4V_timing0.csv . We are not sure how accurate that is, but it can be used as a starting point. @James-Strawson can you please confirm that is the correct dyno data for the Starling V2 motors?

Alex

@reber34 , perhaps this approach can work for you:

• record a video encoded at high bit rate (using voxl-camera-server and voxl-record-video . Please note that the output of voxl-record-video will not be in a standard container (such as mp4, etc), but you can fix it with ffpeg : ffmpeg -r 30 -i voxl-record-video.h264 -codec copy videofile.mp4
• re-encode the video offline with desired codecs / bit rates / resolutions
• install gst-rtsp-launch which uses gstreamer to set up an RTSP stream https://github.com/sfalexrog/gst-rtsp-launch/
  • you will first need to figure out what gstreamer pipeline to use on voxl2 that will load your video and parse the h264/h265 frames (can use null sink for testing) and then use that pipeline with gst-rtsp-launch which will take the encoded frames and serve them over rtsp stream.
• gstreamer may be more flexible for tuning the encoding parameters of h264/h265 (compared to voxl-camera-server) and you can also use it in real time later (using voxl-streamer, which uses gstreamer under the hood)

Another alternative is to use voxl-record-raw-image to save raw YUVs coming from voxl-camera-server and then use voxl-replay and voxl-streamer - the latter will accept YUVs from the MPA pipe and encode them using the bit rate that you want. Note that depending on the image resolution, YUV images will take a lot more space than encoded video, but maybe that is also OK since VOXL2 has lots of storage.

Alex

@smilon ,

I believe you are correct! Thank you. We will double check this and fix.

@Gary-Holmgren , you are correct, the high resolution camera is not used for VIO, we typically use it just for video recording / streaming.

You can certainly add a new transform to the extrinsics file and use it in your application. You should use the same name for the camera in the extrinsics file as you name it in voxl-camera-server.conf just to be consistent.

Hello @Gicu-Panaghiu,

I am going to assume you are using VOXL1, since you did not specify..

We do have RAW8 and RAW10 support for OV7251. The selection of the format has to be done in several places.

First, you have to select the correct camera driver, specifically..

ls /usr/lib/libmmcamera_ov7251*.so
/usr/lib/libmmcamera_ov7251.so
/usr/lib/libmmcamera_ov7251_8bit.so
/usr/lib/libmmcamera_ov7251_hflip_8bit.so
/usr/lib/libmmcamera_ov7251_rot180_8bit.so
/usr/lib/libmmcamera_ov7251_vflip_8bit.so

there are 5 options and one of them is _8bit.so which means it will natively ouptput 8bit data (all others output 10 bit data).

the driver name, such as ov7251_8bit has to be the sensor name <SensorName>ov7251_8bit</SensorName> in /system/etc/camera/camera_config.xml.

You can check camera_config.xml for what sensor library is used for your OV7251.

When you run voxl-configure-cameras script, it will actually copy one of the default camera_config.xml that are set up for a particular use case, and I believe it will indeed select the 8bit one - this was done to save cpu cycles needed to convert 10bit to 8bit, since majority of the time only 8bit pixels are used.

Now, you mentioned that HAL_PIXEL_FORMAT_RAW10 is passed to the stream config and unfortunately this does not have any effect on what the driver outputs. If the low level driver (e.g. libmmcamera_ov7251_8bit.so) is set up to output RAW8, it will output RAW8 if you request either HAL_PIXEL_FORMAT_RAW8 or HAL_PIXEL_FORMAT_RAW10.

So if you update the camera_config.xml to the 10bit driver and just keep the HAL_PIXEL_FORMAT_RAW10 in the stream config (then sync and reboot), you should be getting a 10 bit RAW image from the camera. But since the camera server is currently expecting 8 bit image, if you just interpret the image as 8 bit, it will appear garbled, so you will need to handle the 10 bit image (decide what you want to do with it) in the camera server.

@KnightHawk06 , use voxl-calibrare-camera tracking_down_misp_grey <remaining options>

The ipk is available here now : http://voxl-packages.modalai.com/stable/voxl-hal3-tof-cam-ros_0.0.5.ipk - you should be able to use the launch file to choose between two modes (5=short range and 9=long range) and fps, which are listed in the launch file.

@Prabhav-Gupta , yes it seems like OpenCV and ROS YUV_NV12 formats do not match up. I will take a look at it.. it seems the ROS YUV is packed (interleaved) while standard for storing YUV NV12 is having two planes : plane 1 : Y (size: widthheight), plane 2 : UV (size: widthheight/2)

In the meantime.. you can stream a rtsp h264/h265 from VOXL (use decent quality so that image looks good) and use opencv to receive the stream and get decompressed images: https://stackoverflow.com/questions/40875846/capturing-rtsp-camera-using-opencv-python

Would that work for you ? (unfortunately with rtsp stream, you will not get the full image metadata, like exposure, gain, timestamp, etc).

RTSP streaming can be done using voxl-streamer, which can accept either a YUV (and encode it) or already encoded h264/5 stream from voxl-camera-server.

Alex

@cfirth , if you are streaming raw RGB images, then 6404803 is 921KB, at 30fps will be 27MB/s which is definitely more than you want to transfer over wifi for a single stream. You can measure the available bandwidth using iperf as i suggested in previous post. Consider using compressed image format in ROS or use h264/5 encoded streams. You can use voxl-streamer to encode the tracking frames into a streaming video. If you describe your use case in more detail, we can provide additional suggestions.

@Allister-Lim ,

If you are not monitoring the battery voltage while working with your battery-powered VOXL, it is possible that you are over-discharging the batteries to the point of failure. Especially with LiPo batteries, it is unsafe to over-discharge them, so please be careful. (It seems that you are also using LiPo batteries, in addition to ModalAI Li-Ion batteries also shown (green)). There is nothing wrong with using LiPo batteries, but you have to be more careful with those. Over-discharged batteries lose capacity and Lipo Batteries may become dangerous.

It is a good idea to use an appropriate DC power supply when working with VOXL2 while it is powered on continuously. 12V 3-5A Power supply, connected to the APM (which will provide 5V for VOXL) should be sufficient. You should have no problem finding one, but in case you need, here is a link to the AC adapter that we sell : https://www.modalai.com/collections/accessories/products/ps-xt60

Alex

@Rowan-Dempster ,

The SPI Read is a blocking call, so the DSP will spend time in that call while the data is being transferred, but it may be sleeping while waiting for the data to come into the SPI Hardware.

The UART Write is, actually, also a blocking call, so the DSP will write the data to the UART Hardware and sleep until the data is finished sending.

If you are measuring the times spent in those functions, it can add up. If you increase your UART baud rate, that time should go down. While the DSP is waiting inside those functions, it can process other threads.

The DSP utilization measurement is not very accurate, so it should not be trusted completely. How much utilization increase are you seeing from increasing the processing rate from 800Hz to 1000Hz ?

Maybe @Eric-Katzfey can comment as well - thanks!

Alex

@mkriesel , I would suggest doing a UART loop-back test of the ESC connector on your VOXL2 board. You would need to make a connector which connects UART TX and RX on VOXL2 side (ESC disconnected). We have a SW tool for doing a loopback test of DSP UARTs : qrb5165io-slpi-uart-test

Source code: https://gitlab.com/voxl-public/voxl-sdk/core-libs/libqrb5165-io/-/blob/master/apps/examples/qrb5165io-slpi-uart-test.c

You can test the ESC UART on J18 and also two additional UARTS (also mapped to the DSP) on J19. If the test fails only on J18 UART, then this may be some HW issue. If none of the UARTS on J18 and J19 pass the loopback test, then issue is probably in SW.

Please try and we can go from there.

Alex

Hi @isaac,

We only have two variants of the kernel for VOXL2. The default (original) kernel and one that supports M0173. (mach. var 1.0.0 and 1.0.1 respectively, which you can see in output of voxl-version).

If you are using M0135 camera interposer board, you would have to use the first kernel. However, this kernel is set up for a stereo setup in J8, so J8U is not available for regular cameras. If you are using J6 and J7 for cameras, then using M0135 in J8 to enable J8U, is not really possible, even with a kernel modification (due to some shared reset lines that will affect several cameras, if enabled). I would need to know exactly what cameras are connected where in order to provide more details.

Now, if you use the second kernel in combination with M0173, you can also use other adapters such as M0181, M0172. Enabling a hi-res camera in J8U has been discussed in the following thread, with images and instructions : https://forum.modalai.com/topic/4757/connecting-2-boson-cameras-and-2-mipi-cameras-4-cameras-total . Please note that you can use the smaller boards such as M0181 and M0172 instead of M0173 with the second kernel.

I would strongly suggest going the second route, but if you have an issue with this, let me know. I don't have the full understanding based on your brief question.

Alex

@mkriesel , we were able to get the 14 bit data from Boson after performing a firmware update on our old Hadron unit.

Enabling this will require updated voxl-camera-server, a new Boson sensormodule file as well as a change in the Boson configuration.

We were not able to use the FLIR GUI to switch Boson to 14bit MIPI, but using their python API, we were able to do it over USB (while connected to a linux PC).

While outputting 14 bit data, which is RAW output from the sensor, you cannot simultaneously get the post AGC 8 bit data, so you would need to do your own processing on the 14 bit data.

Our plan is to enable the RAW data publishing first along with perhaps a simple post-processed version of the data. The data will be published in uint16 format, so that you won't have to do the 14->16 bit unpacking.

Here are the Boson versions that worked / did not work to enable 14 bit MIPI data.

Hadron (640x512)
Before update: Software Version 3 0 26416 (not able to switch to 14 bit mode via gui/ python api)
After update: Software Version: 4 1 27660 (able to switch to 14 bit mode via python api and get data on voxl2)

Small Boson (320x256):
Software Version: 4 0 27141 (able to switch to 14 bit mode via python api and get data on voxl2)

Update is coming probably next week.

Regarding the 60Hz, actually we made some improvements in camera server a while ago and 60Hz is working now. You can just update your Boson FPS using the GUI and try it. You should update the FPS in voxl-camera-server.conf to 60 as well, so that if you are using the encoded output, the encoder knows what FPS to expect (remember, the camera server cannot actually change the FPS of the Boson).

Finally, we were previously using the ISP to process the Boson data, which made the image look a bit worse. Please make sure to use MISP when testing boson and disable the small / large encoded streams.

Here is a sample config:

{
			"type":	"boson",
			"name":	"boson640",
			"enabled":	true,
			"camera_id":	2,
			"fps":	30,
			"en_preview":	true,
			"en_raw_preview":	true,
			"en_misp":	true,
			"preview_width":	640,
			"preview_height":	512,
			"en_snapshot":	false,
			"ae_mode":	"off",
			"en_rotate":	false,			
			"misp_width":	640,
			"misp_height":	512,
			"misp_venc_enable":	true,
			"misp_venc_mode":	"h264",
			"misp_venc_br_ctrl":	"cqp",
			"misp_venc_Qfixed":	30,
			"misp_venc_Qmin":	15,
			"misp_venc_Qmax":	50,
			"misp_venc_nPframes":	29,
			"misp_venc_mbps":	2,
			"misp_venc_osd":	false
		}

In order to use MISP for boson, you need to have the camera server which includes the following commits: -- see here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commits/master?ref_type=heads

By the way, there is now also a Boson color stream (heat map) which is generated from the original 8 bit post AGC image. You can see an example in this forum thread : https://forum.modalai.com/topic/4757/connecting-2-boson-cameras-and-2-mipi-cameras-4-cameras-total (where there are two bosons, both running at 60fps, by the way)

Alex

@roy-crosthwaite , please submit an RMA form for a replacement : https://www.modalai.com/rma

Thank you

Alex

@monkescripts said in Be careful building voxl-cross on older SDKS (Other than V1.50.0):

RUN wget http://voxl-packages.modalai.com/dists/qrb5165/sdk-1.5/binary-arm64/voxl-opencv_4.5.5-3_arm64.deb

This line installs only the opencv package into the voxl-cross docker image, it does not install the SDK.

The mismatch you are referring to is related to to applications being built against one version of header files, while being deployed on a system that has a different version of the corresponding library. In this case, the library is libmodal-pipe, which has had a change affecting the structure of some data types.

Most likely, what happened was that you hand an older version of SDK and other libraries installed on the VOXL2, but when you built your application using voxl-cross, the step which installs the dependecies (./install_build_deps.sh qrb5165 <....>) pulled in a newer version of the libmodal-pipe library and headers. When the application was deployed to voxl2, at run-time, it linked to the old libmodal-pipe shared library, causing the mismatch.

There are many updates to libmodal-pipe and most of them do not cause any issues because there are added features, which do not break existing functionality. However, sometimes, a breaking change like this happens..

Alex

@Martin-Lukac ,

The diagram for this variant of the ESC is correct : https://docs.modalai.com/modal-esc-datasheet/#connector-information-and-pin-outs. This applies to M0049, M0117 and M0134 ESCs.

If you are using the M0129 mini ESC, it has a different connector : https://docs.modalai.com/voxl-mini-esc-datasheet/#connector-information-and-pin-outs

Regarding the baud rate.. Your ESC probably came already set up to use 2Mbit baud rate in the ESC params. You have to make sure that the PX4 uses the baud rate that the ESC params are set to, otherwise there will be a baud rate mismatch. It looks like everything is working as expected.

Alex

Here are the links to the test firmware:

M0129-3
M0129-6

After you update, you should see the following version after running voxl-esc-scan.py (except yours will be M0129-6). The firmware version will be 39.23 and this version will be reserved only for this test firmware:

INFO: ESC Information:
INFO: ---------------------
	ID         : 0
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555304003F0029
	Firmware   : version  39.23, hash 30c088dc
	Bootloader : version    184, hash 10bf24c8
...

In case you need help updating ESC firmware: https://docs.modalai.com/voxl-escs/faq/#q-how-do-i-update-esc-firmware

We won't officially release this firmware version in order to avoid the aforementioned risk of turning on 5.0V by just installing a firmware update, however we will work on enabling this in the ESC params.

Also, just as a reminder, please be careful soldering to the AUX test points, use high quality flexible cables, and use strain relief to avoid lifting the pads.

Alex

@Martin-Lukac ,

Thanks for the feedback. We can work on adding a param. Meanwhile, for your testing, I will send firmware (based off the latest version), which will just set the VAUX to 5.0V all the time.

Alex