Posts made by jenyeom

After multiple tries of updating the firmware and uploading the parameters, it seems to have finally worked!!

For additional info, here is what I get when I run ./voxl-esc-verify-params.py

@Alex-Kushleyev,

As you recommended, I am connected to a PC through a USB and using the latest voxl-est tools from dev branch and it seems to be working somewhat, although I am still having some issues.
I was able to update the firmware for all ESCs to version 39, but when I uploaded the parameters (esc_params_generic_m0117.xml), it only seemed to update on ESCs 0, 1, and 3.
When I scan the ESC now, 0, 1, 3 are at v39 and baud rate of 250k where as ESC 2 is at v39 and baud rate of 57600.

Of note, when I upload the firmware, I have to powercycle for ESC 2 as it does not find it, and I get a different tone when complete with the update, compared to the other ESCs.

Here are some screen shots from when I run ./voxl-esc-scan.pyafter uploading the generic params.

Any ideas how I can get ESC 2 to the desired baud rate?
Thanks again so much for all your help!!

@Alex-Kushleyev
Thanks for the quick response.
I was able to upload firmware version 36, but had issues getting the ESC set to the right baud rate, using voxl-esc-upload-params.py. Even though I was giving it 250,000 as the baud rate, it seemed to be stuck at 57600, which may have been a hint that the params were not loading well (after further reading in the forums and modalai documentation).
However, now I cannot even communicate with the ESC.
Here is what I get when I try the voxl-esc-scan.py script:

Could I have bricked the ESC...?
Any idea how I might go about reviving it?
Nothing (uplading firmware or parameter or scanning) seems to work at this point.
Thanks much!

@Alex-Kushleyev
Just a quick update on this journey...
We completed a full downgrade to SDK 0.8 and still experienced oscillations - so it doesn't seem to be an SDK issue.
The last thing that I can think could be an issue is the updated firmware of the ESC (39) that automatically happens when you update the SDK to 1.1+
Or maybe it was an ESC issue all along..? its hard to say at this point.

In order to track this down, I attempted to downgrade our current ESC to version 36 and had some issues with the baud rate not updating (it seemed to be stuck at a baud rate of 57600). And while updating and checking firmware/parameters, I lost all communication with the ESC.

Here is my post on the ESC page about it:
(https://forum.modalai.com/topic/3310/escs-not-found-esc-bricked)

Hi,

I am currently running an old version of SDK (v0.8) with the legacy 'voxl-slip-uart-bridge' and 'voxl-esc' tools along with the M0117 4-in-1 ESC.
In trying to downgrade the firmware (from 39 back to 36) because of some debugging, I seem to have bricked my ESC...
When I first power on, I get a two-tone sound and all 4 LEDs blink, and one of them blink slightliy longer than the rest of them.
Currently when I run voxl-esc-scan.py I either get one of these two results:

I seem to have maybe messed up the baud rate of the ESCs or they are not responding to the scans.
Do you have any recommendations on how to proceed in trying to communicate with the ESC?
Thank you,

Jennifer

@Alex-Kushleyev thanks for the suggestions!
I did some testing logging timestamps today and here is what I've found.

There was definitely some additional delay when using the voxl_uart_read_bytes function, so currently I am exclusively running the qc_esc_create_rpm_packet4_fb and voxl_uart_write functions.
With those two functions, we are still experiencing high frequency oscillations.
Here is what the time differences (dt) look like when sending rpms to the esc:

The dt goes up to greater than 0.003 sec every now and then, which is why I think we have oscillation issues as we trying to send rpm commands at 500 Hz.

Are these 'spikes' in time something you would expect?
We are not currently running any other functions in the rpm callback, only the creation of the packets and writing to the uart.
Thanks for your help, Alex.

@Alex-Kushleyev going back to getting RPM control working on ROS2 and SDK 1.1+...

Our current findings:
ROS2 Humble with SDK 0.8 and the old library (installed with voxl-slpi-uart-bridge_1.0.0-202303130921_arm64.deb) is working well without any issues.
ROS2 Humble with SDK 1.1+ and the new library libvoxl_io.so and new interface (uart.h) has high frequency oscillations when flying the drone.

We've tried many things to incldue:

1. Updating the crc16.h/c and qc_esc_packet.h/c and other dependent code from:
   [https://github.com/modalai/px4-firmware/blob/main/src/drivers/actuators/voxl_esc]
2. Exhaustive gain tuing
3. Delay time analysis within our control stack
4. Experiments with different baudrates

None of which solved the issue or clarified why we are currently having this issue on SDK 1.1+ with the new SLPI library.

Of note, we are using the functions:
voxl_uart_init(SLPI_QUP2_UART, 250000, 0.1, 0, 1, 0); to initialize the UART,
int32_t packet_length = qc_esc_create_rpm_packet4_fb(rpm0, rpm1, rpm2, rpm3, led, led, led, led, cntr, tx_buf, sizeof(tx_buf), 0); to create packets,
and int ret2 = voxl_uart_write(SLPI_QUP2_UART, tx_buf, packet_length); to actually send the rpms.
Additionally we are using voxl_uart_flush(SLPI_QUP2_UART); because we were having issues with the ring buffer overflow.
We are running everything in ROS2 at 500Hz.

Do you have any thoughts on this?
Any ideas on what we might try next?
Thanks in advance.

@Alex-Kushleyev
Yes, also using the option -w 500 (or other numbers that I'm expecting)

@Alex-Kushleyev
Looks like I do have the same behavior (dt about 1ms) when I run the inspect-imu command with the rate set to 1000.

However, the ROS2 topic of /quadrotor/imu_apps is currently only running at a max rate of ~550 Hz even with the "imu0_sample_rate_hz" set to 1000.
It's interesting because the same ROS2 code prior to updating to SDK 1.1.2 (when it was at SDK 1.0) had no issue publishing the imu_apps topic at the requested rate.
Maybe I'm missing something, but I can't think of anything else that would be different.
I've dug into the imu_interface code in the voxl_mpa_to_ros2 package but haven't found anything related to publishing frequencies.
Do you have any idea what might be throttling the imu_apps publish rate?

With the updated SDK 1.1, I have noticed that the imu_apps publish frequency is maxed out at 500 Hz.
Previously, I was able to set the imu_apps reliably even to ~900 Hz or so, by setting the "imu0_sample_rate_hz" value in 'voxl-imu-server.conf' file.
Now, even when I set it to a higher than 500 Hz value, it continues to only publish at about 500 Hz.

Has anyone else seen this issue or know if there is anything being done to support faster imu pub rates?
Thank you in advance!