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

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

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.

@wilkinsaf , M0027 was never shipped to any customers, as it was a test version of the ESC. So there should only be M0049, M0117, M0134 and M0129 (mini) ESCs out there. Like Vinny said, all of those ESCs have a blue status LED for each MCU.

If your ESC has a larger rectangular shape (as opposed to a square), it could be a really old ESC (Atmel-based, not STM32-based), which we do not really support any more. 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.

@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

.. or if you wanted to continue using voxl-camera-server for 4K, just modify the server to save yuv frames on-demand and convert to jpeg later, as we discussed above..

@Morten-Nissov , please only put one sensormodule with the correct slot number in /usr/lib/camera. This will help eliminate any confusion.

Also, does voxl-camera-server -l actually detect your TOF module?

It seems your camera id is actually incorrect. It should be 1. The slot id is 2 (which is tied to the hardware), but the software camera Id is assigned as the cameras are probed in each slot. voxl-camera-server -l will tell you (at the top) which cameras have been detected, which slot and camera ids.

Alex

@KLindgren , based on your picture of the setup, your AR0144 (M0149) is connected to Voxl2 Mini J7U (upper slot) via M0084. This means that the camera will have the camera slot id 3. The orientation of all connections seems correct.

In the dmesg log you posted, I do not see that the camera pipeline attempts to probe the camera in slot id 3 (look at cam-sensorX prints).

Take a look at your /usr/lib/camera/ and see what ar0144 sensormodules you have there. You should have com.qti.sensormodule.ar0144_3.bin there and then voxl-camera-server -l should detect the camera. You can copy the sensormodule from /usr/share/modalai/chi-cdk/ar0144 (and you should probably remove / backup all the other sensormodule files from /usr/lib/camera to avoid any confusion.

Please try.

P.S. the forum does allow you to upload images, perhaps the HEIC format is not supported though.

Alex

@ROBERT-JUDD ,

Our team is getting together a GPS mast kit we can send out for testing on Starling 2 Max. I believe your name is already on the list to receive it.

Regarding your question, the item you circled in blue is a 6-pin connector board that allowed me to extend the short cable using another 6-pin cable. It is kind of bulky, so i just taped over it.

In your implementation, does that look like you have two antennas stacked on top of each other? Can you please elaborate?

Also, did you get a chance to try out the GPS signal viewer in the voxl-portal? how high were your SNR during your test in open sky?

Additionally, as i mentioned before, the proximity of RC transmitter (within < 2 meters) of the drone seems to decrease SNR, so please check that. It seems the RC transmitter is sending out signal outside of 900mhz band, which affects GPS.

Regarding the upgrade mast kit, i am also going to receive it and test it to confirm that it performs similarly to my initial mast.

I am going to perform some more testing in the next few days. I know there are a lot of factors that can affect the GPS signal, i will try to summarize them all in a shorter write-up.

Alex

@h3robotics , yes this is the correct orientation, if you wanted to connect M0181 to VOXL2 J7 (not M0180, i think that was a typo in your question).

Here is the reason why the mounting holes do not line up:

• the M0181 board was originally designed to better fit when connected to VOXL2 J8 (when J6 and J7 are used by M0173 camera front end), then the mounting hole in the tab will line up with the mounting hole on VOXL2 next to the power connector. However, using J8 is not yet officially supported (needs to be tested).
• You could still connect M0181 to VOXL2 J7, but the holes do not line up well.
• When using M0181 with VOXL2 Mini, the mounting hole (the one that is not in the tab) will line up with the Mini's mounting holes.

If you really need to connect M0181 to VOXL2 J8, we could explore this, but i would also need to know what other cameras you are connecting to VOXL2 (and if you are using M0173 camera front end), just to make sure there would not be conflicts with other cameras.

Alex

@Jordyn-Heil , yes i need to add the part that feeds the frames into the video encoder for the ar0144 color use case. it's not difficult, i will do it this week.

Regarding GPU usage, I have only done OpenCL programming on VOXL2, but OpenGL is also supported, I can probably find some resources to help with that. Which one of the two do you prefer? OpenCL would probably be easier (for me to help you) since we have done much more with that already.

Alex

@KLindgren , can you please share a picture of your camera connection?

@KLindgren ,

It is generally not recommended to hot plug the cameras into voxl2 because the camera connectors are not designed for hot plugging.

Just to double check, you have voxl2 mini + M0084 + M0149?

If voxl2 mini fails to boot with M0149 connected, the most likely the M0149 camera is plugged in incorrectly (180 degrees off at the connector). Please double check the pin1 indicator / dot at the M0084 and M0149. Please note that some cameras do not follow the same convention where the camera would be plugged in and point away from the main board (instead it will point toward the main board, as I believe will be the case with M0149).

M0149

M0084
(pin1 circled on the two camera connectors)

You can see that if you correctly plug in M0149, it will be pointing to wards the base of the M0084.

Alex

@Jetson-Nano ,

Thank you for clarifying. Unfortunately, since I don't know what you changed between the working and non-working condition, it is hard to help. Also, since you are indicating that the ESC is responding if you manually start the esc driver, then the ESC itself should still be functional.

Please try to backtrack your changes until you have a working setup again.

Alex

@tom , would you be able to help?

@cegeyer , thank you for reporting this. I have never had this issue when checking gpu usage, but will look into it!