@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

@taiwohazeez , when you run the camera calibrator, are you providing the correct size of the checkerboard? it looks like you are using 8x6 in the image above (number of inner corners).

Alex

@taiwohazeez ,

Can you please confirm that you only inspected several pipes using the command:

voxl-inspect-cam tracking_down tracking_front tracking_rear tof_ir hires_small_color

Also please use voxl-inspect-cpu to check if the cpu is overheating during your testing.

Additionally, are you able to provide output of voxl-camera-server (running in the foreground) when the pipes start disappearing?

If you are able to update to the latest SDK (1.6.x) , it may be easier for us to support, as 1.4.5 is 7 months old.

Alex

@Peter-Lingås-0 ,

We did have a sample batch of color AR0144 global shutter cameras, but i think we probably run out of those. I can double check. Due to low demand, we are not actively supporting them.

For general object detection applications, i would recommend IMX412 camera (M0161 part number, for example). This camera is 4056x3040 resolution, but it also supports 2x2 binned mode. The advantage of using binned mode (for this context), is reducing the rolling shutter effect.

The amount of rolling shutter distortion / skew is a function of the readout time (time between the start of exposure of first line and last line). This time depends on the camera and specific operating mode.

However, the IMX412 camera in combination with VOXL2 supports a 2x2 binned mode where you get a 1920x1080 image with only about 4.2ms of rolling shutter skew, meaning there is only 4.2ms between the first and last line. You can see more details on the readout time for different modes here : https://docs.modalai.com/camera-video/low-latency-video-streaming/#camera-pipeline-latency-in-different-operating-modes

Additionally, the IMX412 camera module has M12 lens mount, which allows for more flexibility in lens choice as well as supporting generally large lenses, which will improve image quality as well.

Would this be an option for you or is having a global shutter camera a requirement?

Alex

@awagner ,

I think the main issue that started the failure mode was the spin-up type was set to 0 in params, which I do see that you got from the seeker_v1 xml file you mentioned. It is not your fault. The non-sinusoidal spinup is not as reliable and it is mostly not used any more. I will look at removing the old param files that use that option.

Let me explain the reasoning behind using a larger ESC, especially during initial testing:

• the larger (FPV) ESC can handle much larger currents and dissipate a lot more heat, so it can handle much larger glitches, which could arise from mis-configuration during initial testing
• the ESC firmware does have some timeouts for protection, which generally do prevent fatal issues like this, but if the glitch results in enough current to quickly burn out a mosfet, the ESC cannot recover. The larger ESC (with larger mosfets and larger thermal mass will take longer to burn out, so the ESC's timeout / glitch detector should save it)
• larger motors in general have larger stall current, which would result in large current if there is some glitch during start-up.
• based on the numbers that you provided for the motor spec calculator (3.75A hover / 17A max), it should be possible to tune the mini ESC to work, however there are still some things to consider:
  • may need to add more bypass capacitance to handle larger current transients
  • if the motor is stalled (due to impact, etc), there is still a bit higher risk of ESC burning out due to stall detection being a bit too late.

As for the xml to use as a starting point.. You can start with this one:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/D0020/m0138_3110_900kv_gemfan_10x4.5_tri.xml

This is tuned for a 6S application 3110-size 900kV motor with a 10x4.5 tri-blade motor (pretty powerful configuration). You will need to update:

• voltage (6s to 4s)
• motor params (kv, rpm curve, etc)
• you can set the timing advance and sense advance from 20 to 0 (your application is likely not aggressive enough to require tweaking that), although you can do some bench testing to determine if you encounter de-syncs during large rpm transitions : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/low_kv_motor_tuning.md
• you may need to adjust the spinup power / latch power -- generally keep it between 70-100 (7-10%) but when i tune this, i also usually find the minimum spin-up power that is able to reliably spin up the motor and then add a 10% extra (so 70->80). You can set spin-up power to a higher value in sinusoidal spin-up mode and it will produce a lot more torque, but will also consume more current. I usually try to limit a per motor spin-up current to 1-2 amps as a rule of thumb. for a fixed prop (not folding), your spin-up time can be anywhere between 500-1000ms, you can experiment. If you see the motor skipping during spinup and re-starting, you can increase either spin-up time or spinup power.
• may want to re-enable start-up beeps (disabled in this config)
• you can set kp (proportional gain) to 50 first (softer), then bump up to 100 or so, as you build confidence. higher kp will result in snappier response (faster than traditional ESCs without rpm control) but will also draw more current during transitions.

(with M0138, you should not need to add more bulk capacitance to ESC power).

With correctly tuned sinusoidal spin-up procedure, it should work pretty much 100% of the time (spin up on the first try every time). If you are seeing some inconsistent spin-up behavior, then it is possible there is some parameter issue and it needs to be investigated.

When you get your M0138, i suggest updating the params per my notes above and doing some bench testing using voxl-esc tools where you just spin up and stop motors many times in a row and make sure the spin-up is reliable.

Please let me know if you have any other questions!

Alex

@Sarika-Sharma ,

The preview width and height parameters are always in the camera config file, so if you added them, they are duplicates (and will be ignored).

Please read through this thread as it has pretty detailed explanation how to configure the correct tof sensor (old or new) for a custom configuration.

Camera-server-config-helper is indeed helpful. If you use it correctly, you should not have to manually modify the resolution in the config file.

If you still cannot get this to work, please let me know what cameras you have plugged in (and which camera ports) on your voxl 2 mini.

Alex

The part number for the coax mating connector is the following : DF56C-26S-0.3V(51).

Hello @Richa,

The documentation states the following: (https://docs.modalai.com/micro-coax-user-guide/)

• ModalAI uses Hirose DF56 series micro coaxial connectors for our adapters and cables

The part number for the coax mating connector is the following : DF56C-26S-0.3V(51).

If you are designing a carrier board for VOXL2, you could request some help from our engineers to help review the design before you send it for manufacturing.

I hope that helps.

Alex

Hello @HsinSWT ,

When i see results like this, i would say there is probably 90% chance that the motor is bad. Unfortunately, there is a chance that the ESC is bad as well, and there is no good way to check the ESC without a known good motor (however the ESC failure is unlikely).

As I mentioned in the previous post, if you had a milli-ohm meter, you could test the motor winding resistance to confirm whether the motor is good or bad. A tool like that measures resistance with high precision (similar to a regular Ohm meter). However, if you don't have one, it may not be worth buying it..

You will not be able to measure the winding resistance of these motors correctly with a regular Ohm meter. However, you will be able to detect a complete open circuit (which could be the case, maybe worth trying). If testing resistance using a regular Ohm meter, any two connections between the 3 motor phases will read 0 ohm (or close to that). If a wire is broken, then you can detect it.

The Starling 2 motor (3000kV) has around 0.360 - 0.370 Ohm phase-to-phase winding resistance.

In order to confirm that the ESC is working properly, you could temporarily connect one of the working motors to the ESC Channel 0 and do the same spin test (using voxl-esc tools), just to confirm that the ESC Channel 0 is working fine.

In order to fix the issue, you could order a new motor and replace it yourself (will be a lot cheaper): https://www.modalai.com/products/starling-2-replacement-parts?variant=49707605393712

You could also send the whole drone back for repair (https://www.modalai.com/rma)

Alex

@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