Hi @austin-c ,

You can find the latest M0138 firmware with regen completely disabled here

Also, I added the esc config that i've been using for testing here

For step tests, i have been using pretty aggressive step command:

./voxl-esc-spin-step.py --id 2 --rpm 2000 --step-amplitude 4000 --step-frequency 2.0 --timeout 2.0 --cmd-rate 2000 --enable-plot 1

In order to make the ESC not de-sync (due to long demag time of the motor), the following params were adjusted:

max_rpm_delta set to 4000 (you can go lower), to cap the maximum rpm transitions. Although in my test, the step is 4000, so this had no effect timing_advance: 45 -- this is pretty high commutation advance to trigger commutation earlier so that there is more time for back-emf sensing -- high advance wiil reduce motor efficiency and will cause the motor to heat up a bit more sense_advance: 30 -- delay back-emf sensing so that we don't sample back-emf during the motor coil demagnetization more details : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/doc/low_kv_motor_tuning.md

I had another thought.. What if you use a small battery to absorb the voltage spikes? Basically hook up a 6-7S battery with a beefy Schottyky diode (10A) set up with Cathode (negative) pointing to the battery.

you will have to make sure the power supply voltage never exceeds battery voltage + diode drop. you will also need to make sure that you don't over-charge the battery with repeated spike absorption.. It is possible to have some sort of self-discharge circuit to slowly discharge the battery to a certain voltage (using a Zener diode + resistor or something similar).

Anyway, just an idea..

Try out the no-regen firmware..

Alex

@fhaltmayer , it looks like there maybe something missing from /usr/lib/camera/, as the camera is detected by the i2c probe but not accepted by the system.

Can you please let me know how exactly the camera is connected (to camera slot/id 2, it seems) and also list all the contents of /usr/lib/camera/.

Alex

@cbay , yes this should work.

Whenever you add cameras of the same type, you should always check for possible I2C (CCI) conflicts. If you look here https://docs.modalai.com/M0188/#image-sensor-interfaces , the sensor IDs 0,2,3,6 (which is what you use) use unique CCI buses 0-3, so that is all good.

If you used ID 1, it would conflict with with another AR0144 on ID6 (both use CCI1)

One last thing to check is the sensor sync.

if you see fsin in the configuration of the sensor (and name of the sensormodule in /usr/lib/camera/), it means it is set up as a sync slave currently you have the IDs 0 and 6 set up as sync slaves, but ID 2 and 3 as free-running

There are two issues enabling sync'ed drivers for AR0144 in ID 2 and 3:

the driver is provided only for ID2 in : /usr/share/modalai/chi-cdk/ar0144-fsin/ - this is easy to fix ID1 and ID3 on M0188 do not have the sync line connected to the camera connector this is easy to fix by installing a 0-ohm resistor, which is DNI by default.

Depending on your requirements for VIO (which VIO are you using?), you may or may not need the cameras synchronized.

Please let me know your requirements and we can go from there..

Alex

Hello @adam , please see the following post regarding GPS signal quality on Starling 2 and Starling 2 Max : https://forum.modalai.com/topic/5116/gnss-emi-mitigation-guidelines

There is no voxl-gps service - voxl-px4 handles the GPS functionality, so as long as that is running, the GPS module should be active. Please go through the documentation linked above, there are some mitigation steps that are relatively easy to implement.

We apologize for the inconvenience, but enabling usable GPS on Starling 2 will require some tweaks.

Alex

@Cliff-Wong said in tarling - Path planning (blue line) is erratic and drone moves to wrong locations:

/etc/modalai/vio_cams.conf

Hi there, thanks for the detailed suggestions!

I have gone through all your steps to discard physical and configuration issues, but it seems I'll need to upgrade. Here is the checklist of what I tested:

Camera orientation: I checked the front camera in voxl-portal and it is completely upright (tops are aligned, ceiling is up, floor is down).

Physical mounts: The VOXL 2 unit is mounted correctly from the factory (USB-C port facing the ground, WiFi dongle on the top side).

IMU Calibration: I ran a full 6DOF voxl-calibrate-imu on a flat surface. It completed successfully, and voxl-inspect-imu shows perfect readings now (X and Y at ~0.00, and Z gravity at exactly -9.80).

VIO config: I checked /etc/modalai/vio_cams.conf. tracking_down is disabled/not present, and it is only using the front camera as expected. Here is my exact configuration:

{
"cams": [{
"enable": true,
"name": "tracking",
"pipe_for_preview": "tracking",
"pipe_for_tracking": "tracking",
"is_occluded_on_ground": false,
"imu": "imu_apps",
"cal_file": "opencv_tracking_intrinsics.yml"
}]
}

Since all physical and configuration checks passed perfectly, I am going to follow your advice and proceed to flash SDK 1.6.3 to take advantage of the advanced config installer and move to OpenVINS.

Thanks again for the help, I'll keep you posted on how the 1.6.3 update goes!

Hi Support team,

I would like to know how to resolve the issue regarding the DEVICE ID change.

Could you please provide a solution for the above?

e.g., Will creating a udev rule file resolve the issue?

Thank you.

Kim,

@Alex-Kushleyev I reached out to Travis last week. I'll bump you here if I don't hear back this week.

@wilkinsaf

I did the following and was able to get it

installed arducopter 4.7 disabled serial2_option for mavlink forward configured compass configured acceleromter turned off GPS_AUTO_CONFIG set SERIAL3_BAUD to 115200

https://www.loom.com/share/b96c3edd2286477ea294ddbd262dc31e

@RyanH ,

Sometimes there is small pieces of random magnetic debris that gets stuck in the motor.

First, you could try using compressed air to clear out the motor.

Additionally, It could help to spin the motor up and down using voxl-esc command line tools a few times to clear it out (without prop is best, just for safety). Spinning the motor without prop a bunch of times could get the debris dislodged and actually broken up by the moving motor parts, so that the debris is no longer large enough to cause a problem. Reversing motor spin using voxl-esc test tools can help dislodge the debris (you can commend negative power/rpm).

You can find useful info regarding motor testing here : https://docs.modalai.com/voxl-escs/faq/

Alex

@Nikos-Mavr I have an extra ac1300 to use that lsusb recognizes but I don't think the driver is implemented. Ac600 Antenna might be malfunctioning after all because even if it lights up on other pcs and identifies WiFis it cannot connect. Is there a way to implement a driver for ac1300?

@Dan-Jennings I'm also guessing that the driver may not be detecting the hardware so is not able to get the data for the battery_status. Have you tried swapping some other hardware to see if the problem is associated with a particular unit?

@MikeR Does your commando 8 have an orq ghost transmitter module connected to it? If it doesn't then it is likely using ELRS which is not compatible with a ghost receiver.

You'd need a orqa transmitter like this one: https://shop.orqafpv.com/products/orqa-orqa-fpv-ctrl-radio-controller

Maybe your other drone had an ELRS receiver on it?

@Nikos-Mavr You're welcome! And can you please start a new forum post for this new issue? Thanks!

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads

Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.