ModalAI Forum

As far as I know no one has ever tried this. I don't think HITL is supported by ardupilot (was in the past) but there may be some sort of Simulation on Hardware (SoH) that you could try to get running on VOXL2. I'm guessing it wouldn't be easy.

The ExpressLRS receiver requires* one additional wire. The ghost atto only connects one wire to the VOXL RC RX pin, but the ELRS receiver will also require a connection to the VOXL RC TX pin, otherwise the wiring is identical. Pre-crimped wires can be found easily for the JST GH connectors (J19) to make adding connections simple. *You could leave the receiver's RX line (the VOXL's RC TX) disconnected; this would make updates and other control using the voxl-elrs application impossible but basic RC functionality would work.

@Colby-Howell New order# 8874.

Hi @saegsali yes, I can help with this. Sorry for the delay in responding here... I will email you to enable the schematic transfer and review setup. For your schematic, these items will ensure a speedy and seamless review: Searchable PDF All items annotated and page numbers correct Off page references if multi-page Caps and R's should have their ratings visible (voltages, power, values) A simple block diagram to help me understand what you are trying to do. Thanks!

Hi @moderator The operating range is 2-6S input VBAT. We currently have no plans for >6S at this time on the ESCs. The 40V is a part rating which gives margin for safe operating limits, transient immunity, or other electrical effects. This is documented to instill confidence in our users that we selected quality parts capable of handling various conditions outside of nominal such as back-EMF, energy dumps, incorrect wiring, or severe transients. We are keeping tabs on the trends in this market and will ascertain for future products if increased operating points are warranted broadly. I do see up to 8S is becoming more popular, but it will increase size and cost of products to enable that capability. Thanks!

Hi @rowan-dempster Yes, we know we purposely put the SPI3 bus in two locations. It was intentional, but we have since learned not the best approach for all customers, so we have no plans to do that again. The CS_N issue you are seeing is not surprising. That being said, if you keep continuing with the SW configuration (which may not be easily solved and I do not think we've done that internally yet) our only suggestion for options right now are as follows: Use a different SPI bus. J3/J5 have other options. It is a smaller "Ask" to enable SPI11 on J5 than fix SPI3. https://docs.modalai.com/voxl2-qups/ Rework (i.e,: remove) the IMU (does not help if you need that IMU however). We can give you a waiver on the RMA exclusions on these boards should something else arise not related to that rework process. Hope that helps, and sorry if it's not the news you were hoping for.

Hi @gerhold-ten-voorde Yes, you are correct. Pin 56 is the signal "FORCE_USB_BOOT". It is default weakly pulled down by the SoC. To enter eDL/QDL mode, this switch connects a 2-2.2K pullup to VREG_S4A_1P8 (J3 pin 47). So, on M0154, the default OPEN/OFF position does noting, when ON it enables the pullup. Hope that helps. Thanks! Vinny

@ModalAI-Team; Any updates?

Hi John, Thank you for the information it was very helpful for analysis. It seems as though the firmware crash happens on stream timeouts and causes the firmware to crash. Here is a potential workaround with the installer, I kept all the claude output in case that helps with any analysis on your end: https://drive.google.com/drive/folders/1sbwS3RZ4wgmC2raH7SnDKZz3OYSOavSg?usp=sharing If you could try running that and using the device normally, hopefully that stops it from crashing. We also do have routing on that expansion board for the RESET pin but for some reason the firmware does not respect it. If you keep seeing the issue that might be the next place to look, but NXP has marked this chip as EOL and won't support any fixes there, so our best hope is to workaround whatever is happening. Let us know how that goes and any other findings. Thanks! Luke

Hey @arvind_g3aero So, it does look like you were able to get this working with the dev release of voxl-camera-server which is great to hear. The natural progression of a software package is through dev-> staging -> release. So, this version of voxl-camera-server will be released in a future SDK. There will most likely not be a backport onto the 1.6.2 SDK

@alex-kushleyev Thanks for the response! A control model is a simple MLP (multi-layer perceptron) Input observation space: PX4 odometry topics, ToF depth/Depth estimation model, object detections. Output action space: PX4 offboard commands ( position and yaw for now, but we might extend to velocity/Collective thrust and body rates)

@zuraneb that new download page doesnt seem to be sending out email verification emails so I cant verify my email so I gent register an account, so I cant download the flat builds

Could you post a log of the drone flip?

hi @nostrain , Thank you for providing an important detail regarding unloaded motor. I am going to test that condition with a similar motor. I am a bit hesitant to ask you to go back to the older firmware since we have had a number of improvements since the original firmware, so we will try to figure out how to make this work. In general, the ESC with unloaded motor should not be doing this, even while running in RPM control mode (which has been tuned for optimal response with a propeller). Ideally, the unloaded performance should not fail (while would behave differently from loaded motor). Meanwhile, i am not sure how much value it is to do RPM step response tests with unloaded motor, because RPM controller assumes a loaded motor and the RPM controller is using the tuning parameters you provided. However, the motor behavior is extremely different without the propeller. To test realistic conditions, we typically run robustness tests like this with propeller on. One more request, are you able to repeat the same test with the original firmware (that currently works) and set the demag_timing ESC parameter to 0. This was a feature originally put in for testing to help with low kv motors, but we later decided that this feature was not complete / robust enough to cover general use cases and it was removed. I am curious if it is helping in this case. Alex