@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

Hello Rolando,

It will not be possible to fully use four ov7251 cameras at the same time due to i2c address conflict. the downward camera can coexist with the stereo pair because

• one of the stereo cameras is actually on a different i2c bus
• ov7251 camera has two i2c addresses, so with some software configuration it works. However, having 3 ov7251 cameras on i2c bus cannot be done without a conflict.

In a condition of i2c conflict between cameras, what will happen is..

• system will be able to detect each camera at boot time because probing happens while other cameras are powered off
• you should be able to fully use the conflicting cameras one at a time (not concurrently)
• if you use the conflicting cameras concurrently, commands sent to one camera will go out to both cameras, for example exposure and gain control. nothing will physically break, but this is currently not a supported use case.
• there will also be a short glitch after you started the first conflicting camera and when you are starting the second conflicting camera, since the first one will also get re-initialized with the commands intended for the second camera

in your case, the ov7251 plugged into J2 was not detected because the camera configuration xml file is not configured to query this camera on J2 connector. If you wanted to enable it, you need to back up and edit the following file : /system/etc/camera/camera_config.xml and add an entry that looks like below (then reboot). The slave address 0xC0 is one of the two possible slave addresses for this camera. The other one is 0xE0 and is already used by the camera plugged into J4 (downward facing).

So are you using one of the stereo cameras + stereo flex + extension cable? if you are using the stereo flex with one camera, make sure to use the left port on the flex because the right port is connected to the secondary i2c bus, accessible only in stereo configuration. Also, multiple stereo pairs are not supported on VOXL and stereo can only be used in J3.

With the below config addition, you should be able to detect all 4 ov7251 cameras and successfully use the following configurations without confilicts:

• J2 + J4 (hires slot + tracking slot)
• J3 + J4 (stereo slot + tracking slot)
• if you want to use J2 + J3 (hires + tracking slot), change the I2C id to 0xE0, but then it's the same thing as current stereo + tracking.

Now, in this configuration you should also be able to run all 4 cameras together but depending on the i2c ID of the camera in slot 0, it will conflict either with left stereo or tracking camera. I would not mess with stereo, so you could set i2c id of slot 0 to the same as in slot 2 (hires and tracking). then there is is still an issue of exposure/gain controls between the two cameras fighting with each other (both cameras will receive both exposure/gain updates).

In order to prevent two cameras from fighting exposure/gain settings the only way to do it is to prevent one of the camera drivers from sending out exposure/gain updates at all. Then both cameras will have the same exposure/gain computed based on one camera's image. This would require a little bit of work on the camera driver side but it's possible (though not supported now).

Anyway, this is just a long explanation of what you could try and what you will see.

<!-- ov7251 tracking camera in camera slot 0 -->
  <CameraModuleConfig>
    <CameraId>0</CameraId>
    <SensorName>ov7251</SensorName>
    <SensorSlaveAddress>0xC0</SensorSlaveAddress>
    <ChromatixName>ov7251_chromatix</ChromatixName>
    <ModesSupported>1</ModesSupported>
    <Position>FRONT</Position>
    <MountAngle>360</MountAngle>
    <CSIInfo>
      <CSIDCore>0</CSIDCore>
      <LaneMask>0x1F</LaneMask>
      <LaneAssign>0x4320</LaneAssign>
      <ComboMode>0</ComboMode>
    </CSIInfo>
    <LensInfo>
      <FocalLength>4.73</FocalLength>
      <FNumber>2.2</FNumber>
      <TotalFocusDistance>1.9</TotalFocusDistance>
      <HorizontalViewAngle>64.1</HorizontalViewAngle>
      <VerticalViewAngle>51.6</VerticalViewAngle>
      <MinFocusDistance>0.1</MinFocusDistance>
    </LensInfo>
  </CameraModuleConfig>

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.

Hello @david-moro ,

mvVISLAM library supports a mask file in the following format : 8 bits per pixel PGM with white (255) being where NO features should be found and black (0) where it is OK to have features. For a frame of aspect ratio 4:3, typically a mask of size 160x120 pixels should be used, although you can have a higher resolution mask if you want to. The mask will be resized to the actual image size or the smaller resolution mask will be properly queried (i do not know which one, but it should not matter). I would just suggest keeping the aspect ratio of the mask the same as the actual image.

You can test this easily by creating a mask that splits the image in half and seeing if features get detected in masked out region. Please note that the mask only affects detection of new features -- if the feature was detected in unmasked region and then the feature ends up in the masked region, it will still be tracked.

It does not look like a mask file is an option in voxl-qvio-server at the moment. You could try to add it yourself, here is an example how it was used in another project : https://github.com/ATLFlight/snap_vio/blob/master/src/snap_vio.cpp#L345C19-L345C19 . If mvVISLAM is not able to open the mask file you provided (wrong path, etc), it should output an error message like this : AR ERROR: arFileOpen(): Failed to open file: <path to mask file name>

I hope this helps!

Alex

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.

@Samuel-Lehman , currently VOXL2 (M0154 variant, but not M0054 or VOXL2 mini M0104) has hardware support for display port output, the software is not available (no ETA at this point). VOXL2 is not intended to be used as a desktop computer, although it could be :).

However, if you just want to stream video without wifi / ethernet, you can actually use a cool trick : ADB port forwarding:

• plug in USBC cable from your VOXL2 in to linux pc
• run the following command to create a forwarding tunnel between voxl port 80 to port 8080 of your linux machine :

adb forward tcp:8080 tcp:80

If you have voxl-camera-server and voxl-portal already running, you should be able to view the camera streams in the browser at http://localhost:8080/video.html?cam=hires_color or something like that (depending on your camera name). I just tested it and it works well. You can use voxl-portal as you normally would, when using an network connection.

A few notes

• please make sure to use SDK 1.3.4 or later or at least voxl-portal because we recently added a fix for voxl-portal to work with port forwarding : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-portal/-/network/master?ref_type=heads
• voxl-portal can also display h264 video, but it needs a fix that i am working on and is almost done.

If this approach would work for you, you can test the non-encoded streams and we'll get the fix for h264 into voxl-portal soon.

Alex

@david-moro

If you look at this image, https://docs.modalai.com/M0169/#image-of-working-module it shows the TOF sensor (right) and the M0169 adapter (left).

The weight of the TOF module is 0.72g and weight of M0169 adapter is 0.93g.

This particular combo requires an external power input (4-5V as described here https://docs.modalai.com/M0169/#current-consumption). "External" in this case means additional power source besides the camera connector. The additional power input connects into M0169 via 2-pin JST connector.

The worse case power consumption is ~0.9W, which is a lot for such small module. The current draw plot shows a typical 5hz operation at maximum "exposure", which sends out 8 6-ms pulses of 1.0-1.1A (at 3.3V). so that is 1.1A * 3.3V * (5hz * 8 * 0.006s) = 0.87W. If you select 15Hz, the maximum exposure (emitter pulse time) will go down from 6ms to 2ms, so the maximum total power will remain the same.

This module would definitely require a heat spreader to operate continuously at this power. However maximum power output (even in auto exposure mode) can be limited to accommodate specific power dissipation capabilities. Additionally, the temperature of the emitter is reported from the TOF sensor.

Due to additional complexities that come with this new module (need for external power, which cannot be obtained from the camera connector) and heat management, we are working on the solution that would provide a positive user experience, so hence the delay.

I will check on the ETA

Hi

If you are looking for more low level functionality and a bit easier to experiment with, you may want to check out https://gitlab.com/voxl-public/utilities/voxl-rtsp/-/tree/dev . This tool is good for testing or running simple scenarios. This tool accepts some commands (like exposure control) via command line, so you could add a simple feature to save an image upon a command line input. Please see README to see how the exposure control input works and code for how it's implemented.

Please make sure that voxl-camera-server is disabled when you run voxl-rtsp.

If you still would like to go through the voxl-camera-server approach, we may need some more input from respective devs :).

I hope this helps..

Alex

BTW, you should be able to use M0076 single camera interposer or M0135 dual image interposer to access the I2C-0 pins if you need to:

https://docs.modalai.com/m0076/#2d-diagrams

• TP 5 and 6 are GPIO 4 and 5

https://docs.modalai.com/m0135/

• TP1 and TP2 are GPIO 4 and 5
  
  

@jcai , good news. I checked the kernel Device Tree for VOXL2 Mini (M0104) and I believe that J7 has /dev/i2c-0 , which is using GPIO 4 and 5. The /dev/i2c-0 is present on on the file system.

I have not tested the i2c port just now, but you should give it a go! Just watch the digital IO voltage levels, they are 1.8V coming off from the voxl2 / mini camera connectors. Not buffered, but ESD protected.

I think we need to update the docs to reflect that this is /dev/i2c-0 and not /dev/i2c-4.

https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/dts/m0104/m0104-modalai-qupv3.dtsi#L11

https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/dts/common/m0xxx-kona-pinctrl.dtsi?ref_type=heads#L3117

Alex

@griffin , please see the following post with the same symptom and fix : https://forum.modalai.com/topic/4171/frame-size-mismatch-got-43200-bytes-from-pipe-expected-38528

We will test this and merge to dev soon, meanwhile if you can re-build the camera server, you could test it.

Alex

@tkddnjs825 depending on which cameras are connected to your M0173, you can select the closest configuration using voxl-configure-cameras and select option 26, 27, or 28. Then you can manually edit /etc/modalai/voxl-camera-server.conf to disable the camera(s) that you don't have installed (you can just remove those camera config entries completely from the file to avoid confusion)

https://docs.modalai.com/voxl2-coax-camera-bundles/

Please let me know if you need any further clarification.

Alex

@jcai , Here is a draft of instructions for using the Hadron adapter (M0159 + M0181) for beta testing. I will put these up on our docs page but just wanted to provide these to you so you can test the hardware. Please let me know if you have any questions.

WARNING:

• even though the coax cables are the same for both connections, the order cannot be swapped
• HR connector has to conect to HR and 5L to 5L
• M0159 J2 -> M0181 J1
• M0159 J3 -> M0181 J2
• shipped assemblies have been correctly connected and tested

Software Setup

• use voxl2 mini (VOXL2 also supported)
• install sdk 1.4.0 (tested) or later
• change apt source to dev : /etc/apt/sources.list.d/modalai.list
  • deb [trusted=yes] http://voxl-packages.modalai.com/ ./dists/qrb5165/dev/binary-arm64/

apt update
apt install libmodal-pipe voxl-portal voxl-camera-server

Confirm sensormodule drivers exist

• in chi-cdk directory where all the camera drivers are kept (but not used)

ls /usr/share/modalai/chi-cdk/ov64b40 : com.qti.sensormodule.ov64b40_0.bin ... 5.bin
ls /usr/share/modalai/chi-cdk/boson:    com.qti.sensormodule.boson_0.bin ... 5.bin

Confirm these exist (also part of camera sernsor drivers):

/usr/lib/camera/com.qti.sensor.ov64b40.so
/usr/lib/camera/com.qti.sensor.boson.so

Connect M0181 to Voxl2 Mini J7

• make sure pin alignment on connectors is correct. the mounting holes should align and the tab of M0181 will hover above the main SoC
• see attached image
• the tab can be removed from M0181 if not needed

Copy correct sensormodule drivers

cp /usr/share/modalai/chi-cdk/boson/com.qti.sensormodule.boson_2.bin /usr/lib/camera/
cp /usr/share/modalai/chi-cdk/ov64b40/com.qti.sensormodule.ov64b40_3.bin /usr/lib/camera/

Configure CCI Mux on M0159 via GPIO

• Use gpio 6 on J7 of VOXL2 Mini to configure the i2c mux to connect J7U cci to Hadron's cam cci
• this needs to be done each time after reboot, before running camera server

voxl-gpio -m 6 out && voxl-gpio -w 6 1

Detect cameras

voxl-camera-server -l
(should detect both cameras)

Supported resolutions / modes

• OV64B currently supports the following modes
• these are the RAW modes that camera can be configured to (by the camera pipeline)
  • the camera pipeline picks the best mode based on the requested resolution and fps
  • note that if you request 3840x2160 30FPS, the camera pipeline actually selects 4624x3472 because it matches the desired FPS (30)
  • actual selected mode can be checked using logcat | grep -i selected before starting camera server, the selected resolution will be printed for each camera.

# (Mbps per csi lane)
Mode0_9248x6944_10fps_2500.8Mbps
Mode1_4624x3472_30fps_PD_1136x860_1502Mbps
Mode4_3840x2160_60fps_2500.8Mbps
Mode5_1920x1080_240fps_2500.8Mbps
Mode6_1920x1080_30fps_800Mbps

Max resolution (works! about 9fps)

		"preview_width":	9248,
		"preview_height":	6944,

• Note that at this >8K resolution, the Qualcomm ISP runs in dual VFE mode, which means you cannot use any other non-RAW camera that uses the ISP.
• MISP approach does not use Qualcomm ISP and will support more cameras (documentation coming soon)

Minimum config

• paste into /etc/modalai/voxl-camera-server.conf:

{
	"version":	0.1,
	"fsync_en":	false,
	"fsync_gpio":	109,
	"cameras":	[
		{
			"type":	"boson",
			"name":	"boson",
			"enabled":	true,
			"camera_id":	0,
			"fps":	30,
			"en_preview":	true,
			"en_misp":	false,
			"preview_width":	640,
			"preview_height":	512,
			"en_raw_preview":	true,
			"en_small_video":	false,
			"en_large_video":	false,
			"ae_mode":	"off"
		},
		{
			"type":				"ov64b",
			"name":				"hires",
			"enabled":			true,
			"camera_id":		1,
			"fps":				30,
			"en_preview":		true,
			"en_misp":			false,
			"preview_width":	1920,
			"preview_height":	1080,
			"en_raw_preview":	false,
			"en_small_video":	false,
			"en_large_video":	false,
			"en_snapshot":	false,
			"ae_mode":	"isp",
			"gain_min":	54,
			"gain_max":	32000
		}
		]
}

Start Camera Server

• run voxl-camera-server in foreground to make sure everything is going right and you can view streams using voxl-portal
• note that very high resolution streams viewed as YUVs (which are transferred as MJPG by voxl-portal) will take a lot of CPU to encode to MJPG and also a lot of bandwidth to stream.

Image of M0181 Plugged into VOXL2 Mini J7

@jcai , can you please let me know where you see i2c0 on J7 of voxl2 mini? Please keep in mind that CCI_I2C ports are reserved for camera use.

Regarding accessing QUP0 on J19 from application processor, it not currently supported. It would require a bridge application to communicate the the DSP's I2C port. It's on our todo list to look at enabling this, but there is no timeline at this moment. The best bet right now would be writing a custom PX4 driver that will run on the DSP and talk to the device and then somehow pass that information to the application processor. There are a number of examples of i2c device drivers, such as barometer, compass drivers that are running on DSP.

Alex

@smilon , Can you please clarify what this is a picture of? I don't recognize it from this angle.

Alex

@jameskuesel ,

Can you please provide a bit more detail about your test -- when you enable M0161, how exactly do you test it? Do you view the images using voxl-portal? and if so, how is your starling2 connected to the network? If you are using the wifi dongle, then we have noticed that moving the wifi dongle away from the GPS antenna helps reduce interference. You can test if the interference is still present by unplugging the wifi dongle completely from usb port and use voxl-inspect-cam test application to make sure the camera is running (inspect the same camera stream that you were previously viewing).

Also, please let me know what resolution / FPS you are testing the camera at.

Regarding the MIPI clock rates, i would need to double check, but i believe the IMX412 driver uses 1.5Gbps MIPI bit rate, which is close to GPS L1, but not really close that it would cause interference. We can definitely try different bit rates to see if it helps reduce EMI (if that is indeed the case), but let's first rule out the potential wifi dongle issue. We have ability to change the MIPI clock rate in quite a wide range, but this will require a different sensormodule driver for the camera, which I would need to provide to you.

Another thing, we recently found that the Starling Front End M0173 board may cause GPS interference via the Lepton connection, so if you have that plugged in, please unplug and see if that helps with GPS signal. Lepton needs 25Mhz clock, so one of the harmonics could hit exactly GPS L1 at 1575Mhz.

Alex

@ashwin , from software point of view, running multiple TOF V2 sensors on VOXL2 is not an issue, but as Vinny said, the power requirements would put a limit of a single TOF sensor per VOXL camera connector (J6, J7, J8), so that would mean at most 3 TOF sensors connected to J6L, J7L and J8L (camera slots 0, 2, 4 in order to avoid i2c slave address conflicts -- this is more of a note to self ).

However, assuming the SW can support these 3 TOF sensors, i am not sure we actually have the required interposers / flex cables to connect 3 TOF V2 sensors to the 3 camera ports. @Vinny , what do you think?

Also, @ashwin , would you need any other cameras connected to VOXL2 besides the multiple TOF sensors?

Alex

and also a simple example here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-tof.c?ref_type=heads