Posts made by benjamin linne

@Vinny

The USB Dropouts seem to be a disconnect and the device refuses to reconnect until physically disconnecting and reconnecting.
We're using the first 4 pins for USB 2.0 on the 3.0 connector as specified in the 3.0 specification https://en.wikipedia.org/wiki/USB_3.0#Pinouts
We've left all the other pins disconnected. I still need to run more tests to determine if it's actually this port or if it's the devic

Hi,

I'm experiencing USB dropouts on the 5G breakout board on the 3.0 port but not the 2.0 port when attempting to run 2.0 devices on the 3.0 port.
Looking at the block diagram, it appears the 2.0 port comes off the same hub. How is that wired since I'm thinking maybe I need to group the remaining grounds or pull the unused signal lines high or low.

Thanks,
Ben

Hey, are there any plans to support 3rd party ESCs with the RB5? Specifically blheli ESCs with DShot support. I'm looking for ESCs that are capable in the 100A range and heard there was some progress being made in . I like the reduced wiring with the modalAI ESC since it uses a single UART, so if there are other compatible ESCs with a higher amperage rating, I'd be interesting in learning about them.

Thanks! I think there was some confusion about which connector to plug into, but that clarifies it. Also, any reason why the RB5 ships with a different antenna type than the VOXL?

Hi, I'm interested in acquiring more WiFi antennas for the RB5, but the original WiFi antennas for the VOXL don't appear to fit, and there's none listed on ModalAI store. Also, are the included WiFi antennas for the RB5 tuned for both 2.4 and 5Ghz? I found 5Ghz in station mode to work very well on the VOXL with significantly faster throughput than connecting to a 2.4Ghz only wifi AP.

Hey @ryan_meagher , I've managed to get micrortps working without the internal uart. I'm using an ftdi adapter from a uart on the voxl to a usb port on-top of the microhard adapter. This is working well, except the voxl is locking up when we are running several nodes. I suspect it to be a problem with DDS requiring more bandwidth and potentially a race condition occurring. I'm interested in trying your voxl_io version if that is working, and I can provide some help to get the ftdi to usb version working if needed.

@Eric-Katzfey I was referring to the documentation for the specific registers that would need to be modified to enable and configure it since I'm familiar with embedded systems that allow that functionality. Another possibility is to add the /dev/watchdog kernel module, however that would require an update to the operating system. If this is possible, it would greatly improve the robustness since we are encountering many cpu lockups that require human intervention to perform hard reboots. For remote applications this is potentially a critical feature

@Eric-Katzfey I'm looking for documentation on the hardware watchdog timers onboard the voxl's snapdragon microcontroller

@Eric-Katzfey Could you point me to how I can setup watchdog timers on the voxl?

@Eric-Katzfey We're having trouble identifying the errors in dmesg. Is there a watchdog timer that could automatically restart the voxl? This will help debugging uas in a remote location without needing a hard reset.

Hi @Chad-Sweet We have a fan and the cpu doesn't appear to be overloaded. Is there any system log capabilities to help identify why the system is locking up and requiring a hard reboot?

@Chad-Sweet how do you recommend debugging this? Is there a system log I can view or any way to identify what is causing the lockup? Also what "release" has voxl-cpu-monitor? I don't think it's included in the latest image.

I wasn't able to run voxl-cpu-monitor but I made a simple bash script that blinks the voxl led every second and it stops blinking once the voxl stops responding. Also I tried tweaking the settings mentioned here https://docs.ros.org/en/ros2_documentation/dashing/Guides/DDS-tuning.html#cross-vendor-tuning, but that didn't help

voxl-cpu-monitor doesn't appear to output anything other than "Init complete, entering main loop"

Yes via USB, however I think that still uses the ip protocol

Edit, it appears after waiting some time the adb and wifi interfaces resume working, but the microhard interface refuses to work. The lights on the microhard indicate it's still connected, but I can't ping the voxl and the voxl can't ping the base station microhard

Hi,

I'm trying to run ros2 on the voxl and it appears to use more data that ros1 and when launching several nodes, sometimes after a while the voxl completely locks up and prevents adb, wifi, or microhard from communicating. My theory is the ipv4 buffer is getting overflown and stops all ip connections. This could make sense since adb also runs on ip.

Is there any way to verify this is the problem and not something else? Is there another way to shell into the voxl without using adb or ip so I can perform and soft-reboot? I've run tests on the power input and that all seems good. Also the flight controller still works when the voxl is locked up. The only fix for now is a hard-reboot

A faster way to replicate is in the MAVLink Console send reboot then hit enter a second later for the shell to reappear then send top and a few seconds later it completely freezes up and requires a hard reboot.

Steps To Reproduce:

1. Connect to uas over wireless connection
2. Run top in MAVLink Console and wait a couple minutes
3. Top will eventually freeze.
4. Observe systemctl status voxl-vision-px4 outputs WARNING PX4 DISCONNECTED FROM UART
5. Attempt systemctl restart voxl-vision-px4 and voxl freezes
6. Only way to fix is a hard reboot

Additional Context:
Running the latest px4 release 1.12 beta5. I also think this behavior can be observed in 1.11. The main issue with 1.12 is the cpu load is significantly higher and I suspect delays in the mavlink processing causes px4-voxl-vision to crash.