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

@jakkkkobo ,

The source code of voxl-send-neopixel-cmd test tool is here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-io-server/-/blob/master/tools/voxl-send-neopixel-cmd.c

The function that creates a binary packet (which is forwarded to the ESC via PX4) is here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-io-server/-/blob/master/lib/modal_io.c#L181 . Basically you need to provide the following information to this function:

• number of LEDs you are controlling
• LED type (RGB or RGBW)
• array of LED colors (3 bytes for each LED in case of RGB, or 4 bytes per LED for RGBW).
• the array should contain all LED values ranging from 0-255, so if you had 3 LEDs and first should be red, second green and third blue (50% power), the LED color array would be : [127, 0, 0, 0, 127, 0, 0,0,127].
• this function will create a packet with checksum and send it to PX4, and PX4 will forward the packet to the ESC.

You can modify the voxl-send-neopixel-cmd to do what you need, maybe you can make it accept an array of LED color values via command line.

I know the tool could have been more helpful. If you describe your use case, maybe I can help improve the voxl-send-neopixel-cmd tool.

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.

Hi @RoyAzriel ,

Running voxl-inspect-cam -a puts significant stress on VOXL2 as all possible camera streams are generated and sent out to the voxl-inspect-cam application. With a small number of camera or low resolutions this can work fine, but in C29 config, this is not a sustainable test. There are quite a few very large images (4056x3040) per hires camera that are being sent uncompressed, causing a lot of cpu stress.

A better test would be to first run voxl-list-pipes to see which camera pipes are available and then run voxl-inspect-cam with arguments explicitly listing the camera streams to inspect -- ideally choosing one stream per camera.

example : voxl-inspect-cam tracking_front tracking_down hires_front_misp_color etc.

So to answer your question regarding "I wonder how it works well when you ship out C29 from the factory" -- we do not use voxl-inspect-cam -a for testing for the exact reason i described. Single stream per camera verification (can be simultaneous for all cameras) is sufficient to test the camera pipeline.

When voxl-inspect-cam was originally developed, we did not have as many cameras connected and the test worked fine, but started hitting system limits as the number of connected cameras (and their resolution) increased. In reality, you would never have to ship such large images across processes -- there is a better mechanism for sharing large buffers between processes (ION buffer) which avoids sending huge amounts of data over the linux pipes. ION buffer sharing is supported on voxl2 but that is outside of the context of this discussion, i believe

The rotation of the PMD sensor is done in software (camera server config, look for the rotation param) and it is done to match the actual rotation of the sensor in the camera mount. You can disable rotation in the camera server config.

Alex

@j-angel ,

We had a small batch of color AR0144, but those have run out and due to low demand, we do not have any stock.

I would like to clarify something. Motion blur is present when using any camera (global shutter or rolling shutter). Global shutter cameras also have exposure control and long exposure times will cause motion blur.

I think what you may be referring to, which is different in rolling shutter cameras (compared to global shutter), is the rolling shutter skew. Rolling shutter cameras use a technique where the start of exposure of each image row is offset slightly, so each row is essentially exposed over a different time frame. The offset is usually very small (4-30 microseconds per line, depends on the camera, mode), but from top to bottom, the rolling shutter effect can add up and be visible when there are moving features in the scene.

The fastest rolling shutter camera we have right now is IMX412 and in the 2x2 binning mode, the 1920x1080 resolution, the total frame readout time is 4ms. (https://docs.modalai.com/camera-video/low-latency-video-streaming/#camera-pipeline-latency-in-different-operating-modes). This means that the difference of the center of exposure between the first and last image row is 4ms.

Considering the information above, 4ms can seem a lot, but keep in mind that is the time delay across the whole image. depending on the size of features, the rolling shutter effect across a smaller image area will be smaller. Using the height of 1080, we can compute the time offset for each line, 4ms / 1080 ~ 4us.

Depending on the size of features that are being tracked, the rolling shutter may not create a lot of local skew. Additionally, the camera timing is deterministic, so it is possible to calculate the time offset of the center of exposure of each line (with respect to the first line). If you want to provide some more details on type of perception, I could provide more guidance.

Unfortunately, right now, we do not have a color global shutter camera option.

Alex

@nickanick , can you please clarify which exact WIFI Dongle you would like to use?

Are you able to unplug the wifi adapter from USB and plug it back in (while VOXL2 is on) and check what kernel reports in dmesg ?

@Jetson-Nano ,

Thank you for providing detailed description of the tests. I just requested access to the logs.

Please see the following comments:

• ESC temperature: the VOXL FPV ESC is rated for pretty high operating temperatures. For example, the MCUs are rated to run at up to 125C MCU temperature. I would not recommend running the ESC above 100C, however I am confident that the ESC will perform fine even above 100C. We typically recommend designing the system such that ESC temperature does not exceed 80C under normal flight conditions - this gives plenty of margin before a failure would occur. Did you take note of the ESC temps of VOXL ESC?
• VOXL FPV ESC reports two types of temperatures: two of the IDs (ID 0, 3) are measuring the ESC temps from separate temperature sensors located on top and bottom of the ESC. IDs 1 and 2 are reporting the MCU temps (the temperature of the MCU silicon). The MCU temps at steady state are typically a bit higher (5-7 deg C higher) because the MCU itself generates a little heat internally.
• VOXL ESC not responding after a crash : the likely reason is mechanical damage as a result of the crash. Components can be knocked off during the crash. If the ESC powers on briefly (you see the leds blink initially, but then the ESC turns off), then the likely issue is some kind of short or high load on one of the regulated ESC power rails (5V or 3.3V) -- the high current drain (due to some issue) results in the voltage regulator to turn off due to over-current, resulting in the ESCs shutting down. If only 3 out of 4 LEDs blink, then it is possible that one ESC channel has some sort of a short (due to mechanical damage) and it does not turn on, eventually causing the power rails to be disabled due to over-current.
• motor suddenly stopping in flight: this is often a result of a mechanical issue related to mounting the motor to the frame. Sometimes the motor mounting screws are too long and they can penetrate the motor windings and cause intermittent failures just like this. We have experienced this ourselves several times when long screws were used and were touching the motor windings. Alternatively, something could be touching the ESC itself and intermittently affecting operation of the ESC
• once I see the px4 log with the FPV ESC, i can check if one of the motors was operating abnormally before it stopped spinning. There is some additional information in the log that can tell us if a particular motor requires more power to spin (compare to the others).

Questions:

• do you have px4 logs of the VOXL ESC with one of the motors shutting down in flight?
• is it possible that the aluminum enclosure is making contact with the ESC components, causing some kind of short? especially during crash, perhaps the ESC is making contact with the enclosure?
• did you check if the motor temperature was OK after successful flights?
• what was the total current draw during flight when the failure occurred? (should see that in the px4 log)

Alex

@RoyAzriel , which sensors does voxl-camera-server -l detect? you can look at the top part, not the resolution list.

Take a look at this, should have some more info : https://docs.modalai.com/configure-cameras/#connect-a-new-camera

Make sure to double check the camera IDs as they may shift after adding a new sensor. voxl-camera-server -l will tell you the camera ID for each camera / slot number.

Alex

@jameskuesel ,

I think there is another option which i have not considered before. The first three cameras are the same as above:

: M0173 J1: AR0144 slot 0 : CCI0
: M0173 J2: AR0144 slot 6 : CCI1
: M0173 J5: AR0144 slot 2 : CCI2

Then if we use J8U (which can be done using M0181 - it allows you to connect a Boson sensor to lower slot, and a tracking / hires camera to upper slot). Then the fourth camera would be:

VOXL2 J8: M0181 Upper : AR0144 slot 5 : CCI3

And there are no CCI conflicts.

One issue is that we don't typically sell M0181 by itself (only in a kit). Instead you could use two other options, both of which allow connecting a tracking / hires camera to the upper slot:

• M0194 : https://www.modalai.com/products/m0194/
• M0172: https://docs.modalai.com/M0172/ / https://www.modalai.com/products/mdk-m0172-1-00

The only down side of using M0172 / M0194 instead of M0181 is that the two alternatives do not have a mounting hole that would align with VOXL2 mounting hole, but M0181 does have a tab with a mounting hole for VOXL2 J8, see below. The M0172 and M0194 were really designed as mainly options for VOXL2 mini.

@jameskuesel , actually EIS can output any arbitrary resolution, just like non-eis MISP output. What i meant to point out is that in order for EIS to work, you will need to have the stabilized ROI smaller than the full image (which typically means zoom > 1.0 and optional crop / aspect ratio change). So you could still have 4040x3040 eis output but the FOV would be smaller than original. If you take this to extreme and set zoom to 10x you will have a large 4040x3040 output image that was generated from a very small patch of the original image (ROI), so the detail would be very low. Does this make sense?

For those who are interested in more details, a new plot with some further discussion regarding exactly how the higher MIPI bitrate (2100Mbps) can interfere with the lower GPS L1 frequency (1575.42).

The plot shows whether different MIPI bitrates are capable of generating interference for the L1 band, considering that the MIPI data line is not producing a constant frequency (unlike the clock line). Byte sequences of different lengths will have different frequency components and they can have harmonics of the resulting slower frequency end up very close to gps L1. This is exactly what happened with 2100Mbps -- repeating 4-byte sequences can have a third harmonic equal to exactly GPS L1 frequency..

This table shows more details for the mipi data rates that may have strong interference with GPS L1. Actually the tables shows the exact bitrate that would have a perfect interference match to the GPS L1 center frequency.

| Data Rate (Mb/s) | Pattern Length (N) | Harmonic (k) |
| ---------------- | ------------------ | ------------ |
| 787.71           | 2                  | 1            |
| 1050.28          | 2                  | 3            |
| 1260.34          | 4                  | 5            |
| 1575.42          | 1                  | 1            |
| 1800.48          | 8                  | 7            |
| 2100.56          | 4                  | 3            |

In practice, the longer the pattern length, the least likely it is to repeat, creating constant interference. However the 4-byte patterns are very short and 2100Mbps ended up being the worst bitrate choice out of all reasonably fast bitrates (above 1300Mbps), excluding the L1 itself.

similar plot for GPS L5

And combined L1 + L5 plot

The 2088Mbps released in the post above (seemed good, based on the experimental results) seems relatively close to 2100, but it's interference will be about 10Mhz away from GPS L1 center frequency and it has shown to cause only 1-2dB drop when both cameras are running at max resolution. It seems that the absolute safest bitrate for GPS L1 would be around 1650Mbps, which has the largest margin.

Alex

Hi @jameskuesel,

I think we should be merging these new features (independent zoom, independent EIS for each misp channel) to dev this week. I will keep you posted.

Regarding your use case:

• Channel 2, if EIS is enabled, you would not have full frame resolution (4040x3040) -- probably something smaller. if you want to upsample a smaller ROI, this is supported, but would be kind of a waste of processing.

Otherwise it looks like the new changes will support what you need. I will follow up once it's merged and we have some documentation.

Alex