Hi Liang-tang, probably best to ask in the ArduPilot/ChibiOS gitter channel. There’s a higher number of people familiar with the details of the ChibiOS builds.
Thank you for your attention!
In the follow-up, I will continue to conduct various tests, try to cover as many test areas as possible, and report test feedback in time.
Ekf errors during the log download process, at least not affecting flight safety, are just strange, because this has not happened in previous firmware.
I haven’t tried to load the ChibiOS firmware into PX4v4, and with the FBL unit, there will be different effects. I may try it later.
Tested RC-3 nuttx on Octo Pixhawk clone. Seems fine. legs retract.
Tested ChibiOS RC-3 on same frame flys well…
This is my second mRo 2.1 fight controller that fly’s bad in ChibiOS . Relay shakes however flashing with Nuttx RC-1 and RC-3. is fine. REPRODUCIBLE.
also radio is stuck in boot mode solid red light in Chi.
After some additional help from on gitter, i have been successful,
Trick is to put board in to DFU mode, change the driver using zadig, and set no reboot and erase flash options in configurator
When trying to load Copter 3.6.0-rc3 firmware through mission planneri get the error below
The Mission Planner build is 184.108.40.206 build 1.36755.6422
@quadsours as I mentioned in the other posting, I’d need to see two DF logs of back-to-back flights with exactly the same parameters, same firmware version, the only difference being the load of px4-v3 versus fmuv3 firmware.
Yes this is exactly what i been doing swamping the two types px4-v3 and fmmuv3 same frame same config 100% then took it for a fly within 20 min apart. . I done this as a tester on each rev with the same results. regarding the log I did upload them last week. let me link them for you they could be a day apart but same hardware. I did not want to use my black hex as a test as i am sure its something in the FM. but I did today and Chibios build doing the same. this make two FC same make and brand following your instruction of today. I like to thank you for responding and thanks for cool stuff your doing.
Note I could not find the PX4-v3 after RC-2 was released to roll back so it was made for me by Randy and stable. All other version of Chibios have v 2.1 issues. If this does not work for you let me know i I will do it again.
Ok I think i have the two log files from the video today the small size log would be the ChibiOS “fmuv3” . and the larger log Nuttx px4-v3 was firmware I compiled 2 days ago.“stable”
Ah, excellent! Txs for the report. I’m especially happy to hear that the landing gear is working.
sorry, it still doesn’t match. The ChibiOS and NuttX logs have different tuning parameters, different compass cal, different RC cal etc.
I’ve created a pair of firmwares for you to test here:
if you could test those back-to-back, with no change in parameters and no recalibration between that would be really appreciated. Then upload the BIN logfiles from microSD.
Ok I will do that going to celebrate the 4th with a beer and file my logs for tomorrow afternoon.
Have a little more daylight so did the test Here is back to back… I went to download logs deleted all, then loaded chibIO via your master it did fly better but a tad shaky. I downloaded the log to MP logs and did the same for nutts.
log from Master directory.
If that does not work let me know.
BTW the ChibiOS will not let me connect the the 915MHz radios I have a hack to get out of boot mode until l remove the two wires. not a issue int Nuttx. master px4-v3
About the radio I did find a very odd bug last month regarding the 915 radio and how it is connected to Mission Planner. if connected via usb and then battery it wound fly. if not it connected and still in bind mode wold shake. This bug is 100% repeatable. however I think people thought was smoking grass . this is only on the mRo v2.1 FC and hardware.
could be why I messed up the logs today
I have encountered an Auto Mission event I can’t explain from the log. 3.6Rc3 Chibios. At a point during the mission it momentarily switches from Auto to Stabilize, drops in altitude (almost to the ground), then resumes the mission climbing to the proper altitude and completes the mission. It loses RC communication so there are radio failsafes but “Continue with Mission” is set in parameters. I’ll add that the mission speed is pretty fast but I see no other errors or reason for the problem. Any help would be appreciated, log attached.
I’ve had an initial look at the logs and it looks like the receiver is setup to pull the channel 5 switch low when it loses contact with the transmitter. Normally the best way to setup the failsafe in the receiver is so that it doesn’t send pulses at all when it loses contact. The next best approach is to pull the throttle channel (normally channel 3) low… but it’s never a good idea for the receiver failsafe to change the flight mode channel.
I’ll have a look at whether behaviour has changed vs 3.5.5 in this area in any case… I can certainly see that some of the code in this area of the code has changed.
The logs are very similar, although I can see a very small bit more rate noise on the ChibiOS build.
I notice you have MOT_PWM_TYPE=4, which is DShot150, but the motors are connected on the main outputs which don’t do DShot for either NuttX or ChibiOS.
Can you please try with either OneShot or (if your ESCs support it) OneShort125 ?
You could also try with MOT_PWM_TYPE=0, for plain old fixed period PWM.
Thanks for the review and I see what you mean from RCIN C5. I checked my Rx setup (Frsky XSR) and it is set for “No Pulses” but that doesn’t appear to be the case. I’ll look into this further.