@Alex-Kushleyev I reflashed 1.6.3 on the VOXL 2 twice and it seemed to fix it the second time. Weird that it fixed it and I am also unable to reproduce the issue again. At least it works now lol.

Hi @Jetson-Nano Thank you for your request regarding MTTF and reliability data for the listed hardware components. At this time, we do not publish formal MTTF/MTBF values for these products. The primary reason is that these systems (VOXL2, ESC, Flight Controller V2, Front-End Board, and Camera Modules) are delivered as development platforms intended for user-defined integration, testing, and operation. In the vast majority of use cases, overall system lifetime is dominated by application-specific factors such as mechanical stress, environmental exposure, power integrity, and crash events rather than intrinsic electronic wear-out mechanisms. As a result, standardized MTTF/MTBF metrics are not representative or particularly actionable for these platforms. That said, the underlying silicon and design heritage for these systems is derived from high-volume mobile and embedded computing applications. These components are built on technologies that are broadly characterized for long operational lifetimes under nominal conditions, consistent with industry expectations for modern semiconductor devices. Additionally, portions of the broader technology heritage have been evaluated in demanding environments, including public programs associated with NASA JPL (e.g., Mars Helicopter which is our design heritage, and CADRE lunar rover initiatives). However, detailed qualification data and reports from those efforts and other non-public efforts are not available for external distribution. From a reliability perspective, our hardware is designed and validated using standard industry practices, including: Functional validation across operating voltage and temperature ranges Environmental and stress testing at the system level (i..e: we and our customers put our drones into very demanding scenarios) Design margining consistent with mobile/embedded electronics standards, oftentimes far exceeding industry norm Production screening and quality control processes and test screening For applications requiring higher confidence in operational lifetime, we typically recommend system-level validation under the specific mission profile, including environmental testing (thermal cycling, vibration, shock) and power/load characterization representative of the end use case. Hope this helps.

@shiva-rv Try heating up the IMU by stressing the CPU then shooting it with air to create a large thermal gradient between the silicon of the VOXL2 and the IMU die itself, I predict you'll see the Z bias jump like crazy, but X and Y not so much. You might also observe that the temperature gradient determines the bias, not the absolute temperature, hence using a temperature model for compensation is useless, and not applied by modal: https://gitlab.com/voxl-public/voxl-sdk/services/qrb5165-imu-server/-/blob/master/server/src/imu_interface.cpp?ref_type=heads#L168 If you're curious about the physics of why MEMs IMUs like ICM42688 act this way I'm sure your favorite AI chatbot could give you a nice explanation about the materials sciences at play here. Practically, thermally isolate the IMU component as much as possible.

Hi @the_engineer , Please see the responses to your questions below: Is the drone suitable for such an application, or is there a drone better suited for this kind of application? Starling 2 Max can be equipped with two global shutter tracking cameras, two high resolution (IMX412) cameras and a TOF sensor, providing the most sensing that our platforms offer. Is such indoor autonomous operation is feasible with the Starling 2 Max? dual-camera VIO can be used for indoor navigation (using our integration with Open Vins software) please note that we cannot guarantee performance in your environment and you would like to achieve reliable operation, you would need to become very familiar with the software components and test and address the issues that may come up in your environment depending on how narrow the aisles are, you may consider Starling 2 (not Starling 2 Max) To what extent can this drone be programmed and extended for research or development purposes? majority of ModalAI software that runs on VOXL2 is open source : https://gitlab.com/voxl-public/voxl-sdk/ Is the drone programmable with Python or a similar programming language? Voxl2 runs Ubuntu 18.04 OS and you can use any standard programming languages. Most of voxl2 apis for data access (camera, imu, etc) are in C/C++ which can be extended to python via bindings. ROS is also supported. What charge time can be expected? Typical recommended charge rate for Li-Ion batteries is 1C, so about one hour, maybe a bit more. You are free to explore other battery vendors if you need faster charge times. Is a docking station/ induction charging retrofit possible? we do not support this feature, but it should be possible with additional design. You would probably need to have your own power management board that allows seamlessly disconnecting the old battery (to be charged) and applying a DC power supply. Is the drone capable of navigating in subpar lighting conditions? you would need to test in your specific environment and address any issues that come up. Lighting is not the only factor, but also amount of useful features, etc What is the expected maximum flight time at maximum takeoff weight? see this thread : https://forum.modalai.com/topic/3732/starling-2-max-payload-capacity-and-flight-time-impact additional recommended payload up to 500g What are the operational temperature limits of the drone? Starling 2 Max can operate in reasonable temperatures. However, you would need to monitor your CPU usage - if it hits 95C, automatic throttling will occur and the system may not be able to keep up with all the tasks. ESC is rated to run at least 100C (MCU temperature), so that should not be an issue for this particular drone, which is not significantly loaded in terms of motor power). Does visual obstacle avoidance also work during remote controlled manual flight? please take a look at voxl-vision-hub, but remember that this will be a starting point and you will need to develop your own application based on your requirements and testing : https://docs.modalai.com/voxl-vision-hub/ What is the expected delivery time for the system to Germany? Expected to ship within 60 business days from San Diego, CA, as stated on our web site https://www.modalai.com/products/starling-2-max

Hi @Myles-Levine , I just want to double check something to make sure there is no confusion. The lepton sensor is an IR (thermal) camera. it does not measure range. The lepton sensor plugs into the large square socket that is mounted to the M0157 / M0187 board (they are very similar). The infrared TOF sensor is a smaller (rectangular) sensor, which is marked as U1 on M0187 : https://docs.modalai.com/M0187/ . Have you checked whether the Lepton sensor is working using voxl-portal, which would allow you to look at the IR image coming from the sensor? Alex

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

^^^ This is the next best option outside of ADB IMO - nice suggestion @Alex-Kushleyev

Flat builds should be available now!!

@DronAlan Hi there, the configuration & extrinsics files look fine (just switch offboard mode from figure_eight back to trajectory mode. Since you confirmed figure 8 and position mode are working fine and reflect true ground truth in voxl portal, next is to dive a bit deep into the processes: Just to confirm: are you using a loaded saved map? Orientation can be different in a loaded maps based on how it was saved. Going forward in debugging this I would create the map while flying, then test plan-to-point to ensure it is working properly. Before take off, if you ssh onto the drone and run voxl-vision-hub --debug_offboard and rerun the mapping test (point 1m in front of the drone hovering), and you don't need to map the entire room, just get the general area. In the ssh session, monitor the output from voxl-vision-hub. Take off and fly forward and backward in position mode, with some slight yaw motions to generate a decent map in voxl portal (recall we're generating a map in flight then plan to fly to a point, not using a old-saved map). Then switch into trajectory mode. In the ssh session, you should get a Received trajectory has duration message printed. Goto voxl-portal and plan-a-point. Then execute go-to-point. In the ssh session you should get a Received insert command. printed out on the terminal. And it will show the drone's forward commands, i..e set points, to your planned point. I expect the commanding: XYZ values to increase in the positive X direction. Please post the output of the ssh session here. If the drone moves in the backwards direction as you've been seeing but the commanding XYZs are moving forward, we have found our problem (PX4 issue such that I'll need your params file). If the drone moves forward with commanding XYZs are moving forward then it's how your older maps are being saved and we can go from there.

OK @Daehan-Won Yeah, I'd try to run one first on it's own before the hub to rule that out. Keep us posted. Thanks!

@Alex-Kushleyev, thank you for your answer. I confirm your assumption, when I set the decimator to 1, the fps is not divided. Here are the tests I did on SDK 1.5.0 and SDK 1.6.3 : test with SDK 1.5.0 ; fps = 10 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 2.90 | 0 | 1540 | 28.0 | 10.0 | 3.5 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 7170622 | 240 | 180 | 7.1 | -0.0 0.0 0.0 0 fps = 60 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.30 | 0 | 2155 | 9.3 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 10666991 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 fps = 60 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.18 | 0 | 869 | 9.4 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 10753813 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 test with SDK 1.6.3 fps = 10 | standy_enabled = true or false | decimator = 1 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 3.02 | 0 | 260 | 29.7 | 10.0 | 3.5 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2052194 | 240 | 180 | 7.1 | -0.0 0.0 0.0 0 fps = 60 | standy_enabled = true or false | decimator = 1 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.18 | 0 | 7532 | 9.3 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2190721 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 fps = 60 | standy_enabled = true or false | decimator = 10 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.20 | 0 | 83 | 10.1 | 6.0 | 2.1 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2469720 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 As you can see, for SDK 1.5.0, fhe fps is NEVER divided, regardless of the value of standby_enabled. For SDK 1.6.3, fhe fps is ALWAYS divided, regardless of the value of standby_enabled. So, my problem is solved but I think you have a bug on the management of the paramater 'standby_enabled'. I fastly investigate the code of voxl-camera-server and I can't find where you are using 'standby_enabled'. Here is the search result in all the project : # Query: standby_en # ContextLines: 2 6 results - 2 files include/common_defs.h: 370 modal_exposure_msv_config_t ae_msv_info; ///< ModalAI AE data (MSV) 371 372: int standby_enabled; ///< Standby enabled for lidar 373 int decimator; ///< Decimator to use for standby 374 src/config_file.cpp: 129 printf(" gain_min : %d\n", cams[i].ae_msv_info.gain_min); 130 printf(" gain_max : %d\n", cams[i].ae_msv_info.gain_max); 131: printf(" standby_enabled: %d\n", cams[i].standby_enabled); 132 printf(" decimator: %d\n", cams[i].decimator); 133 printf(" independent_exposure:%d\n", cams[i].ind_exp); 642 // standby settings for tof only 643 if(is_tof_sensor(cam->type)) { 644: json_fetch_bool_with_default(item, "standby_enabled", (int*)&cam->standby_enabled, cam->standby_enabled); 645 json_fetch_int_with_default (item, "decimator", &cam->decimator, cam->decimator); 646 } Maybe you should add a condition in your function PerCameraMgr::ProcessTOFPreviewFrame(): void PerCameraMgr::ProcessTOFPreviewFrame(mpa_ion_buf_t* buffer_info, camera_image_metadata_t meta) { tofFrameCounter++; if(grab_cpu_pitmode_active() && tofFrameCounter % (int)configInfo.decimator != 0){ return; } auto noStridePlaneSize = static_cast<size_t>(pre_width*pre_height*1.5); auto realWidth = static_cast<uint32_t>(pre_width*1.5); uint8_t* noStridePlane; if (buffer_info->stride != realWidth) { noStridePlane = new uint8_t[noStridePlaneSize]; removePlaneStride(buffer_info->stride, realWidth, buffer_info->height, (uint8_t*) buffer_info->vaddress, noStridePlane); } else { noStridePlane = static_cast<uint8_t*>(buffer_info->vaddress); } uint16_t srcPixel16[pre_width * pre_height] = {0}; // NOTE we don't actually puvblish tis particular metadata to the pipe // TOF data is published separately in a very different way to cameras meta.format = IMAGE_FORMAT_RAW8; meta.size_bytes = pre_width * pre_height; meta.stride = pre_width; Mipi12ToRaw16(meta.size_bytes, noStridePlane, srcPixel16); tof_interface->ProcessRAW16(srcPixel16, meta.timestamp_ns); if (buffer_info->stride != realWidth) { delete[] noStridePlane; } M_VERBOSE("Sent tof data to royale for processing\n"); return; } Best regards Quentin

@Alex-Kushleyev Hi Alex, Thank you for the clear and concise explanation.

Adding onto this, is there a way to get the server to log out which operations/how many operations were delegated to the CPU? I believe its something that the tflite interpreter can spit out and would be super useful when trying to figure out why a model isnt loading correctly.