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

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

@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

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.

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)

@Matt69 , yes you should splice the cable as needed. I will double check if we have plans to release a new cable, it will probably depend on the demand.

Alex

@john_t , sounds good. The DFS processing on VOXL2 happens on the DSP, so it's quite efficient and does not use up much CPU or any GPU.

By the way, you could also simulate lower resolution DFS by binning the 1280x800 into 640x400 and it would be very similar to using the older M0015 stereo modules, so that DFS configuration from M0015 stereo could be used without much change.

Since the AR0144 stereo is not a configuration we currently use / support (but we have tested before), we don't have a ready-to-go documentation for setting this up.

This would be kind of experimental test on your end, which we will support. At minimum, you would need:

• voxl2 + APM + power adapter
• M0173
• two AR0144 (M0166) with appropriate coax cable lengths (comes with 80mm cable, but there are other lengths available via custom order)

If you wanted additional cameras, it may be chaper to get a M0173 bundle: such as https://www.modalai.com/products/m0173?variant=48528274424112 or similar (please check cable lengths)

Once you have the hardware, we can set up a similar test (based on your baseline, camera orientation) and help you get started.

Alex

@Jetson-Nano , can you please elaborate on what happened during the attempt to unbrick the voxl2 board?

@Matt69 , good question. let me ask someone else to help with that

Hello @newdroneflyer ,

In order to adjust focus of the hires camera, you need to do the following:

1. loosen the screw that holds the lens and prevents it from turning. this will allow the lens to turn within the assembly
2. turn the lens using the lens focus tool (should have come with your Starling 2), it is a black plastic tool that goes around the rim of the lens and allows you to turn the lens.
3. after focusing, tighten the screw that was loosened in step 1.

Here is the picture of the focus tool, it has two sizes - one for hires camera, one for tracking camera (if needed). You should have received one with the Starling2 (in an envelope, probably different packaging).

Alex

@Peter-Lingås-0

• some approximate perf specs for EIS are mentioned here : https://docs.modalai.com/camera-video/electronic-image-stabilization/#performance
  • in short, 4K60 (60fps) will use about 30% of the GPU, so two 4K30 would be similar GPU usage. CPU usage for EIS is minimal, as all the heavy lifting is done on the GPU.

Does your YOLOv8 run on CPU or GPU?

There is no documentation on binning, but it is actually very simple : when we talk about 2x2 binning, we typically mean (unless otherwise noted) that the binning happens on the camera itself. Here is a diagram that shows how the pixels are typically binned in the RGGB bayer pattern : https://www.1stvision.com/cameras/IDS/IDS-manuals/uEye_Manual/hw_binning.html

Because the camera does binning internally, this particular camera is able to do processing faster and there is less data to send out, so the readout time is reduced. Please note that not all cameras that output 2x2 binned images actually reduce the read time - some cameras are limited by the analog ADC part, which still has to sample all pixels and then bin them, so for those cameras you would get 2x2 binned image with the same readout time. The readout time is mainly driven by how fast the camera can read the pixels (ADC conversion), process them and send them out via MIPI. The MIPI output is usually not the bottleneck, but the analog/digital processing is.

There is no overhead for VOXL2 to received 2x2 binned image, in fact the power and cpu usage will be slightly reduced (less data to handle). However, you will lose detail if you use 2x2 binned image.

For analyzing small april tags in the distance, well, the smaller they are, the lower the rolling shutter skew will be (locally) so motion blur will probably dominate the distortion, so you would need to set the exposure low. The IMX412 has a good low-light sensitivity, so this allows you to reduce exposure and still get good image.

One last note, when using EIS, we typically use a full frame image (4056x3040, not 3840x2160), which is a 4:3 aspect ratio and provides a lot of margin for stabilization for 3840x2160 output. The readout time for the full frame image is proportionally larger (16ms instead of 12ms), however, locally the read out skew does not change (larger image = larger total rolling shutter skew). Also, EIS supports arbitrary output dimensions, so you can choose how much stabilization margin you want to have vs the stabilized FOV.

Out of curiosity, are you building a custom drone to support this effort or using one of our drones?

Alex

@Sarika-Sharma , thanks for the sending the picture of the TOF module.

In terms of connecting all 4 cameras to VOXL2 Mini, there is a lot of flexibility:

• both M0084 and M0135 provide two camera ports each
• any camera can be connected to any port, but i would probably group two tracking cameras together and then TOF + IMX214
• you could choose where to connect the cameras based on the mechanical integration requirements
• you can replace M0084 with another M0135 if you do not need a longer extension that M0084 provides
• depending on the actual locations of each camera, each camera will have a corresponding camera slot ID (0 through 3) and the camera drivers (sensormodules) will need to be set up correctly, but that is not difficult (we have a helper tools to help with that).
• a few notes about the TOF sensor
  • it needs external power (not from voxl), so you have to connect the red/black wire that branches off from the APM cable to the dark red power connector on the TOF module assembly
  • TOF module is pretty powerful and can potentially overheat if uncooled (with a heat spreader). Please check notes here:
  • https://docs.modalai.com/M0169/
  • https://docs.modalai.com/M0178/ (this is slightly newer version of the assembly, but should have some applicable info as well)
  • to prevent overheating, you can limit maximum "exposure" time for the ToF sensor (that is time the IR emitter is on), please see notes here : https://docs.modalai.com/M0178/#currentpower-consumption (the limit can be set in voxl-camera-server.conf.
  • TOF temperature is currently not possible to display anywhere, but if the TOF sensor overheats, the camera server will show an error and the sensor will stop working until until camera server is reset.
  • my suggestion is to limit the exposure to 2ms (2000us) instead of maximum 6ms in default mode if you do not have a heat spreader attached.
• you can see the heat spreader we now provide with the bundle here (https://www.modalai.com/products/m0178), screenshot below - heat spreader shown in lower left. (note this is the updated adapter configuration for tof sensor, not requiring external power, but we can work with what you already have).
  

Please make sure as you are plugging in all the interposers / flex cables (M0135 and M0084) and cameras that you line up pin1 locations (marked with a dot), so that you can make the connections properly.

Once you connect everything, you can send a picture of the board, flexes and cameras, i can double check the orientation and provide instructions how to actually set up the camera server for your config.

Alex

@jakkkkobo , we don't officially sell this part separately because we usually bundle it with M0173 on drone builds, however we can help you - please send us an email for a custom order.

Alex

Hello @Peter-Lingås-0 ,

I just checked and we have 0 stock of the color AR0144 cameras. At this moment, we do not have a plan to build more (due to lack of demand, as I mentioned). Unfortunately this means that we do not have any color global shutter cameras available.

Regarding rolling shutter, please keep in mind that in 2x2 binned mode, the 4.2ms skew is top to bottom across a pretty large vertical FOV (94 degrees for the lens used in IMX412 camera). Depending on the size of the object that you are looking for, you can calculate the distortion due to motion + rolling shutter skew.

EIS can correct for camera rotation, however motion compensation would require depth information and is a lot more complicated. We do support EIS on voxl2:

• https://docs.modalai.com/camera-video/electronic-image-stabilization/
• here is the performance you might expect (from tests some time ago):
  • dual camera EIS on Starling 2 Max (hand carried) : https://www.youtube.com/watch?v=-BA_nU4kjQs
  • down-facing camera EIS on Starling 2 Max (flight) : https://www.youtube.com/watch?v=-B5xKmBBCAc

You can see the rolling shutter effects present in the hand carried video. The down-facing video demo is a flight at about 5m, actually, might be close to what you are looking for. Both videos were actually shot in 4K (4056x3040 full frame) input mode (longer readout time) and then downscaled to 1080p during EIS (but EIS can also produce 4K output).

Additional notes:

• lower exposure time will not reduce rolling shutter skew, it will reduce motion blur
• 2x2 binned mode automatically gives you 1920x1080 instead of 3840x2160, however you can also get 3840x2160 (or even full frame) and re-scale the image down. You will get better image quality (because the source image is higher resolution), but will have higher rolling shutter skew (12ms vs 4ms -- note it's not exactly 4 times difference due to how the camera operates internally).

Since we don't have an option for global shutter color camera, and the EIS performance looks acceptable, you could try going with IMX412 + EIS (single or dual IMX412 cameras). BTW, VOXL2 can run dual EIS as well, as shown in one of the videos. EIS can work with either full resolution or 2x2 binned as input and output resolution can be arbitrary.

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