ModalAI Forum

It shows that no bytes have been received over the UART. So you need to see why there are no bytes coming across. Is the receiver generating any? You can attach a oscilloscope to the transmit line from the receiver and see if it is trying to send anything. Are you sure that the receiver and transmitter are properly bound?

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

@Alex-Kushleyev Hi Alex, Looking for some updates on the I/O Expander firmware release? Any news? Also, a follow up question for third-party ESC integration: what is the recommended way of getting telemetry information like battery voltage and current to the FC? Do I need to harness from the ESC to a different port on the VOXL2 or does the IO Expander have the ability to accept this telem information and send it back to voxl-px4 through normal channels?

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

I want to develop a battery management system to read live battery data and use it into a software that plans launch, path, return and control of the drone

I was finally able to get to a Windows PC and try this. I still cannot recreate the issue. I can restart voxl-ardupilot with systemctl restart or via Mission Planner reboot pixhawk and in both cases I can disconnect and then reconnect Mission Planner to ardupilot. I am connected on VOXL2 to my local WiFi network via station mode. I have disabled all other services other than, essentially, voxl-ardupilot and voxl-mavlink-server. I am using recent VOXL2 SDK, recent ArduPilot build, and Mission Planner 1.3.83

Please update your VINS to our master branch here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server For epoch-synced cams, tracking AR0144, please use: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server/-/tree/synced-timestamp?ref_type=heads

Yes, you can connect to one of the UARTs on J19. However, there are only 3 UARTs so you'll have to choose which one to use. The PWM outputs on the IO expander are mainly intended to be used when you have PWM ESCs instead of a ModalAI UART based ESC. In that case you would connect to the ESC UART. If you want to use the IO expander in addition to a ModalAI UART based ESC then you will have to choose between the RC UART or the GNSS UART.