@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 , voxl-esc-calibrate.py is a script that runs a test procedure in a single motor (with propeller mounted) to calibrate the behavior of the motor / propeller. This procedure only needs to be run once if you change motor or propeller type from a default configuration. The output of this script is just 3 coeficients a1, a2, a3 which you would need to manually enter into an ESC calibration xml file and then upload the xml paramer file to the ESC. Full details about the ESC calibration (when to do it and how) can be found here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md?ref_type=heads

If you are using standard motors and propellers (one of standard ModalAI drones), you do not need to run this calibration procedure.

It sounds like you got it working, I believe voxl-configre-mpa took care of it. You can see what voxl-configure-mpa typically does here : https://docs.modalai.com/voxl-configure-mpa/ , which includes running voxl-esc to upload the latest firmware and params for a specific vehicle.

@psafi , before calling voxl-gpio read, you need to enable the pin by setting it to input or output. Please check voxl-gpio -h. (hint: use voxl-gpio -m / voxl-gpio mode)

Alex

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.

@tonygurney , I am assuming that you are using the ESC hardware version M0134 (you can confirm using voxl-esc scan tool.

Here is the datasheet for M0134.
https://docs.modalai.com/modal-esc-datasheet/

This ESC has an option (via installing a 0 ohm resistor) to provide 3.3V to pin 1 of J3. This is the same voltage that is used for the MCUs that run on the ESC and should be used with caution (if this voltage rail is brought down by overloading, the ESC will shut down). Please see image below that shows where 0 ohm resistor should be (carefully) installed to enable 3.3V on pin1 of J3 (marked in red)

If you actually wanted 5V (VAUX), that is available on the other side of the board via two test points at the edge of the board. This voltage rail is provided by a separate switching regulator. See the following section : https://docs.modalai.com/modal-esc-datasheet/#neopixel-led-support

If you REALLY need 5V to be present on pin1 of J3, then you can add a small wire jumper from the VAUX test point directly to the pin1 of J3 (which is marked with a white dot). This pin 1 of J3 is normally disconnected. Please only do this if you are comfortable performing this type of soldering and we cannot guarantee the results :).

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.

@Moderator said in VOXL ESC Mini 4-in-1 Current per Motor:

Is it possible to step up voltage?

Can you please clarify the question?

Mini ESC is designed for small drones ( < 500g ). The ESC has been tested to handle 15A continous at 15V input continuously (60+ seconds), but with full direct air flow from propellers. This would simulate a full throttle "punch-out" on a small FPV drone (high current, but also lots of direct airflow = cooling). Do not use this ESC if the drone needs 10-15A per channel just to hover. Use it in application where hover current per motor is less than 5A (ideally 2-3A which is very typical) and absolute maximum continuous current per motor can be 10-15A.

For example, motors used for small FPV drones often are around 1306 size (3-4S Lipo). Those motors are usually rated for up to 10-12A continous (for 30-60 seconds). Larger motors can be used as long as maximum motor current does not exceed 10-15A (still 2-3A at hover) and there is sufficient cooling.

Always check ESC board temperature during initial flights / tuning. Temperature must stay below 110C at all times (critical), typically in the range of 40-70C for most applications. The ESC will most likely fail above 125C.

Temperature of the ESC board is the limiting factor because the board is so small. Mosfets can handle a lot of current as long as they don't overheat. So the design of the drone is very important (either use low current so that temperature is not an issue or properly design air flow from propellers and/or add heat spreader to keep the ESC board temperature in normal range for higher current draw applications).

ESC provides real time temperature feedback and it can be viewed in PX4 / QGC. Additionally, the PX4 logs contain the temperature information.

It looks like your machine does not have QEMU support or is missing ARM support on your host machine. Please try instructions here : https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/ (which also show you how to run ARM64 docker images on x86)

@Sarika-Sharma ,

Can you please take a look at output of dmesg -w, and paste here only the part that prints after you start the camera server. Use the flex cable that is able to detect all 4 cameras, but streaming does not work. You should try to view the stream in voxl-portal so that the camera is actually activated in this test. Also please post the output of voxl-camera-server.

Alex

@Piyush-Singh ,

The voxl-portal does not handle well streaming large images (including in multi-view, where the images are actually appearing small). The voxl-portal back-end uses software JPEG encoding, so one of your streams (hires_large) is 4208x3120, which takes LOT of cpu processing to encode to jpeg.

You can see that the voxl-portal process uses 260% cpu (2.6 full cores), which is a lot.

There is no practical need for streaming small and large uncompressed images to voxl-portal, so you can just enable small video stream, which is much smaller.

Also, if you select an individual camera stream, you can enable advanced camera controls (click on the small check box in lower left) and then you can adjust the JPEG encode quality from default 70 to something much lower in order to use less cpu. This setting will be applied to all cameras and you can go back to multi view after that. Note that the jpeg encode quality only affects voxl-portal view, not h264/h265 encoding.

Please try.

Alex

@jmltt , ok, thanks for the details. I will check if we have any of those assemblies in stock, or what the best course of action in your case.

Meanwhile, if you already have the shorter cable, are you able to use it for checking if the USB issues are resolved by switching the USB cable?

Alex

@Piyush-Singh

That’s good news. As for overheating, can you describe what tests you are running that use camera streams and what resolution?

@cbay , what happens with the third misp norm stream? Is it not available? Maybe you did not enable misp for that camera in voxl-camera-server.conf?

@jmltt , are you looking for an adapter like this? https://www.modalai.com/products/mcbl-00009 . If not, please attache a picture of what you need.

Definitely worth trying another adapter cable.

Alex

@cbay , M0188 does NOT support a Boson sensor, which has different power requirements (compared to tracking, hires cameras) and uses different pinout of the same micro coax port type.

M0195 supports 4 cameras + Boson https://docs.modalai.com/M0195/ , but the Boson takes ID2 (CCI2), meaning you would have to put AR0144 cameras on IDs 0,1,3,6 and IDs 1 and 6 would still have a CCI conflict (CCI1). So you would still need the alt slave address for one AR0144.

Boson can only be connected to J2 of M0195, as documented.

Let me check about the dual lepton. It is documented, but i just want to confirm that it works.

Alex

One last detail,

I will need to check for you whether the M0173 (ID1) and M0188 (ID1 , ID3) have the sync line connected to corresponding coax ports. Worst case scenario you may need to add a 0402 0 ohm resistor (or use unsync'ed AR0144 driver).

I will get back to you about that. If i dont get back to you before you test, you can just use the unsync'ed driver for the camera with alt slave (instead of combo/fsin, use just ..sensormodule.ar0144_0x20_x.bin -- both variants are present in the zip with drivers for alt address)

If you use a combo / fsync variant of the AR0144 driver (both set up the camera to expect a sync signal from the host), but the sync line is not coming through to the camera, you will not get any frames (this is how this particular camera does sync, as it starts the exposure).

Alex

@cbay , M0188 (with voxl2 mini) would allow you to use 4 tracking without changing the CCI slave address, you just use AR0144 instead of Hires Sensor ID3:

https://docs.modalai.com/M0188/

And, you could either use a hires camera in ID1 or another (5th) AR0144 with alt slave address.

By the way, Tracking Sensor ID8 on M0188 is untested and is not available.

Alex

@cbay , you need to flash the kernel for VOXL2 that supports M0173. It is part of the SDK install (there are only two options). Then the selection will persist.

Regarding running 4 Tracking cameras, it is only possible if you change the i2c slave address of one of the cameras (using a hardware modification to move the "slave ID selection" resistor on the AR0144 camera module. In addition to that, you will need updated camera driver (sensormodule) to use the alternate slave ID for the AR0144 camera.

This has been done in another thread:
https://forum.modalai.com/topic/4491/ar0144-rgb-output-on-voxl2

If you look at M0173 connectors (https://docs.modalai.com/M0173/) you can see which I2C (CCI) bus is used for which connector on M0173. There are only 4 unique CCI buses on VOXL2 and unfortunately with M0173, one of them (CCI3 is used for the TOF camera, which uses another connector). So that is why it is not possible to have 4 cameras with the same slave ID when using M0173 approach.

So here is the CCI bus usage for your use case (C27 + AR0144 instead of IMX412 in M0173 J4 (camera slot 1))

: M0173 J1: AR0144 slot 0 : CCI0
: M0173 J2: AR0144 slot 6 : CCI1
: M0173 J5: AR0144 slot 2 : CCI2
: M0173 J4: AR0144 slot 1 : CCI1 *** this is the camera / slot that uses conflicting CCI1 bus, so you need to change the camera's slave address to avoid conflict with AR0144 in slot 6.
: M0173 J3: Unused or TOF (slot 3) : CCI3 

(also this is helpful https://docs.modalai.com/voxl2-connectors/)

My suggestion: since you dont have a hires camera, you can connect all 4 cameras to M0173, basically C27 but instead of hires, you have another AR0144 (in slot 1). You will need the AR0144 driver for slot 1 with alt slave address from here : https://storage.googleapis.com/modalai_public/temp/ar0144/ar0144_drivers_alt_slave_addr_0x20_20250709.zip . And make the resistor change on one of the AR0144 cameras and plug it into slot 1 (J4 on M0173).

If you want to use a hires camera as well, then you can use exactly C27 and add another tracking camera to VOXL2 J8 using an adapter such as M0155 or M0181 (use J2 on M0181 for camera slot 5, since M0181 J1 is for boson only) , or similar.

You will find the following image as well as more details for changing the i2c slave id of AR0144 in the forum post mentioned above. Please do this at your own risk as it will void the warranty, since you would be performing hardware modifications to the camera module.

Alex