Topics created by Stefan Amundarain

Hello, @Stefan-Amundarain ,

Let's try to narrow this down. Can you reproduce the issue without flying?

When the issue occurs, does the camera server restart completely, or you only lose hires camera feed. I suggest running the test on the bench with voxl-camera-server running in foreground so you can easily see what's happening in real time.

Please try to reproduce on the bench all 3 cameras (hires, tracking, TOF) working with your Ark Flow board working as well, then you can just move the platform by hand, if needed, to cause the camera failure and investigate what:

voxl-camera-server outputs output of dmesg

We can go from there.

Also, can you please provide details how the ARK Flow is actually connected to VOXL2 (electrically) and also confirm that the issue does not happen at all without ARK Flow plugged in?

Also, using voxl-portal should not cause the camera server or the portal backend to get bogged down if your image is reasonable size (not full 4k image), but a small 720p is just fine.

You could view the 3 camera streams thru voxl portal during the test or just have the voxl-inspect-cam tool running and inspecting just the streams that you want (you can provide the streams to inspect as arguments to the tool, such as voxl-inspect-cam hires tracking_down tof_depth, etc. Either voxl-portal or voxl-inspect-cam should properly use the camera pipeline with all camera streaming, so that you can catch the fault.

Alex

@rdjarvis Okay, great! Instead of starting voxl-px4 with systemctl start voxl-px4 can you start it as a foreground process using voxl-px4 -d and then capture the output and paste as a response? I'd like to see if there are any error messages printed that could help determine why it isn't seeing your GPS unit.

@Alex-Kushleyev this issue was due to poor amperage out of the shore power module. swapped for a different power source and issue was resolved.

@Stefan-Amundarain ,

Quick tip: if you use --id 2 during the calibration, the total current will be reported because the ESC ID2 senses the total board current. Note that if you have other load connected to the ESC, like VOXL2, that current will also be included, but it's better than nothing. Generally VOXL2 will consume little power compared to a motor spining a 5-inch propeller at high speed. The current measurement is not used for anything in the calibration, but it is a good sanity check to make sure things are behaving properly.

The first plot (commanded motor voltage vs rpm is close to linear, which is a good result).

Do not try to "blindly" change the a0, a1, and a2 parameters, as they are the coefficients of a quadratic curve used for feed-forward component of the RPM controller. It is not possible to just guess it.

Also another tip, if you are running this calibration VOXL2 (as opposed to a PC), if you enable the cpu performance mode (voxl-set-cpu-mode perf), it should reduce some delays in running the calibration script and the data should look a bit cleaner (although i don't think it is an issue here).

After performing the calibration and updating the calibration esc params file, make sure you are actually uploading that to the ESC using voxl-esc-upload-params.py script.

Finally, after updating the params, what command are you using to test the ESC?

You can gently test the RPM response using a ramp test, similar to what is described here:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/low_kv_motor_tuning.md?ref_type=heads#power-ramp-test , but instead of power ramp, you can do an rpm ramp:

./voxl-esc-spin.py --id 2 --rpm 12000 --ramp-time 3.0 --timeout 3.5 --enable-plot 1 --cmd-rate 250

I would be curious to see the plot of that test.

You can vary the rpm target in the test (make it higher) as you become more comfortable with the performance.

The closest param file to what you are testing is probably this one : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/FPV_RevB/m0138_xing2_1855_5x4x3.xml?ref_type=heads using Xing2 2207 1855kv with 5.1x4.1x3 tri-blade propeller, but this tuning is for 6S battery -- do not use this param file directly because the a0, a1, a2 params will be wrong (because you are using 4S)

Please double check your results and if it is still not working, i can test your calibration file on my setup with the xing2 motor with a 4S battery.

Alex

We removed the RC and are able to fly with a wired gamepad.

Could the control loss be due to a voltage drop on the J19 12-PIN JST to the Rx? I will check later today.

Hi @Stefan-Amundarain ,

Thank you for uploading the video with the detailed demonstration.

What I see from the video is that the initial "sinusoidal" spin-up works (almost) every time, but the ESC fails to transition to regular non-sinusoidal control mode. There are typically two reasons for this:

a bad motor / wiring / connection or one of the ESC Mosfets is not working properly. In some failures, the sinusoidal spin-up is still able to rotate the motor, but during the transition to normal operating mode, there are some checks to ensure proper motor behavior and if those checks fail, the ESC stops (and then restarts since you are commanding it to spin). The behavior i am seeing is very similar to this.

sometimes if you have spin-up time too fast (and spin-up power too low), the ESC will lose sync with the motor during sinusoidal spin-up. I would suggest trying to (you can do both changes at once):

increase the spin-up time (double it from what you have now) increase the spin-up power by 20% (if it is 100 (which is 10% power), set it to 120, so it will be 12% power). also double check that the motor kV is set correctly, because it is used during sinusoidal spin-up for back-emf compensation.

I would also suggest swapping out the motor for an identical new motor, so you can eliminate the motor being an issue. You can also check the motor winding resistance to make sure all 3 possible pair-wise resistance measurements have the same resistance.

Finally, if all of these steps fail, please try to use another ESC channel to see if it is a dead ESC channel (which should be unlikely).

Please try these out and let me know what you find!

Alex

@Stefan-Amundarain ,

It is always good to double check the firmware version of our ESCs and IO board (whichever you are using) so that you have control over the version that you are using and do not upgrade unless that is your intention or use outdated firmware. Typically when we release the new SDK we recommend updating ESC and IO board firmware because some features will require the update.

However, if you just receive a new board, you probably want to upgrade it to the firmware version that you have already been using or version required by the sdk.

Our voxl-esc tools (used for firmware update, checking) are used for IO board and ESC and make it easy to check and update firmware in an automated way to ensure you are running the firmware that you intended.

If you need more help with this, please let me know.

Alex

@Stefan-Amundarain We have not tried getting Internet traffic routed to the Doodle Labs network. Should be possible but we haven't done it.

@Stefan-Amundarain That's the correct QDL image for QRB5165. The next step would be to submit an RMA: https://www.modalai.com/pages/rma

@Stefan-Amundarain As a member of the software team I have no knowledge of your orders. I gave you the missing info you needed and a path forward using your existing hardware. If you'd like to get a replacement you can reach out to contact@modalai.com and they'll get you sorted quickly.

@Stefan-Amundarain Thanks for your patience! There is a slight bug in the flashing script that doesn't handle fixing the partition layout correctly without forcing it via. that arg. It'll be fixed in the next release (SDK 1.3..0)

@Alex-Kushleyev

all is working now. Not sure what has changed but we are all set. Thank you for your help Alex!

Stefan