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

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

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.

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)

@aheyne ,

Sorry for the delay.

You can find the M0172 CAD file here

Alex

Hi @JoonaR,

Yes, the Starling 2 drones are shipped with the lepton adapter (M0187), but Lepton sensor itself is not included.

https://docs.modalai.com/M0187/

Alex

Hello @Sarika-Sharma ,

Do you have all these cameras already and are asking how to connect them, or are you looking to purchase them?

If you do have the M0169, can you please post the picture of the TOF module and attached adapters that came with it? I just want to make sure I know exactly what you have, since there are several adapter options.

Also, are you open to any updates to the camera selection, as I can make suggestions to use better cameras (both tracking cameras and hires cameras).

Alex

@Piyush-Singh, please double check that you have the imx214 sensormodule bin for slot 0 in /usr/lib/camera/ (since you have M0084 connected to J6 and the IMX214 camera connected to the "lower" port (JL) of M0084, so the resulting connection of the IMX214 camera will be mapped to VOXL2's J6L (slot 0)).

You can find all the sensormodule files in /usr/share/modalai/chi-cdk/

Alex

Hello @SKA,

Thank you for the details. I can't think of anything right now, but will double check this.

I know that there is one potential issue in voxl-camera-server - the SPS header (which is part of the H264 / H265 stream) is only sent by the video encoder once (at the beginning of the stream). I believe that voxl-streamer will cache the SPS packet (which contains things like resolution, etc) and i think when clients connect to voxl-streamer, then it will send that SPS header to the clients. However, if voxl-streamer does not get that first header, it will not be able to forward it to the clients. This is a guess for now, but could be related to the issue that you are seeing.

I can look into this issue. Can you please let me know how exactly to set up VLC for 0ms cache? I want to make sure that my test is the same. Also, which version of VLC are you using?

Also, i noticed one thing - you are using hires_misp_color stream from camera server, which is not actually encoded, but YUV. Then voxl-streamer will take those YUVs and encode them (using hardware encoder). Is there a reason why you are not using the hires_misp_encoded stream to get H264 directly from camera server and serve it using voxl-streamer without re-encoding? I wonder if in the old SDK you were using _color or _encoded stream?

Alex

@cbay ,

As long as the Boson / Boson+ 640 (or 320) supports MIPI output, it should work. We believe that some Boson models do NOT have MIPI support (HW limitation) but all Boson+ do have MIPI support. Please check with your vendor to make sure MIPI output is supported.

Also, did you actually mean M0187, or something else? M0187 is an adapter for a Flir Lepton : https://docs.modalai.com/M0187/

Alex

Hello @MattB69 ,

Sorry I made a mistake regarding the current rating of the step-up regulator. the 80mA number was for a very low input voltage (to the step-up regulator). with 3.3V intput to the step-up regulator, M0065 can support up to 350mA of output current at 5V, but we still do not recommend using it for powering servos.

So this means that our documentation for D0015 flight configuration is in conflict with documentation for M0065 board (which says use 5.0V for reference only).

Even though we have tested it in the D0015 configuration with "some" servos (i am not sure which ones were used), we still do not recommend powering servos using 5V from M0065. We will update the D0015 documentation.. Thanks for pointing it out!

Alex

Hi @Martin-Lukac ,

Thank you for the update. I am glad to see that your new tests went fine. As I mentioned before, i was quite surprised to see the ESC fail in such a way, which may suggest some kind of anomaly.

I will provide a longer answer soon, but for now some quick notes:

• non-zero kp / ki parameters will speed up the ESC's RPM response. I will provide some examples
• you can test whether the ESC closed-loop controller is stable using voxl-esc tools, using step inputs, etc. if unstable, lower Kp. Then lower Ki to avoid slow overshoots. Ki will definitely not contribute to high frequency oscillations.
• assuming the ESC closed loop response is stable, if the Flight Controller is commanding noisy RPMs, the ESC with aggressive tuning (high kp) will try to track the noisy rpm commands, resulting in motor and ESC heating up.
• there are generally two main sources of oscillations: unstable attitude controller or vibrations / noisy gyro
  • unstable attitude controller : characterized by lower frequency oscillations (in the range of 10-30Hz, depending on your frame, motors, etc)
  • vibrations can result from drone frame twisting at the frequency of motor RPM, or loose flight controller board / IMU, if flight board is shock mounted, the connected wires can potentially carry vibrations or cause the board to flex due to the wires vibrating / moving (very quickly). These vibrations will be at the frequency of motor RPM. aggressive (high) values of ESC kp will amplify these vibrations, so you can end up in a situation when the ESC's closed loop RPM controller is feeding back and contributing to higher oscillations.
  • by analyzing the gyro logs (will need to enable high rate logging), using FFT you can determine if your frame is mechanically unstable / noisy or the attitude controller is unstable.
• if you set kp and ki to 0, you still have the advantage of calibrated (and voltage-compensated) RPM control. However, the control will only have feed-forward term. So behavior will be close to response of a traditional ESC with added calibrated feed-forward rpm control with voltage compensation.
• regarding whether you need a bigger ESC.. it depends on the maximum total current that you plan to pull. The M0138 ESC has been tested with similar motor / prop combo (3110 motor, 900kV with a 10x4.5 tri-blade) . During bench testing, each motor could pull close to 40A at 6S, however in practice you are never going to have all 4 motors spinning at absolute maximum rpm (then you will not have any control margin for attitude). We have tested full punch-out flights for 100+ Amps for over a minute and the ESC was perfectly fine (airflow required for cooling). The mosfets on M0138 are rated for 100A+ continuous (each), so 40A continuous an issue. It will come down to the total current draw and cooling. For high power applications like this, you should definitely start at lighter loads and try to push the ESC to the limit. You will also need to worry about power connector(s) if you are drawing 100A+ continuously (battery connector may melt).
• px4 params: the min and max rpm params in px4 should match the min and max in your esc params. the px4 params do not override the limits in the esc params - the ESC will cap the incoming rpm commands if they are outside of the ESC params limits. Also, if you have incorrect px4 rpm limits, the thrust calculation in px4 will be incorrectly scaled from 0 to 100%, so you definitely want to get those rpm limits to be in sync between the ESC and px4.

Also, you can use our custom version of flight-review to display additional data specific to our ESC (rpm commands, actual rpms, esc temps, etc) : https://github.com/modalai/px4-flight-review (you can run it locally in docker).

Alex

Hi @SKA ,

Can you please clarify a few things:

• using latest SDK, does rtsp streaming work, if you do NOT specify 0ms cache?
• what player are you using for receiving the video? have you tried ffmpeg (if so, what is the full command?)
• are you sure that you are actually have the hires_misp_color stream available from the camera server? you can check it using either voxl-portal or using voxl-inspect-cam hires_misp_color.

Alex

@MattB69 ,

The 5V output on M0065 (10-pin connector with pwm outputs) should not be used to power any servos. The 5V signal is generated from 3.3V (coming from VOXL2) using a step-up converter, only capable of 80mA output).

https://docs.modalai.com/voxl2-io-datasheet/

the 3.3V (which is coming from VOXL2), also should not be used to power servos, as that would be risking bringing down a major power rail on VOXL2.

Alex

@Gary-Holmgren ,

The configuration you are asking about is the standard C28 (https://docs.modalai.com/voxl2-coax-camera-bundles/#mdk-m0173-1-03) with an addition of another hires camera.

Using MISP (not built-in ISP), VOXL2 supports as many hires cameras as can be physically connected (may run into some limitations if you are running at full resolution and encoding all streams at the same time).

C28 config uses VOXL2 + M0173 and you are left with voxl2 J8 (which has two camera ports), so we just need to add another IMX412 to voxl2 J8. The best way to do this would be using M0181 (which supports a Boson + hires camera), it would be connected like this (you can just ignore Boson):

What is not shown here is the standard C28 config (using M0173 adapter, plugged into VOXL2 J6, J7).

Just to make sure there will be enough processing resources for the three IMX412, can you briefly describe what resolution you plan to use and whether you need encoded video, etc. I could test this configuration for you.

Alex