@pmeras , the connector specs are provided here : https://docs.modalai.com/micro-coax-user-guide/ . Specifically, the connector part number is DF56C-26S-0.3V(51). You can find some more information regarding the cable pinout for our hires camera here : https://docs.modalai.com/M0186/ We do not manufacture custom cables, just the ones used in our VOXL camera ecosystem. Alex

@AndrewC , sorry for the delay. There are no hardware modifications to VOXL2 before installing it into Starling 2 Max. You would just need to configure SKU on your new VOXL2 board (https://docs.modalai.com/sku/) and just just reflash the latest SDK to start off clean. During the SDK install, there are a few steps (voxl-configure-mpa) that will load all the needed configurations for your SKU. Please let us know if you have any issues with that. Alex

@james-emi , In our voxl-camera-server, we have a default intrinsics config for the IMX412 camera / lens as follows (focal length approximation is based on a several calibrations). Basically it is a fisheye lens with about 2000px focal length at full resolution (half of that at half resolution, etc). The camera full sensor width is 4056 (hence the x principal point is exactly half of that 2028). In some cases we use slightly trimmed frame (4040 in width). But in any case, that should be enough for a good starting point. lens_cal.width = 4040; lens_cal.height = 3040; lens_cal.fx = 1999.0; lens_cal.fy = 1999.0; lens_cal.cx = 2028.0; lens_cal.cy = 1520.0; lens_cal.is_fisheye = 1; Alex

@Alex-Kushleyev Sounds good, thank you!

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