Agree with Randy, it is facing the center at the beginning right? Perhaps one way to manage this is if I use Circle, I also use that switch to reverse the direction of my pitch stick. Seems a hack, but, seems more intuitive use of the mode in the long run - and I’m actually pretty excited you’ve implemented this at all!
@andyp1per 's fixes relate to flash-based storage devices (essentially).
SD-card logging is not flash-based - and I’m assuming that’s what’s going on on the CubeBlack
can you give me your full param list? I’d like to try to reproduce this
please also give me a non-corrupt log from 4.0.0 from your board
First, thank you @Pedals2Paddles for your effort. This is a very powerful mode and am thankful to have it in my tool kit.
My use case is almost always pointing the camera or spotlight on the subject/area and then initiating circle mode. My thought was that by pulling the stick back I move away from the subject, and forward I am moving toward the subject all the while rotating around the subject, the center of the circle. Left/Right roll changes direction of the rotation including the ability to speed up or stop. In fact you could “arc” the subject (back and forth) as well.
I have successfully used circle mode on several SAR missions, but find a single direction/rate very limiting.
Here you go
CUBE_UAVCAN_X4_MYXA.param (18.2 KB)
2020-01-14 13-37-12.zip (793.3 KB)
ESC UAVCAN nodeID values are from 20 to 23.
Hi, I did never encounter the bug either but it’s there
And yes, copter 3.6.x did have a sub optimal frsky scheduler that would stall all telemetry while messages were being sent, version 4.x.x brought 2 big improvements: a dedicated thread for the frsky subsystem which solved many issues (but is the root cause of the potential race condition) and an improved frsky packet scheduler.
Thank you. I loaded your parameters onto a quad with 4 CAN ESCs but I can’t reproduce the issue. I’d appreciate it if you could try to narrow down the issue for us.
Can you please try disabling features progressively and see which feature is key to making the problem happen?
I know it will make it unflyable disabling many of these. All we’re trying to find is which ones affect log corruption.
Please also try a different microSD card.
Thanks, I am interested in the fixing of flash-based (block based) storage devices.
I have also put a firmware here for you to test:
this firmware is the same as 4.0.1rc1, but removes a patch that adds new CAN ESC logging. That is the most likely change to have caused an issue.
Thanks. I will test these later today or by latest tomorrow.
So I did some troubleshooting to narrow down the problem and here’s what I found:
- Log will corrupt if CAN_P2_DRIVER = 2, but works fine when it is set either 0 or 1 (4.0.1-test1.apj and on 4.0.1-rc2).
- Doing any changes to CAN_P2_DRIVER, will cause following messages (4.0.1-test1.apj and on 4.0.1-rc2):
15.1.2020 17:05:27 : PreArm: Internal errors (0x8000) 15.1.2020 17:05:27 : PreArm: Logging failed 15.1.2020 17:05:10 : AP_Logger: stuck thread ()
Log gets corrupted on both your 4.0.1-test1.apj and on 4.0.1-rc2
Downloading a log will cause following messages happen during/after (CAN_P2_DRIVER=ANY)
This happens on all ! AC 4.0.0 !, 4.0.1-test1.apj and on 4.0.1-rc2
15.1.2020 17:18:30 : PreArm: Internal errors (0x8000)
I was using otherwise same params as shared before. Only changes are on CAN_P2_DRIVER param.
Disabling other features didn’t help.
Hopefully this helps.
Can you tell me what devices you have attached to each CAN port?
a related question: what is the minimum set of attached devices to your board that is needed to reproduce the issue? I really want to reproduce the issue here to fix it and need to know what devices I need to attach. The key issue I’m looking for is the log corruption.
Currently there is 4x Myxa ESC on UAVCAN on P1 and no devices on P2. That’s all.
These are indexed for motors 1…4 and CAN nodeID’s are 20…23
Tomorrow I will try to minimize the setup to bare minimum where its still giving problems.
If you are using the full carrier board then are you aware that CAN1 and CAN2 labels are backwards on the case? Are your CAN devices connected to the connector in the center of the board (next to telem2) or on the right hand edge?
FYI the radius direction control has been swapped in master and will be included in Copter 4.0.2 when that rolls out.