Topics created by mkriesel

@mkriesel ,

I did a basic test of configuring Boson for external sync using bosonSetExtSyncMode(FLR_BOSON_EXT_SYNC_MODE_E.FLR_BOSON_EXT_SYNC_SLAVE_MODE) in the FLIR python API.

If the sync signal is absent, then Boson just stops sending frames (as expected). Once I installed the missing resistor on the ModalAI Boson adapter to patch the common 30FPS camera sync signal from VOXL2 to Boson, I started receiving frames from Boson at 30FPS. Adjusting the sync signal from 30 to 60FPS resulted in some FPS instability (as well as some minor flickering artifacts) in Boson frames due to the fact that the sync signal coming out of voxl2 has some jitter. Boson timing at 60FPS is very tight, so sync signal coming in too early can cut off the previous frame, so i believe that was happening.

I also noticed that when the sync signal was at 30FPS, the FFC would take twice as long, which is interesting. I wonder if Boson indeed expects 60FPS sync signal and perhaps something may not work properly otherwise. will need to check Boson documentation..

Also keep in mind that the tracking cameras (AR0144) cannot operate at 60FPS in sync'ed mode (different story). So, if you are using sync'ed AR0144 tracking cameras and would like to use 60FPS sync'ed Boson, this may not be possible with the same sync line.

I will need to experiment with this some more. Can you please elaborate on the use of Boson sync in your application (and whether you need VOXL2 to generate the sync signal or you have your own sync signal)?

Alex

@mkriesel , just to confirm, does this test work (run) on other voxl2 boards for you?

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