Bi-directional dshot - testers wanted

These configs have now been merged so will show up on the firmware server tomorrow

Completely untested, so please let me know if you encounter problems

@andyp1per I tested last PR, this are results:

bdshot-test

In the grid there are number of motor spinning for each combination of parameters. Between each test I did power off / power on otherwise with only reboot I donā€™t get repeatability.
3, 4 means sometimes I obtain 3 sometimes 4.

For now I didnā€™t test ESC RPM, I will do later in the evening. Now really busy.

Ok thanks. Some progress, but no cigar as yet. I have four ESCs now - will wire up and look at the timing.
Interesting that 2Khz dshot rate works well - I wonder why that is. Seems strange that 2.4Khz does not. Note that I can no longer reproduce the issue with the parameter file you posted above.

I do wonder whether its still jitter in the timing - Iā€™ll see whether I can get a more accurate timing rate.

Donā€™t worry for now - my code clearly isnā€™t right yet. I will investigate some more.

1 Like

Hey all,

Just read through the entirety of this forum, 287 posts to date as I am trying to get up to speed on this, but havenā€™t seen any mention of APD ESCs, which do have RPM filtering now with a new FW update.

I have a 550mm setup on 3510 350kv 1345 (E800 DJI) that is equipped with the APD 40F3 speed controllers, have flashed ā€œlatestā€ BiDir firmware for my mRo Pixracer Pro, and have done an initial autotune. Upon reviewing the log, I canā€™t find anywhere that RPM value is being reported, and thus am not quite sure what to reference in regard to setting up the dynamic notch. These ESCS have successfully communicated with Betaflight and reported RPM with 0% error, as I flashed them prior to installing them in the arms of the 550, but I am not sure what I should be doing in order to move towards getting the dynamic notch set. A log can be found at the below link.

any insight would be great,

Thanks

Please read the original post - you donā€™t have any of the required parameters set. There is also a wiki writeup ready to go on this that you can see here: https://github.com/ArduPilot/ardupilot_wiki/blob/e7afc1e3cec040905fa619e3fa5efd9a8cabd814/common/source/docs/common-dshot-blheli32-telemetry.rst

So its very strange. I can reproduce what you see but not reliably. It seems very, very timing sensitive. I found a bug with my 1Khz output so have fixed that, but that still resulted in issues. I finally tried the Betaflight definition for the prescaler and that seemed to yield better results - but could just be a fluke. So please try my latest changes!

Understood. Thanks for the quick reply, Iā€™ll make the required changes and report back. My mistake not reading the initial post close enough.

Andy,

I wanted to get back and report on what I found using the mRo Pixracer Pro in conjunction with APD40F3 ESCS.

Upon flashing the ā€œlatestā€ bdir FW for the PRP, I was able to boot the board, and began to set initial parameters in the original post

SERVO_BLH_BDMASK=15 

(PRP does not have IOMCU)

Given that I am really new to MavProxy (installed and connected to FC via mavproxy tonight for first time), I did not verify that I was getting RPM and error rates in the terminal window, but did move on into MP to see if I could arm, and perhaps look at a log to determine if ESC RPM was being logged. I noticed that when I tried to arm, the whole FC rebooted. Interesting.

Upon reconnecting checking ā€œmessagesā€ in MP, I was able to grab the following output.

3/3/2021 7:56:28 PM : 5 FICSR2051 MM0 MC0 IE0 IEC0 TN:Ardu

3/3/2021 7:56:28 PM : WDG: T-2 SL0 FL127 FT3 FA1FFF06B6 FTP182 FLR813517

3/3/2021 7:56:26 PM : EKF3 IMU1 is using GPS

3/3/2021 7:56:26 PM : EKF3 IMU0 is using GPS

3/3/2021 7:56:18 PM : 5 FICSR2051 MM0 MC0 IE0 IEC0 TN:Ardu

3/3/2021 7:56:18 PM : WDG: T-2 SL0 FL127 FT3 FA1FFF06B6 FTP182 FLR813517

3/3/2021 7:56:08 PM : 5 FICSR2051 MM0 MC0 IE0 IEC0 TN:Ardu

3/3/2021 7:56:08 PM : WDG: T-2 SL0 FL127 FT3 FA1FFF06B6 FTP182 FLR813517

3/3/2021 7:56:03 PM : PreArm: Internal errors 0x800 l:240 watchdog_rst

The above errors were frequently repeating.

At this point, I thought that it would be best to enable LOG_DISARMED to grab a .bin to post here, but this is when the fun started. I tried to spin motor A in the motor test tab. The motor spun for a split second, and then the FC rebooted again. This time however, the FC got stuck in a boot loop and I was unable to connect. After flashing 4.0.7 from the GUI in MP, I was able to get the board out of boot loop, and tried to flash back to the latest bdir for the PRP. I was able to get in and make the change SERVO_BLH_BDMASK=0 which resulted in me being able to boot a few times successfully, but as soon as I wrote parameters on SERVO_BLH_BDMASK=15 the board instantly disconnected and went back to bootlooping.

On one of the occasions I was able to connect to the board with the bdir FW I was able to grab this repeating output:

3/3/2021 8:30:26 PM : motors not allocated

3/3/2021 8:30:26 PM : RCOut: PWM:1-8

3/3/2021 8:30:26 PM : mRoPixracerPr 0044004B 3030510B 3739343

3/3/2021 8:30:26 PM : ChibiOS: a14aa6b0

3/3/2021 8:30:26 PM : ArduCopter V4.1.0-dev (f6231db6)

I have reviewed all of the disarmed logs, but cannot find the errors in the messages tab that I have copied in plain text here. It seems the error is happening before logging starts.

Conclusions that I can draw: The FW was initially stable until setting BDMASK = 15. From that point on there seems to be serious and worsening errors. Was able to connect a few times after setting the BDMASK param and grab some errors from the messages tab, but it got impossible to do that after a little while of messing with it. I have tried to flash the bdir fw a few times now, was unsuccessful in doing so until resetting all parameters to default via the official FW flashed through the GUI, then reflashing the bdir fw. DSHOT 300, and 600 were both tried, with the same results.

With a fresh flash of the bdir FW and default parameters, I verified that setting SERVO_BLH_BDMASK=15 results in immediate boot loop as soon as ā€œwrite paramsā€ is executed, even though this was not the initial result when I first set the param.

Hoping to help in bringing the addition of BiDirectional Dshot to setups using APD and mRo PRP boards, and am happy to test out additional firmwares to try to drill down on any issues.

Donā€™t try flying! WDG is a watchdog reset which means the firmware crashed. Iā€™ll see if I can figure out what caused it.

Do you have MOT_PWM_TYPE set to dshot?

Sorry, no good news regarding latest changes.

With SCHED_LOOP_RATE = 800 I have no more then 3 motors spinning for any combination of SERVO_DSHOT_RATE and MOT_PWM_TYPE

With SCHED_LOOP_RATE = 1000 I have 4 motors spinning for SERVO_DSHOT_RATE = 0, 1 and MOT_PWM_TYPE = 5, 6. Other combinations give or 0 or 3 motors.

Ok, and this is with the config above? My test yesterday was with type = 5 and rate = 0 and that worked fine. Iā€™ll try some other combinations. Youā€™ve check ground etc presumably?

Yes, tested with config above.
I checked signal, but moreover as a test if I set SERVO_BLH_BDMASK = 0 it works always.

Iā€™m beginning to think this is the H7 issue I see on the BeastH7 - Iā€™ll attach some motors and do some tests this evening hopefully

I had to correct the last results, I did it another way and I obtained the following:

bdshot-test1

Not perfect but much better.

Ah interesting - that is good news. I will continue pushing on this theme as it seems to be paying off. Interesting about dshot 150

This is the difference between the two test:

  1. I merged your PR on my local master (from yesterday) with:
    git pull https://github.com/andyp1per/ardupilot pr-matekh743-bdshot
    and then built target MatekH743-bdshot

  2. I cloned your ardupilot repo and checked out the branch:
    git checkout pr-matekh743-bdshot
    and then built target MatekH743-bdshot

Where do the two case differ?

No idea, sorry. It may just be random - I too see some variablilty related to how I power up the flight controller. For instance on the trace sometimes I get no signal from one timer - which I believe is the problem you are seeing.

Anyway I donā€™t like so much this Matek H743 Mini even for thermal problems, it become very hot:

What version of BLHeli do you have? also I have the MatekH743 Slim rather than mini - dunno whether that makes a difference