Posts made by Alex Kushleyev

@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

Hi @jameskuesel ,

Please check these threads:

• https://forum.modalai.com/topic/5010/m0173-with-4-ar0144-tracking-cameras
• https://forum.modalai.com/topic/4491/ar0144-rgb-output-on-voxl2

Specifically, look for the post with these details:

OK, I was able to confirm this configuration:

VOXL2
M0173 + 3x AR0144 + 1x IMX412 (C27 config)
M0155 + 1x AR0144 plugged into J8
AR0144 i2c slave id change via resistor
small camera driver modification for new slave id
also verified the synchronization between the 4 AR0144

You will need to switch the CCI slave id of one of the AR0144 to avoid bus conflicts, as described in the posts, otherwise no issues.

Do you need all 4 AR0144 sync'ed to the same sync pulse (as normally is done in our dual AR0144 config) ? Please keep in mind that sync may not make sense if the 4 cameras are using different exposure values -- on AR0144 cameras, the sync pulse triggers Start of Exposure, so center of exposure could still be different in the "sync'ed" cameras if the exposure length is different. We can discuss more.

Alex

@Jon-Brookshire , sorry for the delay.

Based on the dmesg log, it does look like a cabling issue, causing the USB connection to get dropped and then picked up again. Can you please clarify how exactly, in your case, the new wifi card is connected to VOXL2 and whether you replaced any adapters / cabling when switching back to the older AC600 ?

Alex

@awagner , I believe on VOXL2 Mini should be able to support any 4 cameras on the J6L, J6U, J7L, J7U (specifically the AR0144 (M0149) and IMX412 (M0107), which I assume you are using)

Can you please clarify the error that you are seeing? Is the issue the lack of correct sensormodule or something else? (you can check if correct sensormodules are present in /usr/lib/camera after configuring the cameras). As a reminder, the J6L, maps to slot 0, J6U, slot 1, J7L slot 2 and J7U slot 3.

Are you able to connect the 2 AR0144 cameras to J6 and J7?

What is your goal - how many of each cameras do you need to use? We can test it.

Alex

@qubotics-admin , thanks for doing the motor swap test. From this result, it does appear that one of the ESC channels is not working properly. We would like to take a look at the ESC - are you able to send it back for inspection? We can send you a replacement ESC in return.

Alex

@Jetson-Nano ,

In a case like this, if the ESC works and suddenly stops working, the resulting state is probably a hardware problem (possibly caused by software action or hardware damage). In this state, it is probably impossible to recover the ESC using software and remote diagnostics would be difficult and you would probably not be able to fix the ESC hardware anyway.

Do you have any additional information that could help us understand what happened and the frequency of occurrence? you mentioned two occurrences "recently" -- any more details? What motor/prop/battery was used and was there anything unusual that happened during the test? Do you have a px4 log from the flight? (you could share it privately if needed).

If you are able to ship two failed ESC boards back to us for investigation, i'll ask our team if we can send you new replacement(s).

Alex

@bschulzhf ,

I have just posted the drivers for testing here : https://storage.googleapis.com/modalai_public/temp/imx412_test_bins/20260529/imx412_drivers_20260529.zip

These have the mipi bit rate adjusted slightly from 2100Mbps to 2088Mbps as the latter has shown very little interference based on the prior tests.

These drivers have the following resolutions / modes -- note that two modes use higher bitrate (2200Mbps) in order to achieve the required throughput -- 2200 also seems safe.

Mbps: 2088, 4056x3040, 30.0 fps
Mbps: 2088, 4040x3040, 30.0 fps
Mbps: 2200, 4040x3040, 60.0 fps
Mbps: 2088, 3840x2160, 30.0 fps
Mbps: 2088, 3840x2160, 60.0 fps
Mbps: 2200, 3840x2160, 80.0 fps
Mbps: 2088, 2028x1520, 30.0 fps
Mbps: 2088, 1996x1520, 30.0 fps
Mbps: 2088, 1996x1520, 60.0 fps
Mbps: 2088, 1996x1520, 120.0 fps
Mbps: 2088, 1936x1080, 30.0 fps
Mbps: 2088, 1936x1080, 60.0 fps
Mbps: 2088, 1936x1080, 90.0 fps
Mbps: 2088, 1936x1080, 120.0 fps
Mbps: 2200, 1936x1080, 240.0 fps
Mbps: 2088, 1920x1080, 30.0 fps
Mbps: 2088, 1920x1080, 60.0 fps
Mbps: 2088, 1920x1080, 90.0 fps
Mbps: 2088, 1920x1080, 120.0 fps

In order to allow the system to use all the modes, please double check that the following setting is set correctly in /vendor/etc/camera/camxoverridesettings.txt:

maxRAWSizes=20

We will be doing more testing but most likely these updated drivers will become the official ones in an upcoming SDK release.

Alex

@Eyal , sorry for the delay. Here is some additional information regarding Stinger FPV:

• https://docs.modalai.com/stinger-vision-datasheet/
• base weight with battery : ~570g
• maximum thrust per motor : 650g @ 15V, 2600g total theoretical
• theoretical max thrust to weight ratio: 4.5:1, lots of extra margin, but if you add a LOT of weight, will need to check motor temps, etc.
• CAD model for stinger (may be slightly outdated) : https://forum.modalai.com/topic/5180/looking-stinger-fpv-cad-models -- you can attach your payload to carbon fiber
• I think that Stinger will be easier to tune up with additional payload because of more responsive and powerful propulsion system than Starling 2.
• i dont know what your sensor package is so, it is hard to comment about which platform is better. Starling 2 has landing gear that offsets it from the floor. Stringer is much lower to the ground.

Alex

@awagner

You have the wrong kernel variant installed (2.0.2 instead of 2.0.0) on your voxl2 mini. You should re-install the SDK and select the correct kernel.

On the VOXL2 Mini, kernel versions 2.0.0 and 2.0.2 are ModalAI hardware/kernel variant identifiers (mach.var) used to select the correct device-tree and hardware configuration for different carrier/camera setups.

The key practical difference is:

Variant | Intended Hardware Configuration
2.0.0 | Standard VOXL2 Mini configuration / legacy non-coax adapters (what you are using)
2.0.2 | VOXL2 Mini configured for the M0188, M0194, M0195 and other u-coax camera adapters

When flashing the SDK, the installer exposes this as:

• Standard VOXL2 Mini (2.0.0)
• VOXL2 Mini with M0188 Camera Breakout Board (2.0.2)

Alex

Hi @qubotics-admin , a few comments:

• you don't need to re-calibrate per motor -- one time calibration for the motor / propeller time is sufficient
• make sure to update the correct kV value in the spinup params. although it probably is not the issue here since your motor is 2300kV and the params you started with are for 2400kv, but it's good to make it right. This param affect the spinup procedure.

Questions:

• the the motor connected to ID2 spin at all during the initial spin-up procedure? are you able to share a video?
• if you extend the spinup from 0.5s to 1.0 second, does the same issue persist?
• if you increase the spinup power a bit (i think it may be set to 100 right now (10%), make it 120 and test again? If the current spinup power is not 100 -- whatever it is now, increase by 20% for a test and see if that helps (change it back after the test if there is no improvement).
  • note that if the motor does spin up, it is important to note the rpm at a specific commanded power and compare that rpm to other motors. Sometimes it is possible for a motor to spin even with a partially shorted windings or an issue in the ESC, but it would spin slower than normal, especially under load (with propeller attached).
• i know you said that swapping the motor did not help, but it would be good to test the motor that is not spinning now on ID2 by switching this motor to another ESC ID and making sure it spins ok.

Also,

• please make sure that the windings of the motor are not damaged by the motor mounting screws. this is a common issue when the motor mounting screws are too long and they penetrate into the windings, creating a partial short
• if you have a milliohm meter, the winding resistance can be verified (it should be the same for any pairwise test of any phases for all motors of the same type -- within a few percent)
• inspect the ESC for any debris or any other objects touching the ESC board

Alex

Hi @qubotics-admin ,

Between the two tests, i see that one test shows 16V input voltage and the other test ~7.2V. Was the voltage applied to the ESC the same during the tests (and the ESC read it incorrectly) or the voltage was in fact different?

Such a big difference can have adverse affects on spin-up if the change in voltage is not accounted for in the esc tuning param file.

It is possible that if the ESC does not have correct parameters for your motor / propeller, the sinusoidal spinup does not have enough power and loses tracking during the spin-up phase and fails to transition to steady-state spin stage.

The ESC channel 2 on the FPV ESC is the only channel that measures the total board current, so that is why the printout is slightly different when you test the channel 2.

Please provide the following details that will help us figure out the issue:

• what voltage are you testing the ESC? 16V or 7V?
• what motor/propeller do you have and which ESC params are you using?
• does the "bad" ESC channel ever properly spin up, or it never spins up at any battery voltage?
• is this the first time you are using this motor + propeller + voltage combination with the FPV ESC , or it has been previously working reliably?
• have you performed any ESC parameter tuning using voxl-esc tools?

Alex

@jameskuesel , i have been testing a version of camera server that supports independent zoom / drag on each of the 4 misp channels and also independent EIS modes. This means that you can have one full size unstabilized image and one or more stabilized with EIS and arbitrary zoom and look-at positions for each stream.

There is also an updated voxl-portal version that has the multi view that supports showing and interactive with multiple streams at the same time.

If you would like to test it, let me know, i will need to document a bit. Please provide some more information such as what camera you use and what use cases you need, so i can provide an exact camera server config to test (basically specs for each misp channel, - fps, dims, eis/on off and eis mode)

Alex