Posts made by Alex Kushleyev

@astro_phil , OK, thanks for testing. I will check it myself tomorrow.

Alex

@John-Keller , please try https://docs.modalai.com/voxl2-unbricking/

@Maya-Boker , please see a discussion regarding flight time vs added payload to Starling 2 Max. https://forum.modalai.com/topic/3732/starling-2-max-payload-capacity-and-flight-time-impact

Considering that you would be increasing the mass by 50% in your case (quite substantial), I imagine some flight controller tuning would be required (no ESC tuning needed).

Any new mass should be mounted as close as possible to the geometrical center of the drone in order to reduce the added moment of inertia. Off-center mass will not only have greater impact on the moment of inertia, it will also make the vehicle imbalanced at hover and even more so during accelerations.

You will probably need to perform or at least check the Attitude Controller tuning, and Height Controller tuning (due to increased mass). Please consult the PX4 tuning guide(s) for this, as we do not offer any additional information on that topic. You should be able to use a stock Starling 2 Max tune and make adjustments. If adding 250g does not work well, try a smaller weight increase with a dummy weight and see what tuning parameters you need to change to make it work well again (and then go from there).

Alex

@zaimin78 , I am sorry for the long delay, we somehow missed this post.

Can you please let me know which kernel variant you are using? (you can check it using voxl-version and look at mach.var.

There is no good way of making this configuration work, because the default function of J6U is actually disabled by default in favor for using a stereo camera setup, as shown here : https://docs.modalai.com/voxl2-camera-configs/#c-10-front-stereo-only-ov7251 . So the kernel variant that is compatible with the M0135 / M0076 interposers, cannot be used for any camera in J6U camera slot (slot 1).

However, the J7U and J7L should work. The way to make the 4th camera work is to use either M0135 or M0076 to connect it to J8L (slot 4) instead of J6U.

I am not sure why your J7U (slot 3) did not work -- can you try connecting without extension cables?

Alex

@Arunabh-Sharma ,

I believe the extrinsics file is correct. Here is an extrinsics file for Starling 2 (which can support up to 3 tracking cameras, depending on configuration). https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/misc_files/usr/share/modalai/extrinsic_configs/D0014_Starling_2.conf

tracking_down is the camera we want and the extrinsics are:

"parent": "imu_apps",
"child":  "tracking_down",
"T_child_wrt_parent": [-0.08825, -0.0045, 0.0269],
"RPY_parent_to_child":    [0, 0, 180]

I have labeled the camera X and Y axes on the down-facing rear camera and the rotation matches up with 180 degree yaw with respect to the drone's body axes (X=forward, Y=right, Z= down)

Please note something that may add to the confusion. The front facing tracking camera is technically upside down (using our standard convention that i labeled for the down-facing camera), however we rotate the image 180 degrees in the camera itself during image read-out, so that the image looks right side up without any software work. This 180 degree rotation is selected in voxl-camera-server.conf with a rotation parameter, which instructs voxl-camera-server to set a special register in the camera to reverse the image readout. This is why you will see tracking_front and hires cameras having the same rotation extrinsics, while the tracking_front camera is physically upside down.

Some more info about our extrinsics and conventions : https://docs.modalai.com/configure-extrinsics/

Alex

Hi @Eyal ,

I just did a quick test and I am getting 2.0ms ping time when voxl2 cpu is in perf mode, and about 2.5ms when in auto mode. VOXL2 is idle.

the NCM networking feature works concurrently with ADB, which is great and we also have some scripts to set up NAT if you need your voxl2 to actually use the Linux host as a "router" to access outside world. that is easy to set up as well (requires some routing changes on the linux host).

In terms of real-time streaming, it is definitely adequate for image / video streaming to a Linux host. In fact, this option is my personal favorite way of connecting to Voxl2 while developing / testing cameras and viewing multiple streams in voxl-portal. Voxl-portal uses jpeg compression, which is a lot less efficient than h264/h265 and with the NCM connection, i don't have any issues (compared to adb port forwarding, which also allows voxl-portal to work, but is about 10x slower and uses a lot more CPU, you get frame drops in voxl-portal if required bandwidth is higher than 30-50Mbps or so). I am mainly using the USB-NCM feature for development purposes (as opposed to on a flying drone), but i have not found any limitations, at least for the bench testing use case.

In terms of CPU load affecting the speed, i just ran a test stress -c 8 which loads up all 8 cores to 100% and the ping times did not change in perf mode (2.0ms) and in auto mode, the ping times reduced from 2.5ms to 2.0ms because the cpu cores are actually running at faster speeds. I am guessing that all the USB stuff is happening in the kernel at a higher priority, so it's not affected by the user applications (unless the cpu overheats, i supposed). GPU / DSP loads should not have any effect on this, since they are separate hardware.

I also did another test - stream 4 video streams to voxl-portal (live view), which added up to about 100Mbps of network traffic and ping time stayed between 1.5-3.0ms (sometimes lower than 2.0ms).

I have not observed any stability issues related to NCM being active for long periods of time (days). Make sure you are using a high quality USB-C cable (nothing fancy).

Alex

@Noah-Heinen ,

Here is how you can create a high speed ethernet connection (about 400Mbps) using the USB C port on voxl2 / mini connected to a linux machine:

https://docs.modalai.com/qgc-via-adb/

Also refer to this post as another user has written a script to automate ip assignment on the host side when you plug in the cable. https://forum.modalai.com/topic/1115/px4-qgc-connection-through-usb-for-voxl2/22

If you want to plug in a wifi or ethernet adapter, then you can use MCBL-00022-2 connected to J3 will enable USB3 port, which you can use for the wifi / ethernet adapters.

will check regarding the doodle labs pinout..

Alex

@astro_phil , are you able to test J6 in a similar manner? you can just use the tracking camera alone on both J6L and J6U to see if those hardware paths are working. If J6 is working fully, then there may be a HW issue in voxl2 mini / camera connector.

The error you are getting now when you put tracking camera on J7U is failure to detect the camera via CCI (I2C), which could be either a bad connection in the power path or the CCI signal, or the camera reset signal.

Alex

@ralinaresg ,

After discussing this issue with the team, it looks like the ESC has been reworked after the original manufacturing / assembly. Please submit an RMA request and we can figure out the details about what happened and how to proceed.

https://www.modalai.com/pages/rma

Alex

@astro_phil ,

Which camera connector (J6 or J7) are you using on VOXL2 mini? Also, have you sensormodule (camera driver) to /usr/lib/camera (assuming you are doing a manual configuration). See some details here : https://docs.modalai.com/configure-cameras/#connect-a-new-camera

Since the kernel is reporting that camera probing is failing, this could mean one of several things:

• correct sensormodule for the camera and slot id is not present
• incorrect kernel variant is used (should be 2.0.0)
• a hardware issue in the interposer / camera

You can also check if the tracking camera works in the upper slot (where you have the IMX214 plugged in right now) and vice versa. Swapping the camera slots would require making sure you have correct mating orientation of the connectors and correct sensormodules available.

I just checked on voxl2 mini, we have the following sensormodules available:

voxl2-mini:/usr/share/modalai/chi-cdk/imx214$ ls
com.qti.sensormodule.imx214_0.bin  com.qti.sensormodule.imx214_3.bin
com.qti.sensormodule.imx214_2.bin  com.qti.sensormodule.imx214_4.bin

voxl2-mini:/usr/share/modalai/chi-cdk/ov7251$ ls
com.qti.sensormodule.ov7251_0.bin  com.qti.sensormodule.ov7251_2.bin  com.qti.sensormodule.ov7251_4.bin
com.qti.sensormodule.ov7251_1.bin  com.qti.sensormodule.ov7251_3.bin  com.qti.sensormodule.ov7251_5.bin

So you would not be able to get this combo to work on J6 (slot ids 0 and 1) because the imx214 sensormodule for slot 1 is missing (we did not add it by mistake), but J7 should work (slots 2 and 3). If you put IMX214 into lower slot, and tracking camera in upper slot, then you could use J6 : imx214 : slot 0, ov7251 : slot 1.

Additionally, make sure that you are using the correct kernel for voxl2 mini (it should be 2.0.0, not 2.0.2 when you are using the non coax cameras / interposers). you can check the kernel version using voxl-version and look at the top of the output, under mach. var (machine variant), should be 2.0.0. if not, re-install SDK and select the correct kernel variant during install.

Alex

@ralinaresg , can you please clarify a few things:

• what type of vehicle was the ESC a part of?
• what was the behavior of the motor that was not functioning properly?
• did the whole ESC stop working or only one channel, which was originally struggling?
• did you notice the burned component when the ESC arrived or did it burn after arrival?
• was the black paint already on the ESC when you received it?

Those questions can help us figure out what happened - please provide the details if you are able to.

In any case, if the system arrived in a non-functioning state, you should request a replacement : https://www.modalai.com/pages/rma

Alex

Hi @Jetson-Nano,

Can you please clarify the following - in your original post, you mentioned that the third party ESC also had issues, however in the post above you said no issues. I am quoting your notes from above:

"
Scenario 3 – Third-Party ESC Evaluation
To further isolate the issue, we replaced the VOXL FPV ESC with a NeutronRC X-CLASS 4IN1 ESC V2 (3–8S, 70A) configured using the DShot protocol.

During testing, we observed the following:

ESC temperature increased rapidly, reaching approximately 80°C to 90°C within two minutes of flight.
One motor would subsequently stop during flight.
The aircraft would lose stability and crash.
"

I just wanted to clarify what actually happened and then we can investigate further. Than, you for providing the diagram, i think it looks OK.

I have never seen this behavior where the ESC reports incorrect voltage and these short spikes in temperature. This may point to a hardware issue on the ESC board, but i do not actually know where it might be or what would cause it. Have you visually inspected the FPV ESC that has this issue to see if any components appear damaged or anything looks unusual?

Alex

@nl_vdi , if you log into developer.modalai.com, you will see the CAD models. the latest model we have is:

D0012-4-V3-C28-M36-T7-K0-Starling2-Max-V3-20260317.step

@Eyal ,

I will look for an indoor flight log from a stinger. At hover, the power usage should be around 110-115W based on motor dyno tests. The peak motor current can go up to 300W (per motor), but it's not possible to have all 4 motors maxed out.

Regarding ethernet.. It is actually possible to establish a full wired interface using the same usb interface that is used for ADB. it is a lot more efficient that using something like adb port forwarding. We have some scripts that set up the full network with NAT, when voxl2 / voxl2 mini is connected to a linux host. There is one script that enables the usb ethernet in voxl2 kernel and then there is the host side script to set up the networking and tcp/ip rules for NAT (so that voxl2 can access internet via the host) -- the NAT part is actually optional.

Actually the first part (without NAT) is already documented here, you could try it : https://docs.modalai.com/qgc-via-adb/ -- this will give you a full tcp/ip connection to the linux host.

For downloading log files, we get about 35-37MB/s, it seems to be a 400Mbps link. Even with 1Gbps usb3 adapters we don't get full 1Gbps, so this may be the best you can get. Can you clarify your application for the network connection?

Alex

@cguzikowski ,

Sorry for the delay.

Regarding the new HW not working, since you have two identical setups, i would recommend swapping components to identify what exactly is not working. This is the most efficient way to diagnose it. From the logs you provided, the ov64b camera is detected and initialized, it seems, but no frames come in, which could be a cabling or interposer issue.

I will get back to you with an update on the lens shading tomorrow.

Alex

@Jetson-Nano ,

I looked at the log you shared. There is something strange going on with the voltage sensing on all 4 ESCs at the same time.

Voltage Plot

RPM Plot

ESC Temperature Plot

My thoughts:

• Since you said that you are using a 6S Li-Ion, it should not be possible for voltage to go up to 30+ volts.
• Voltage sensing and Temperature sensing are exhibiting very unusual spikes - i have never seen this before.
• the ESC temp before the crash is around 52C, so that is not an issue at all
• Looking at the RPM plot, i see RPM (actual) humps at around t=58.750s, which is where the measured voltage is reported dipping. Connecting the two pieces information, i am guessing that the actual battery voltage stayed the same, and the ESC measured (incorrectly) wrong voltage, and RPM controller tried to compensate, driving the actual rpm higher (since the battery voltage was still pretty high).

Final thoughts:

• it seems that multiple ADC channels on the ESC are affected (voltage, temperature measurements). A possible reason for this is the ESC MCU power supply (3.3V) is not constant. This could happen if 3.3V regulator on the ESC is overloaded by something (else) or the main 5V switching regulator is overloaded and drops out, causing a dropout on 3.3V.
• All 4 ESC channels are responding almost identically (before one motor stops), which would mean that a software bug is very unlikely. This is a hardware issue that is somehow affecting the ADC (and probably other components) of the ESC.

Please double check your system design to make sure that the ESC power supplies are not affected.

Alex

Hi @bschulzhf

You need to copy the new sensormodule file with the correct slot id (number at the end) to /usr/lib/camera and (re)move the existing one, so that it does not get picked up by the camera pipeline.

Good idea to back up your existing configuration before making changes.

Also more general details here : https://docs.modalai.com/configure-cameras/#connect-a-new-camera

Alex

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?