@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

@vjuliani , the tracking camera ( i assume ov7251 or AR0144) is monochrome, so you can not make the image colored. You can install the latest version of the voxl-streamer from dev (nightly builds) http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/ and it should allow you to encode h265.

Alex

@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.

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)

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.

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

@TomP , oh yeah, my bad.. you found the right one

@tom , what would be the right course of action here? Thanks!

Hello @Dronodev ,

The other side of the M0166 PCB has a picture of a tiny figure which shows the nominal "up" orientation. You will see the little guy in the image below (coax cables are going up):

So if you flip the camera around to point away from you, then reference frame will be (right-handed):

• X : right
• Y : down
• Z : out of the camera lens

So your first diagram (on the left) is correct.

Here is specifically what en_rotate flag in voxl-camera-server.conf does for AR0144 camera:

• it sets the camera configuration / register such that the image is read out backwards (rotated 180 degrees) from camera to VOXL2
• no rotation is done in software (voxl-camera-server)

If you enable the rotation this way, you will need to either re-do the camera calibration or rotate your intrinsics manually, which I guess is trivial.

In terms of extrinsics (in /etc/modalai/extrinsics.conf file), you will need to update the camera rotation by 180 degrees along the Z-axis, if en_rotate flag is used (assuming you had it already configured for the non-rotated configuration).

Alex

@Richa , you should find information you need in the links below:

• https://docs.modalai.com/M0186/#module-connector-pinout-for-j1-s-h26-hr-ds-412
• https://docs.modalai.com/micro-coax-user-guide/

Alex

Hello @awagner ,

I am sorry this happened to you. A few questions / comments:

It seems your motor is too large for this mini ESC

• https://docs.modalai.com/voxl-mini-esc-datasheet/

  • "This Mini ESC is designed for aerial vehicles under 750g (under 500g for FPV racing applications). For larger slow flying vehicles up to 1500g, please use the VOXL 4-in-1 ESC. For FPV racers exceeding 500g, please use VOXL 4-in-1 FPV ESC."

• the kp value is very aggressive (typically i would recommend starting at 0 kp and ki (proportional and integral gains) and ramp those up to increase responsiveness.

• the spin-up type should be set to 1 (sinusoidal), since it is much more reliable. Which parameters did you start with when you calibrated your ESC? i suspect that improper spin-up caused the ESC to get out of sync and fail due to excessive current.

I know it can be difficult to get started with using new hardware. Aside from the need for updated esc parameters, the issue here is that the mini ESC is not suitable for your motors / propellers. I strongly recommend upgrading to our FPV ESC , which is build to handle a lot of power and stress:

• https://www.modalai.com/products/m0138
• https://docs.modalai.com/voxl-fpv-esc-datasheet/

Once you get the FPV ESC, I can help with the tuning (let me know, i can provide updated params before you test gain).

Please submit an RMA request, https://www.modalai.com/pages/rma . I would recommend at least a discount on the new ESC. We will try to improve documentation to avoid this in the future.

Alex

Hello @taiwohazeez ,

Thank you for sending updated images.

Just for sanity checking, please double check that the other tracking camera on your drone is in focus and does not have this issue.. (i assume that is true).

To me, it definitely looks likes either

• damaged or dirty lens on the external lens surface
• damaged or dirty lens on the internal lens surface (the back surface of the lens)
• dirty surface of the camera sensor itself (inside the camera module)

If you are comfortable with unscrewing the lens completely and wiping it (front and back) with a new microfiber cloth (preferably long strand) and screw it back again to check if there is any improvement. Also, once you remove the lens, you can take a look at the sensor itself, any dirt or smudges should be very easy to detect because the surface of the camera sensor is very reflective and should be perfectly clean. I can't recommend cleaning the sensor itself on your own, since that would involve inserting something inside the camera module, which could lead to damage. Please dont keep the lens out of the lens holder for a long time (hours) as dust or dirt may get inside on the surface of the sensor (do not perform this procedure in a dusty environment).

Please reach out to https://www.modalai.com/pages/rma if you need further help to get this fixed / replaced.

Alex

@l05 , when in doubt, you can add a print statement in your app as a sanity check to make sure you are running the correct version of the application. Then check your print statement at run time.

If you are modifying an existing app in voxl-mpa-tools, you just need to use the voxl-cross docker image to

• build the source code
• build the package (deb)
• deploy the package (either manually pushing and dpkg -i <package.deb> on target) or using a convenience script deploy_to_voxl.sh which is typically present in most voxl projects -- this script will push the deb to voxl2 and install the deb.
• run your new application on voxl and confirm functionality

If you are adding a new app to voxl-mpa-tools project, you will need to modify the CMakeLists.txt file in the tools folder, it should be self explanatory how to add a simple app. Once you build and deploy, your new app will be installed into /usr/bin on voxl2.

If you have any other questions, let me know.

Alex

Hello @shalini-kumari ,

The M0186 camera uses the Sony IMX664 sensor. You can find high level information for the M0186 module here https://docs.modalai.com/M0186/ (as well as a link to the basic documentation from Sony).

The camera sensor itself (within M0186 module) requires three primary voltages, 3.3V, 1.8V and 1.1V. The maximum power consumption is 0.6-0.7W (theoretical), although we have not explicitly measured it.This is for a worst case, full frame resolution 120FPS. VOXL2 and the M0186 module provide the appropriate voltages for the IMX664 sensor to function properly.

Note that the power consumption of the whole system will not only depend on the camera resolution, fps, it will also depend on what you are doing with the images in VOXL2 (since VOXL2 will also consume power processing the images).

Hopefully this helps.

Alex

Hi @Aaky ,

I looked at the log using our customized version of flight-review (https://github.com/modalai/px4-flight-review), which you can run locally on your linux machine (the custom version of flight-review provides additional plots related to ESC and some other fields).

The RPM tracking looks good - tight tracking and not a lot of noise in commands (meaning IMU is well isolated, there are no significant vibrations or esc-induced oscillations).

ESC temps are ok (although this is a pretty short test!)

Power

The total battery current seems to be around 35A, meaning 8-9A per motor, which is still a very comfortable load for this ESC, as long as you can keep the ESC temperature not exceeding 100C (it should still run OK at 125C and higher, but that's definitely not recommended, and if you have to do that for short bursts, it may be ok). Unless you are trying to push the performance to the limit somehow, stay below 90-100C for the ESC temps. You can also significantly help with ESC cooling by adding a heat spreader to significantly increase the thermal mass of the ESC (which is very low, since the board is so tiny). Adding a heat spreader will make the cooling more efficient.

You should double check your PX4 params for min and max rpm to match what you have in the ESC params, since at the end it seems that PX4 is sending a low RPM that is not achievable by the ESC:

Since we are talking about ESC temps, you can actually set up a parameter to send a warning or critical message (which you should see in QGC) for different ESC temperature thresholds : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/actuators/voxl_esc/voxl_esc_params.c#L249. Just for full disclosure, we don't test this PX4 feature frequently, but my understanding is that if you hit the warning threshold, QGC should show a warning and CRITICAL limit may actually cause a behavior change in PX4, I am not sure. The ESC driver in PX4 just sends out a warning message, but how it is handled is up to PX4.

Honestly I don't really see any issues with this setup, even though it is heavier than I would recommend for this ESC. I would suggest that you slowly build up confidence in this setup and start flying a bit more aggressively and checking the log for the metrics i mentioned in this post and checking ESC temps.

Alex

Hello, @HsinSWT ,

I am assuming your are using a 12V AC/DC adapter, which is higher voltage than the 2S battery used with Starling 2. Using 12V bench testing is OK, so that should not be an issue.

The ESC should already have the correct parameters loaded for the Starling 2 Motors and the correct battery voltage (2S). Inability to start at the nominal voltage, but success when using 12V is likely a symptom of a motor damage. Even though the ESC does have voltage compensation, it is limited (on purpose, for safety) and if you apply higher voltage, like 12V instead of 7-8V, the ESC will actually output higher power during the spin-up phase.

Also please make sure you are using the latest ESC firmware, there are a lot of tips here : https://docs.modalai.com/voxl-escs/faq/

Once you start using voxl-esc tools, you can also spin one motor at a time (or all 4 at a time) and get real-time RPM feedback. You could use your 12V supply and spin the motors at 10% power and see what RPMs they actually spin at. A faulty motor would spin slower. Please be careful while testing, since the drone could fly up if you send a wrong command, you could also test without propellers, the motor issue should be observable in unloaded motor RPMs as well.

Another typical issue with motors not spinning up is damage of motor windings due to mounting screws going into the windings (which could happen if the landing gear is removed, but the same screws are used to attach the motors). I am not saying this is the case here, but worth inspecting the motor windings on the under side, right where the motor mounting screws could make contact with the windings if the screws were too long.

If you do have a milli-ohm meter accessible to you, you could actually measure the motor winding resistance (while the drone is powered off, but motors can remain soldered to the ESC). You can compare the milli-ohm readings from working motors vs non-working (check all phases pair-wise).

The rust on the inductor is only cosmetic. We are aware of this "issue", but it's really not an issue (rust on a iron case of an inductor - the case does not really affect the inductor itself).

Hopefully this helps!

Alex

@colombe-ai , when you flash a voxl2 SDK, there should be an option to set it up from scratch. did you try it?

https://docs.modalai.com/voxl-suite/

Alex