@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

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

@psafi , before calling voxl-gpio read, you need to enable the pin by setting it to input or output. Please check voxl-gpio -h. (hint: use voxl-gpio -m / voxl-gpio mode)

Alex

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.

@tonygurney , I am assuming that you are using the ESC hardware version M0134 (you can confirm using voxl-esc scan tool.

Here is the datasheet for M0134.
https://docs.modalai.com/modal-esc-datasheet/

This ESC has an option (via installing a 0 ohm resistor) to provide 3.3V to pin 1 of J3. This is the same voltage that is used for the MCUs that run on the ESC and should be used with caution (if this voltage rail is brought down by overloading, the ESC will shut down). Please see image below that shows where 0 ohm resistor should be (carefully) installed to enable 3.3V on pin1 of J3 (marked in red)

If you actually wanted 5V (VAUX), that is available on the other side of the board via two test points at the edge of the board. This voltage rail is provided by a separate switching regulator. See the following section : https://docs.modalai.com/modal-esc-datasheet/#neopixel-led-support

If you REALLY need 5V to be present on pin1 of J3, then you can add a small wire jumper from the VAUX test point directly to the pin1 of J3 (which is marked with a white dot). This pin 1 of J3 is normally disconnected. Please only do this if you are comfortable performing this type of soldering and we cannot guarantee the results :).

Alex

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.

It looks like your machine does not have QEMU support or is missing ARM support on your host machine. Please try instructions here : https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/ (which also show you how to run ARM64 docker images on x86)

Hello @HLaGrone ,

Sorry for the delay in response!

Did something happen to the board that caused it to stop booting?

Are you able to remove the voxl2 board completely from the drone and just try to boot it by itself (nothing plugged in except APM / ESC for power and USB)? Sometimes issues on power rails going to external components (like cameras) can prevent the board from booting.

Alex

Hi @Piyush-Singh,

Sorry for the delay. I believe your issue is the same as in this post : https://forum.modalai.com/topic/4975/hardware-configuration-for-2-m0014-tracking-1-m0169-pmd-tof-1-m0024-hires/ . Specifically, the kernel variant that is installed is 2.0.2 which is designed for newer camera adapters like M0188, M0195.

Please change your kernel to the 2.0.0 variant as described in the thread above (you can test it first before overwriting).

It looks like you do have the right sensormodules in place.

Alex

@Samuel-Lehman

If you have the original adapter for Boson+ which allows you to connect it to a USB port, then you can use the FLIR SDK (we use Boson Plus SDK 4.0). Unfortunately, M0153 board does not have J3 connector populated, which would allow you to connect a serial-to-usb adapter to it.

We have several python scripts, which use the Boson SDK to help set up the Boson sensor without the GUI.

query basic sensor info:
https://storage.googleapis.com/modalai_public/temp/boson/boson_read.py

set up sensor for 8bit MIPI mode, 60fps (option to set 30fps):
https://storage.googleapis.com/modalai_public/temp/boson/boson_set_8bit.py

You can put both of these scripts next to the BosonSDK directory and run them. Please check the USB port name inside the scripts.

Once you get that configured, you can put M0153 back on boson. Regarding where to plug it in on Voxl2, please tell me what other cameras you plan to use with your Boson.

Alex

Hi @Jetson-Nano,

You have an option to send the board back to use for diagnostics for a fee (if you would like to do that, please fill out the RMA form : www.modalai.com/rma). However, the likelihood for a positive result is not very high because the board and the SoC is so complex and finding micro fractures can be very difficult.

Also, let me clarify why you are able to flash the board in EDL mode, but not boot. When in EDL mode, the majority of VOXL2 SoC is not actually running. You basically have direct USB to FLASH storage access in order to write the low-level partitions. So it might look like the board flashes fine, but when you try to boot into the OS, some issue may prevent the board from booting completely.

There is a way to perform some more diagnostics on your own as well. VOXL2 has a debug console UART port, which is accessible via J3 : https://docs.modalai.com/voxl2-connectors/#j3---legacy-board-to-board-connector-b2b (pins 27, 29, which are unprotected, 1.8V levels).

Even though normally we use a perf kernel which disables prints to the console, when the VOXL2 boots, there are debug messages printed to console before the kernel starts. See example below. It also possible to enable the Kernel messages to console witih a debug kernel, which we could provide if needed (or you could also build it yourself, i can tell you how).

Do you have any add-on boards (like M0130, which has an unpopulated connector with console debug 4-pin J6, which is level shifted to 3.3V). I will see if we have any other options to tap into the debug console.

• https://docs.modalai.com/lte-io-breakout-usb-hub-datasheet/#connector-callouts (look for J6 in the diagram, but it's not populated on the actual board)
• the pinout of J6 on M0130, starting witih pin1 is (3.3V, DBG_RX (in), DBG_TX (out), GND)

We also used to make M0017 but it's EOL. https://docs.modalai.com/m0017/

Here is an example of debug console output on a VOXL2 (M0154) with perf kernel (no prints from kernel itself). You should see what you see on your damaged board, perhaps it will actually tell you what the issue is.

Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.3.2-00354-SM8250-1
S - IMAGE_VARIANT_STRING=Soc8250LAA
S - OEM_IMAGE_VERSION_STRING=4ff32558f5a2
S - Boot Interface: UFS
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x00000001
S - JTAG ID @ 0x00786130 = 0x0015a0e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x00786134 = 0xb211f0e6
S - OEM Config Row 0 @ 0x007841e0 = 0x0000000000000000
S - OEM Config Row 1 @ 0x007841e8 = 0x0000000000000000
S - Feature Config Row 0 @ 0x007841f8 = 0x0040200000000400
S - Feature Config Row 1 @ 0x00784200 = 0xc000000000000000
S - Core 0 Frequency, 1516 MHz
S - PBL Patch Ver: 5
S - PBL freq: 600 MHZ
D -      6208 - pbl_apps_init_timestamp
D -     39432 - bootable_media_detect_timestamp
D -       970 - bl_elf_metadata_loading_timestamp
D -       709 - bl_hash_seg_auth_timestamp
D -      6316 - bl_elf_loadable_segment_loading_timestamp
D -      5492 - bl_elf_segs_hash_verify_timestamp
D -      6999 - bl_sec_hash_seg_auth_timestamp
D -       819 - bl_sec_segs_hash_verify_timestamp
D -        35 - pbl_populate_shared_data_and_exit_timestamp
S -     66980 - PBL, End
B -     80795 - SBL1, Start
B -    196023 - SBL1 BUILD @ 20:33:25 on Mar 24 2022
B -    200171 - usb: usb_shared_hs_phy_init: hs phy cfg size , 0xc
D -     10584 - sbl1_hw_init
D -        30 - boot_flash_init
B -    615002 - UFS INQUIRY ID: KIOXIA  THGJFAT0T44BAILB1001
B -    616710 - UFS Boot LUN: 1
D -       884 - Auth Metadata
D -    419406 - sbl1_xblconfig_init
D -         0 - boot_config_data_table_default_init
D -       336 - boot_config_data_table_init
B -    641506 - CDT Version:3,Platform ID:11,Major ID:1,Minor ID:0,Subtype:3
D -     17324 - sbl1_hw_platform_pre_ddr
D -         0 - devcfg init
B -    670573 - PM: PM 0=0x4000008000000040:0x40 
B -    670664 - PM: PM 1=0x4000008000000040:0x800 
B -    675209 - PM: PM 2=0x4000008000000020:0x800 
B -    679875 - PM: PM 5=0x400000000000000:0x0 
B -    684511 - PM: POWER ON by CBLPWR, POWER OFF due to FAULT UVLO
B -    697504 - PM: PMA_2 PON:CBL ON:PON OFF:FLT FAULT1:UVLO
B -    697504 - PM: PMA_3 PON:CBL ON:PON OFF:FLT FAULT1:UVLO
B -    804346 - PM: SET_VAL:Skip
B -    804895 - PM: PSI: b0x00_v0x53
B -    810964 - PM: Device Init # SPMI Transn: 5397
B -    819962 - PM: Driver Init # SPMI Transn: 531
B -    832772 - PM: battery Id: 7574
B -    832772 - PM: Debug Board detected
D -    173576 - pmic XBL init
D -     28548 - vsense_railway_cpr init
D -    209657 - sbl1_hw_pre_ddr_init
D -         0 - boot_dload_handle_forced_dload_timeout
D -      1494 - sbl1_load_ddr_training_data
D -      5124 - sbl1_ddr_set_params
B -    901519 - eCDT MRR - Data Starting Address: 0x09066D00

B -    903715 - DSF version = 156.8.18
B -    907161 - Manufacturer ID = ff, Device Type = 8
B -    910760 - Rank 0 size = 4096 MB, Rank 1 size = 4096 MB
D -     31354 - sbl1_ddr_init
D -         0 - boot_pre_ddi_entry
B -    923967 - do_ddr_training, Start
B -    954406 - DDR: Start of DDR Training Restore
B -    963830 - Frequency = 1805 MHz
B -    963830 - DDR: End of DDR Training Restore
D -     40168 - do_ddr_training, Delta
D -     47793 - sbl1_do_ddr_training
D -         0 - sbl1_hand_control_to_devprog_ddr
D -      1006 - boot_ddi_entry
B -    983167 - Pimem init cmd, entry
D -     10736 - Pimem init cmd, exit
D -     13878 - sbl1_post_ddr_init
D -         0 - sbl1_hw_init_secondary
B -   1003694 - APDP Image Load, Start
D -       824 - Auth Metadata
D -       488 - Segments hash check
D -      9638 - APDP Image Loaded, Delta - (8204 Bytes)
D -         0 - boot_dload_dump_security_regions
B -   1021780 - usb: UFS Serial - e53d3d65
B -   1026264 - usb: chgr -  SDP_CHARGER
D -      8387 - boot_dload_check
D -         0 - boot_cache_set_memory_barrier
D -         0 - boot_smem_debug_init
D -       366 - boot_smem_init
D -        31 - boot_smem_alloc_for_minidump
B -   1047492 - PM: SMEM Chgr Info Write Success
D -      4118 - boot_smem_store_pon_status
D -        30 - sbl1_hw_platform_smem
D -        92 - boot_ddr_share_data_to_aop
D -       518 - boot_clock_init_rpm
D -         0 - boot_vsense_copy_to_smem
D -         0 - boot_share_flash_data
D -        30 - boot_populate_ram_partition_table
D -        31 - boot_populate_ddr_details_shared_table
D -         0 - sbl1_tlmm_init
D -         0 - sbl1_efs_handle_cookies
D -         0 - boot_apt_test
B -   1094218 - OEM_MISC Image Load, Start
D -       732 - Auth Metadata
D -       305 - Segments hash check
D -      9272 - OEM_MISC Image Loaded, Delta - (8192 Bytes)
B -   1106875 - QTI_MISC Image Load, Start
D -      5368 - QTI_MISC Image Loaded, Delta - (0 Bytes)
B -   1123833 - PM: PM Total Mem Allocated: 2964 
D -      7686 - sbl1_pm_aop_pre_init_wrapper
B -   1128408 - AOP Image Load, Start
D -       885 - Auth Metadata
D -      1921 - Segments hash check
D -     13908 - AOP Image Loaded, Delta - (198224 Bytes)
B -   1145641 - QSEE Dev Config Image Load, Start
D -       976 - Auth Metadata
D -       549 - Segments hash check
D -     12505 - QSEE Dev Config Image Loaded, Delta - (45520 Bytes)
B -   1167174 - QSEE Image Load, Start
D -      4331 - Auth Metadata
D -     21685 - Segments hash check
D -     70760 - QSEE Image Loaded, Delta - (3260452 Bytes)
D -       152 - sbl1_hw_play_vibr
B -   1246718 - SEC Image Load, Start
D -      2989 - SEC Image Loaded, Delta - (0 Bytes)
B -   1253214 - CPUCPFW Image Load, Start
D -      4728 - CPUCPFW Image Loaded, Delta - (0 Bytes)
B -   1261785 - QHEE Image Load, Start
D -       854 - Auth Metadata
D -      2715 - Segments hash check
D -     12596 - QHEE Image Loaded, Delta - (448728 Bytes)
B -   1277675 - OEM_HYP Image Load, Start
D -      5277 - OEM_HYP Image Loaded, Delta - (0 Bytes)
B -   1286795 - STI Image Load, Start
D -      5093 - STI Image Loaded, Delta - (0 Bytes)
B -   1295914 - APPSBL Image Load, Start
D -      1037 - Auth Metadata
D -     13024 - Segments hash check
D -     23851 - APPSBL Image Loaded, Delta - (2510848 Bytes)
D -         0 - sbl1_appsbl_arch_determination
B -   1328946 - SBL1, End
D -   1252085 - SBL1, Delta
S - Flash Throughput, 202000 KB/s  (6556580 Bytes,  32309 us)
S - DDR Frequency, 1555 MHz


UEFI Start     [ 1548]


ModalAI v1.0
 - 0x09FC01000 [ 1552] Sec.efi
ASLR        : ON
DEP         : ON (RTB)
Timer Delta : +1 mS
RAM Entry 0 : Base 0x080000000  Size 0x03B800000
RAM Entry 1 : Base 0x180000000  Size 0x100000000
RAM Entry 2 : Base 0x0C0000000  Size 0x0C0000000
Total RAM   : 0x1FB800000
UEFI Ver    : 5.0.220324.BOOT.XF.3.2-00354-SM8250-1
Build Info  : 64b Mar 24 2022 20:33:48
Boot Device : UFS
PROD Mode   : TRUE
Retail      : TRUE
PM0: 30, PM1: 32, PM2: 39, PM3: 33, PM5: 36, 
UFS INQUIRY ID: KIOXIA  THGJFAT0T44BAILB1001
UFS Boot LUN: 1
 Valid primary and !Valid backup partition table
 Restore backup partition table by the primary
 Restore backup partition table success
HW Wdog Setting from PCD : Disabled
DisplayDxe: SW renderer mode enabled!
DisplayDxe: Resolution 640x480 (1 intf)
SPSSDxe:: SPSSDxe_PreLoadChecks SPSS loading in UEFI not supported for this chipID = 455 
UsbConfigLibOpenProtocols: PMI version (0x20)
UsbConfigInit: UsbConfigInit, not start on port: 0, mode 0
UsbConfigInit: UsbConfigInit, not start on port: 1, mode 0
UsbConfigPortsQueryConnectionChange: usbport->connectstate: ATT
APC1 IDDQ WC 0 , L2:0, CPU[0]:175, CPU[1]:175, CPU[2]:175, CPU[3]:175
 APC1 Total 700
LoadSys  TIME 0ms
tsens  TIME 1ms
scm  TIME 2ms
Load CPU 0 Slp: 0x6C, Int: 0x16
Load CPU 1 Slp: 0xE0, Int: 0xFFFFFF65
Load CPU 2 Slp: 0x94, Int: 0xFFFFFFF1
Load CPU 3 Slp: 0x107, Int: 0xFFFFFFB1
Load GPU 0 Slp: 0x99, Int: 0x13B adc_min:0x19E adc_max:0x15C
Load NPU 0 Slp: 0x2C, Int: 0x4F
LmhIsenseInit Pre CPU  TIME 0ms
GLD IDDQ WC 0
LmhIsenseSubSysEntry Post SubSysEntryCb  TIME 0ms
LmhIsenseSubSysEntry Post LmhIsenseSubSysInit  TIME 0ms
LmhIsenseInitSubSys Post SubSysEntry  TIME 0ms
LmhIsenseInitSubSys Post SubSysTrim  TIME 0ms
LmhIsenseInitSubSys Post SubSysExit  TIME 0ms
LmhIsenseInit Post CPU  TIME 0ms
GPU IDDQ 60
LmhIsenseSubSysEntry Post SubSysEntryCb  TIME 0ms
LmhIsenseSubSysEntry Post LmhIsenseSubSysInit  TIME 0ms
LmhIsenseInitSubSys Post SubSysEntry  TIME 0ms
LmhIsenseInitSubSys Post SubSysTrim  TIME 0ms
LmhIsenseInitSubSys Post SubSysExit  TIME 1ms
LmhIsenseInit Post GPU  TIME 2ms
Entering in func1 of NPU  TIME 2ms
NPU IDDQ 70
LmhIsenseSubSysEntry Post SubSysEntryCb  TIME 0ms
LmhIsenseSubSysEntry Post LmhIsenseSubSysInit  TIME 0ms
LmhIsenseInitSubSys Post SubSysEntry  TIME 0ms
LmhIsenseInitSubSys Post SubSysTrim  TIME 0ms
LmhIsenseInitSubSys Post SubSysExit  TIME 0ms
LmhIsenseInit Post NPU  TIME 2ms
isense  TIME 5ms
ISENSE TOTAL TIME 5ms
Disp init wait [ 2031] 
-----------------------------
Platform Init  [ 2050] BDS
UEFI Ver   : 5.0.220324.BOOT.XF.3.2-00354-SM8250-1
Platform           : QRD
Chip Name          : QRB5165
Chip Ver           : 2.1
Chip Serial Number : 0xB211F0E6
Silver cluster Core 0 Freq: 1516 MHz
-----------------------------
UEFI Total : 542 ms
POST Time      [ 2090] OS Loader
Loader Build Info: May 17 2024 23:45:26
VB: Non-secure device: Security State: (0xF7F)
VB: RWDeviceState: Succeed using devinfo!
KeyPress:0, BootReason:0
Fastboot=0, Recovery:0
GetVmData: making ScmCall to get HypInfo
GetVmData: No Vm data present! Status = (0x3)
VM Hyp calls not present
Booting from slot (_a)
Booting Into Mission Mode
Loading Image Start : 2109 ms
Loading Image Done : 2109 ms
Total Image Read size : 4096 Bytes
Loading Image Start : 2109 ms
Loading Image Done : 2135 ms
Total Image Read size : 17981440 Bytes
Loading Image Start : 2141 ms
Loading Image Done : 2166 ms
Total Image Read size : 25165824 Bytes
In Ubuntu ab ota platform, we don't use the system_a / _b slotGetVmData: making ScmCall to get HypInfo
GetVmData: No Vm data present! Status = (0x3)
No Ffbm cookie found, ignore: Not Found
Memory Base Address: 0x80000000
Decompressing kernel image start: 2169 ms
Decompressing kernel image done: 2537 ms
Dtbo hdr magic mismatch 0, with D7B7AB1E
DTB offset is incorrect, kernel image does not have appended DTB
Cmdline: noinitrd  earlycon=msm_geni_serial,0xa90000 androidboot.hardware=qcom androidboot.console=ttyMSM0 androidboot.memcg=1 lpm_levels.sleep_disabled=1 video=vfb:640x400,bpp=32,memsize=3072000 msm_rtb.filter=0x237 service_locator.enable=1 androidboou
RAM Partitions
Add Base: 0x0000000080000000 Available Length: 0x000000003B800000 
Add Base: 0x0000000180000000 Available Length: 0x0000000100000000 
Add Base: 0x00000000C0000000 Available Length: 0x00000000C0000000 
ERROR: Could not get splash memory region node
kaslr-Seed is added to chosen node

Shutting Down UEFI Boot Services: 2607 ms
Start EBS        [ 2607] 
BDS: LogFs sync skipped, Unsupported
App Log Flush : 23 ms
Exit EBS        [ 2645] UEFI End

Hi @Rowan-Dempster ,

I updated both projects to be compatible with 32 and 64 bit builds.

https://gitlab.com/voxl-public/voxl-sdk/core-libs/libmodal-pipe/-/tree/ion-32bit-test
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/tree/ion-32bit-test

Now you should be able to install the libmodal pipe package without breaking 64 bit build and it will enable the 32-bit ion buffer client support.

In order to support this on the 32-bit client application side, you need to have the following defines:

• -DEN_ION_BUF
• -DEN_32BIT_ION_BUF

as seen here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/ion-32bit-test/CMakeLists.txt#L22

Also, you can build just the 32-bit voxl-mpa-tools using ./build.sh arm32-only

I did a quick test. Can you please test to make sure the updated libmodal pipe works with your 32 bit application and also does not break the main 64-bit functionality? Then i think we can merge it to dev.

Thanks for your patience!

Alex

@Sarika-Sharma ,

Your VOXL2 mini uses a kernel variant 2.0.2 (you can see in mach.var field, in the log-in message in your terminal). This kernel is used with M0188, M0195 camera adapter boards and is not compatible with all use cases that use the older adapters and interposers liike M0135 and M0084.

Since you are using older interposers / cables, you need to switch to the original kernel, which you can do during the SDK setup (it will ask you which kernel variant to install, there are only two options).

You can also test and update your kernel without re-installing the sdk. I suggest testing first to see if you can detect all 4 cameras:

• you can find the kernel in your SDK in system-image directory. the original voxl2 mini kernel is qti-ubuntu-robotics-image-m0104-1-boot.img
• test and update kernel instructions here : https://docs.modalai.com/voxl2-kernel-build-guide/#test

By testing the kernel you will temporarily load it into RAM and boot using the kernel, after which you can check if all cameras are detected. If you want the kernel update to persist after power cycle, you need to update it, as documented.

Alex

@Jetson-Nano , the boot issue is not related to the missing U18 (which is a secondary barometer, which was removed from the revised VOXL2 design a while ago (in M0154 revision of the VOXL2 board). The sensor was not used. https://docs.modalai.com/voxl2-onboard-sensors/#barometers

I will double check with the team how to proceed in your case.

Alex

@Matt69 , yes you should splice the cable as needed. I will double check if we have plans to release a new cable, it will probably depend on the demand.

Alex

@john_t , sounds good. The DFS processing on VOXL2 happens on the DSP, so it's quite efficient and does not use up much CPU or any GPU.

By the way, you could also simulate lower resolution DFS by binning the 1280x800 into 640x400 and it would be very similar to using the older M0015 stereo modules, so that DFS configuration from M0015 stereo could be used without much change.

Since the AR0144 stereo is not a configuration we currently use / support (but we have tested before), we don't have a ready-to-go documentation for setting this up.

This would be kind of experimental test on your end, which we will support. At minimum, you would need:

• voxl2 + APM + power adapter
• M0173
• two AR0144 (M0166) with appropriate coax cable lengths (comes with 80mm cable, but there are other lengths available via custom order)

If you wanted additional cameras, it may be chaper to get a M0173 bundle: such as https://www.modalai.com/products/m0173?variant=48528274424112 or similar (please check cable lengths)

Once you have the hardware, we can set up a similar test (based on your baseline, camera orientation) and help you get started.

Alex

@Jetson-Nano , can you please elaborate on what happened during the attempt to unbrick the voxl2 board?