Topics created by mkriesel

@mkriesel , we do not have enough information to be able to pinpoint the root cause, so please try to perform the following test:

on voxl2

systemctl stop voxl-px4 cd /usr/share/modalai/voxl-esc-tools ./voxl-esc-scan.py

The output should look similar to this . Run this scan back to back several times and check if all 4 ESCs are detected each time.

If the esc scan result on voxl2 is not consistently detecting all 4 ESCs, please repeat the same test on a linux PC (you will need the aforementioned UART cable). You can download voxl-esc tools from the git repository here and run the same test, the output should look like this -- almost identical to what is expected when scanning on voxl2.

Thank you

Alex

@tom Gotcha, I did not realize that and in the version of QGC I was using the motor spin tool was not working. I updated QGC and was able to get them working correctly, thanks for the help.

@mkriesel , the exposure and gain period parameters should be set to 1. They were used a long time ago for Auto Exposure control for ov7251 camera, which would have weird image flicker issues if you updated gain every frame, so we would use ae_gain_period set to 2. The issue with ov7251 was also resolved a while ago and it supports gain period of 1.

These parameters specify the update period (in frames) for sending out the new gain and exposure from the AE algo. So these parameters should be set to 1, which is the default for AR0144.

There is no practical reason to use any value other than 1.

Alex

@mkriesel , there is no way to turn off power to just the IMU. It seems your IMU is "broken" and it may not be safe to use it for any application that might involve moving parts 🙂

You can try to restart voxl-imu-server, which will perform a complete re-init of the sensor, but this will probably not fix the actual issue even if it helps with temporarily recovering the sensor from the latched state.

Alex

@mkriesel Great, thanks for the update

@mkriesel,

For global shutter camera like AR0144, the center of exposure will happen at the time that you suggested:

int64_t center_of_exposure_ns = start_of_exposure_ns + exposure_time_ns / 2;

For rolling shutter cameras, this is not true because different lines are exposed at different times. In this case, the center of exposure, which means the center of exposure of the middle line ( 🙂 ) will be:

int64_t center_of_exposure_ns = start_of_exposure_ns + (exposure_time_ns + readout_time_ns)/2;

This means that you will need to know the readout_time (which is time it takes for the full image to be transferred from the camera). It is not currently exposed in camera server or the camera metadata.

Take a look at this resource, it should help understand the rolling shutter case if you need : https://www.1stvision.com/cameras/IDS/IDS-manuals/en/basics-shutter-mode.html , specifically:

shutter_global.png

shutter_rolling.png

Alex

@Alex-Kushleyev Alright, thanks for the info

@Vinny Thanks for the help on this I really appreciate it. I'll take a look.

@Eric-Katzfey ok, thank you

If you need the cpu stress function to generate more heat, here is something that works. you can replace the current function with this one. It adds a memcpy() operation which uses a lot of power. You can tune do_memcpy_every_nth to control more or less heat (decreasing the number will use heat up cpu more).

Original function is here

#define STRESS_ARRAY_SIZE (128*1024) static void* _stress_function(__attribute__((unused)) void* arg) { uint8_t * _stress_array = malloc(sizeof(uint8_t)*STRESS_ARRAY_SIZE); uint32_t cntr = 0; while(stress_running){ cntr++; volatile double s = sqrt(rand()); //this helps slow down the while loop const int do_memcpy_every_nth = 50; //do not perform memcpy every loop because cpu can get hot very quickly if ((cntr % do_memcpy_every_nth) == 0){ memcpy(_stress_array,_stress_array+STRESS_ARRAY_SIZE/2,sizeof(uint8_t)*STRESS_ARRAY_SIZE/2); } } //printf("stress thread exiting\n"); free(_stress_array); return NULL; }

@mkriesel Yep, exactly

OK, here is the clarification regarding camera IDs and sensormodule file names and the general process for camera detection on VOXL2 platforms

all the camera-related drivers are located in /usr/lib/camera the index at the end of sensormodule.bin filename, such as 0 in com.qti.sensormodule.imx678_0.bin is only used to distinguish the files - the actual index at the end is not being used for anything each sensormodule.bin file contains a camera_id parameter, which is read by the camera framework after loading the .bin file the camera_id is then used by the Kernel to look up the specific port information to be used for communication with the specific camera, including (but not limited to): i2c (cci) bus id, mipi interface id, reset pin and others. This information is mapped to each camera port in the Linux Device Tree. with the above information (all basically mapped to a single camera ID), the camera framework knows how to turn on the camera, which bus to use for i2c communication and which mipi port to receive the image data from after obtaining the port information, the camera framework uses other information in sensormodule.bin to detect the camera (query the WHOAMI register for camera identification). If the camera is detected, it is considered to be available for the camera framework to use (not much else is happening until you actually open the camera using the voxl-camera-server, for example). The camera framework also loads the list of available streaming modes which is also contained in the sensormodule.bin after the camera is queried / identified, it is then powered off when voxl-camera-server is started, it sees all the cameras that the camera framework already detected and their corresponding resolutions / modes. Based on the voxl-camera-server.conf, the appropriate cameras are turned on again and set to stream at the desired resolution / fps. lastly, for each camera type, there is a single .so dynamic library (for example com.qti.sensor.imx678.so) which contains functions for converting desired exposure and gain values into the register values that need to be sent to the camera.

With all of this in mind, renaming a sensormodule.bin should achieve nothing because the actual id / number at the end of the file is not used for the camera ID parameter, it is only used for differentiating the files.

If there is still an outstanding request to connect IMX678 camera to a port that is currently not supported, please let us know, we can generate and test the new sensormodule.bin files and release them (assuming there are no other unexpected issues)

Alex

@mkriesel I wonder if that is the reason why IMX678 product on modalai show as out-of-stock at the moment. I contacted FRAMOS and they told me that they did not develop the driver for the sensor but modalai probably did it themselves.