@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

@jimbow77 and @oasisartisan ,

TOF V1 (which is now EOL, so you don't have it on Starling 2 Max) was set up the following way:

• The calibration data was downloaded the first time the sensor was used and stored in /data/misc/camera/, then re-used for next time
• calibration files include pmd.spc, tof_cal_eeprom.bin and irs10x0c_lens.cal - the latter likely containing the intrinsics calibraiton data (although i have not checked explicitly)

TOF V2 (what is shipping in Starling 2 (and Max) ), is set up so that the TOF Library downloads (via i2c) the calibration data each time the voxl-camera-server starts. This is done internally to the TOF libraries. I don't know exactly why there is a difference between how the calib data is handled for two sensors by the TOF software, but this is how our sensor vendor helped us set it up. The TOF processing software downloads the calibration from the sensor each time voxl-camera-server starts and applies it to generate the point cloud. It may be possible to get the TOF intrinsics using the TOF library API, but we have not checked.

Do you have a specific reason why the TOF intrinsics are needed?

If you wanted to calibrate the TOF sensor yourself, then you would either need a checkerboard some material that is IR reflective ("white") and non-reflective ("black"). Alternatively, you could use an array of IR leds (or IR reflective dots + IR light) and use dot pattern detector as opposed for checkerboard for calibration.

Regarding Hi-res cameras, the intrinsics are not calibrated and not included. It can be calibrated using our camera calibration app (voxl-camera-calibration), but you should do it at half resolution or smaller (not full size like 4056x3040), otherwise the app runs very slowly. If you need more details how to calibrate at high resolution, let me know (involves downscaling exactly by a factor of 2 and then upscaling the resulting intrinsics)

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.

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

@KnightHawk06 , use voxl-calibrare-camera tracking_down_misp_grey <remaining options>

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.

@Andrew-Jong , we are able to reproduce the error that you are seeing. I believe that you may need to set up a virtual display in order to get this to work. You could try doing so using Weston compositor, which would normally run if the display was available. Please try it and let us know if you are able to get it to work (or not).

You would need to create a config file /etc/xdg/weston/weston.ini

and try running it manually like this :

weston --idle-time=0 --config=/etc/xdg/weston/weston.ini

a sample config file might look something like this:

# configuration file for Weston
[core]
idle-time=0
repaint-window=15

[output]
name=virtual-1
mode=on

We have not tested this yet, but hopefully it's a good start.

Alex

@Catalystmachine

https://www.modalai.com/products/m0155
https://www.modalai.com/products/m0188 (fixed link)
https://www.modalai.com/products/m0194

If you need M0195, you can contact us directly for a custom order (it's not in the shop yet).

https://modalai.com/contact

Alex

@yashpatel ,

Please see some responses below:

i2c_geni a84000.i2c / 884000.i2c: i2c error :-107

This is likely due to a service that is enabled for a sensor that's not present, so the service is restarting and trying to detect the sensor.

• please make sure the voxl-rangefinder-server is not running and also voxl-lepton-server. you can disable the service using systemd : systemctl disable voxl-rangefinder-server.

CAM_ERR: CAM-SENSOR: cam_cci_i2c_read: 35 rc = -22

this one is usually present when you have a sensormodule driver in /usr/lib/camera for a camera that is not actually plugged in, so the probe fails. Double check the cameras that you have plugged in vs sensormodules peresent in the directory above. However, this is usually harmless, if all of your cameras are working properly.

Pin conflict.. We will double check that, but GPIO 130 is on a Board to Board connector that you are most likely not using, so that should not be an issue.

VIO performance..

• please review : https://docs.modalai.com/flying-with-vio/
• try to identify the condition that caused the low feature count (look at the actual images, if possible). may need some hand-held testing and looking at the output.

Please let us know if you have any other questions.

Alex

@oasisartisan , I just checked the API for the TOF sensor and it seems we can get the lens calibration. I would need to make a change in the voxl camera server to try it. Please give me a few days..

Alex

@Leo-Allesch , actually we do have a very limited quantity of the TOF V1, so hopefully that would avoid doing the re-design of the camera mounts and flex routing.

Please reach out to https://modalai.com/contact for a custom order. you probably should get one or two of M0135 as well.

Alex

@Leo-Allesch

So it seems like the VOXL2 ports (J6L, J7L, J7U) seem to be functioning (when tested with the hires or tracking camera and a working M0135)?

Can you please provide more information on your requirements: VSLAM and target detection. Both can be done without TOF sensor. TOF sensor is often used to help with obstacle detection / avoidance in indoor environments.

The easiest way to add the new TOF sensor to your drone would be to use the following:

• sensor: https://www.modalai.com/products/m0178?variant=48528287793456
  • this has the M0177 and M0178 board combo + actual sensor
• adapter : https://docs.modalai.com/M0172/

The connection for the new TOF module to VOXL2 would look like this :

VOXL2 <-> M0172 <-> M0177 <-> M0178 <-> IRS2975 TOF sensor

You are right that the cable routing may be an issue, you would likely need to update the mounting bracket for the camera as well.

I am going to double check if we have any TOF V1 left at all.. will get back to you soon.

Replacement M0135 (if you need):

• https://www.modalai.com/products/mdk-m0135

Alex

@Dan-Jennings , M0181 can be used to enable a Boson and another hires or tracking camera (or Hadron combo), see diagram below. You would need to use the kernal variant 1.0.1 (same one used for M0173, which I am assuming you are already using).

So basically, you can use any standard config C26-C29 + two more cameras connected to VOXL2 J8. Please note that VOXL2 J8 shares CCI (i2c) buses with J6 and J7, so you have to be a little careful about what cameras you connect to J8 to avoid i2c address conflicts. I am going to put together some more information on that soon. But if you are adding a Hadron or Boson + IMX412 to J8, there will be no conflict.

Please let us know if you have any other questions.

Alex

@Leo-Allesch ,

It seems the TOF sensor and camera port 2 are not functional. I am assuming that you tried using both M0135 adapters to test port 2? Considering that it was working before, this is likely not a software issue, but a hardware issue, but it is not clear why exactly.

All of your cameras are interchangeable in the camera ports, as long as the camera ports and sensors are working (and the sensormodule drivers are set up correctly).

By default, the port 1 (camera slot 1), is reserved for use in a stereo configuration when used with M0076, like this one : https://docs.modalai.com/voxl2-camera-configs/#c10---front-stereo-only . So it will not work as a generic camera port when used with M0135. The functionality can be re-configured in software (requires a change in the kernel), but we don't have a ready-to-go kernel with just this change (we can revisit this later, if needed).

By the way, you can also test VOXL2 J8. J8 is set up in a similar way as J6, that is the J8L can be used for any camera, but J8U is reserved (by default) for another stereo pair. However, this will allow you to test yet another port just to double check things. The camera slot IDs for J8 are 4 and 5. Please note that the orientation of J8 is rotated compared to J6 and J7. You can see how a TOF sensor is attached to VOXL2 J8 via M0076 adapter : https://docs.modalai.com/voxl2-camera-configs/#cx---two-time-of-flights-tof . M0076 is a single port version of M0135 interposer (only providing the Lower camera port).

So, if you test VOXL2 J8, use the lower camera port 4 (J8L).

Yes, M0040 is EOL, so the replacements are not available. The upgraded version of TOF sensor is here : https://docs.modalai.com/M0169/ , however it has different dimensions and connector requirements. We can discuss this further if needed.

What is your goal? Do you need the original configuration working or are you potentially looking for any updates?

Alex

@Leo-Allesch ,

OK, i understand. So i think the next step is to figure out what exactly is not working: cameras, M0135 interposers or VOXL2.

Since we know that the camera slot 3 hardware and software path seems to be working, you can try plugging in other cameras (hires, TOF) in to that slot:

• power off VOXL2, disconnect tracking camera, disconnect TOF and hires camera
• plug in IMX214 hires camera into tracking camera's slot, the camera flex will be going towards the center of M0135
• power on voxl2 and copy com.qti.sensormodule.imx214_3.bin from /usr/share/modalai/chi-cdk/imx214 to /usr/lib/camera/. You can leave the existing sensormodules in /usr/lib/camera/, no need to delete.
• run voxl-camera-server -l to see if the camera is detected
• repeat the same test for the TOF sensor ( you will need to copy com.qti.sensormodule.irs1645_3.bin camera driver)

Alternatively, if you have another VOXL2, you could do some testing with that, but I am assuming that another VOXL2 is not available.

Alex

@Leo-Allesch , thanks for checking that. I am assuming that the cameras used to work at some point - can you confirm? What happened between the working and non-working state?

Alex