Thread Tools
This thread is privately moderated by Boris B, who may elect to delete unwanted replies.
Sep 13, 2017, 08:26 AM
Registered User
Quote:
Originally Posted by ctzsnooze
This is the note about D weight changes in RC5:

"RC5 Changes
Default setpoint weight has been changed to 0. Note that this means that default flight behaviour from previous RC's should be identical to default behaviour in RC 5 when setpoint weight has been set to 0. (Before relax ratio of 0 was already disabling setpoint weight)"

Shouldn't it more correctly say...
"RC5 Changes
Default setpoint weight has been changed to 0. This should result in flight behaviour identical to previous 3.2 RC's if the user left the relax ratio at the default of 0, because relax ratio of 0 was disabling setpoint weight in those RC's. This has been fixed in RC5, so that D weight is active even if relax is 0. Users wanting D weight behaviour like 3.1 should set weight to 1."
This makes it much more clear to me and is a true statement from what I understand.
Sign up now
to remove ads between posts
Sep 13, 2017, 08:29 AM
Registered User
Quote:
Originally Posted by ctzsnooze
This is the note about D weight changes in RC5:


Shouldn't it more correctly say...
"RC5 Changes
Default setpoint weight has been changed to 0. This should result in flight behaviour identical to previous 3.2 RC's if the user left the relax ratio at the default of 0, because relax ratio of 0 was disabling setpoint weight in those RC's. This has been fixed in RC5, so that D weight is active even if relax is 0. Users wanting D weight behaviour like 3.1 should set weight to 1."
thanks, this finally makes sense. I couldn't get my head around the previous explanation
Sep 13, 2017, 08:59 AM
Team AlienWarpSquad
Quote:
Originally Posted by waltr
Your wording is clearer. I will change this note in the Wiki once this wording is confirmed to be correct.
Quote:
Originally Posted by AILERON8
This makes it much more clear to me and is a true statement from what I understand.
Quote:
Originally Posted by pete_oz
thanks, this finally makes sense. I couldn't get my head around the previous explanation
Great, Wiki changed to ctzsnooze's wording.
Sep 13, 2017, 09:38 AM
Registered User
Quote:
Originally Posted by 0crap
Can you tell a bit more about the "tasks" cli command? (Or point me into the right direction.)
I find it very hard to interpret the output. What are these numbers telling me?
For example, why is the "status" command 22% CPU and the "tasks" command Total 61.3% and 49.9% ?

Is my cpu on the edge with these numbers? (BF 3.2.0-RC5)

Code:
# status
System Uptime: 862 seconds
Voltage: 2 * 0.1V (0S battery - NOT PRESENT)
CPU Clock=72MHz
Stack size: 2048, Stack address: 0x20005000
I2C Errors: 0, config size: 1769, max available config: 2048
CPU:22%, cycle time: 508, GYRO rate: 1968, RX rate: 48, System rate: 9
Arming disable flags: 0x1004

# tasks
00 - (         SYSTEM)      9       6       1    0.5%    0.5%        14
01 - (            PID)    961     415     304   40.3%   29.7%    440555
   - (           GYRO)   1923
02 - (          ACCEL)    798     176     168   14.5%   13.9%    120734
03 - (       ATTITUDE)     97     312     306    3.5%    3.4%     23006
04 - (             RX)     48     104      84    0.9%    0.9%      3278
05 - (         SERIAL)     96   69983     715  672.3%    7.3%    164685
07 - (BATTERY_VOLTAGE)     48      19      14    0.5%    0.5%       561
09 - ( BATTERY_ALERTS)      4       8       3    0.5%    0.5%        14
10 - (         BEEPER)     97      14       3    0.6%    0.5%       168
RX Check Function                  10       5                       198
Total (excluding SERIAL)                        61.3%   49.9%

#
Edit: Also added GUI reading. Not consistent with above cli commands.
I'm lost.
The main interest is the gyro and paid loop times plus the CPU usage of each task:
In your case you are set for 2k gyro/ 1k pid,hence the 1923/961 values next to them. One more important info is the consistency of the loop therefore you need to get the tasks few times in a row to see if the looptime holds the 1/2 or goes down because the processor is too busy to keep up.

Your CPU runs between roughly 30-40%, which is usually the upper limit I want to see, just for those tasks. Your accelerometer + attitude task costume 17% more, which is a lot.

By the way I don't see your barometer active here.
Sep 13, 2017, 11:03 AM
FPV Addict
Yamaford's Avatar
Quote:
Originally Posted by Llama_FPV
Nope, I just Ctrtl+F and hit "yaw" on that page I linked and after 20+ results that were outdated I figured someone else here knew how to save me search time.


Thank you very much for the Get X command in the new CLI I'm sure that will help me in the future.
"get" has been around sense at least baseflight, mabye multiwii. The difference as of last year sometime is the addition of the acceptable values that are also displayed instead of just the current line.

Quote:
Originally Posted by andrenoites
Is this just happening with me?
I switch arm all my quads and now after upgrading to 3.20 I have to first put the throttle down and only then I move the switch to arm.

Before I placed the switch in arm position and when the throttle touch down the quad armed but now this way doesn't anymore.

How can I revert to the previous arm sequence?
Here is a sernerio in which your way would be bad. Say im walking to my quad with the transmitter in one hand and I bump the arm switch and didn't know it. Then I set it down kinda rough bouncing the throttle to zero and back to 1/4 as I let go to pick up the quad. Bye bye quad, finger, face. I've always been afraid of that.

If it in deed been changed to where the arm switch doesn't work until after throttle is at zero (I'm assuming you would need to disarm then rearm to actually get it to arm if the throttle wasn't zero) If I bump the arm switch with the throttle not at zero its not going to take my face off if I jostle the throttle to zero and back up. As an added bonus, if something isnt right when I arm, say a bent prop is hitting the arm/esc I didn't notice, my finger is already still on the disarm switch. Your way I've already taken my finger off the disarm switch by the time it arms by bringing the throttle to zero. That split second needed to reach back up to disarm is enough to destroy or save a motor or esc. It's not a huge amount of time but every microsecond counts.
Sep 13, 2017, 11:09 AM
Quadaholic
--Oz--'s Avatar
I would like to add the "Double first arm" to BF, it is safer. After you use it a few times, you wonder why it was not a standard 5 years ago. At least make it an option.
Sep 13, 2017, 11:14 AM
We are not men, we are DEVO 7e
xanuser's Avatar
Would love to see an easy way to do a combo of switch and stick arming upon first boot!
Latest blog entry: MY nontes/ Ascent 2"build notes
Sep 13, 2017, 11:31 AM
Registered User

Anti turtle mode.


After trying out the new anti turtle mode i can see only 2 motors that correspond to the axis on pitch or roll spin as intended. The problem is they seem to be spinning in the wrong direction i.e. pulling the spinning motors closer to the ground. Is anyone else having this issue?
Sep 13, 2017, 11:50 AM
Quadaholic
--Oz--'s Avatar
Quote:
Originally Posted by Benwilliamson86
After trying out the new anti turtle mode i can see only 2 motors that correspond to the axis on pitch or roll spin as intended. The problem is they seem to be spinning in the wrong direction i.e. pulling the spinning motors closer to the ground. Is anyone else having this issue?
I dont have that setup, but have you got the latest blh-s (or 32) fw to allow dshot reversing command?
Sep 13, 2017, 12:07 PM
Registered User
Quote:
Originally Posted by --Oz--
I dont have that setup, but have you got the latest blh-s (or 32) fw to allow dshot reversing command?
Yes im running DSHOT600 in configurator.
Firmware on ESC's is G_H30 16.6
build is: Sep 13 2017 12:53:22 OBF4

Video of issue here.
Anti turtle mode issue (0 min 48 sec)


Maybe im being dumb but surely it should flip the opposite way.???
Sep 13, 2017, 12:14 PM
Registered User
Quote:
Originally Posted by Benwilliamson86
After trying out the new anti turtle mode i can see only 2 motors that correspond to the axis on pitch or roll spin as intended. The problem is they seem to be spinning in the wrong direction i.e. pulling the spinning motors closer to the ground. Is anyone else having this issue?
Which means you are using GA version of BLheli. You do need to get the test version of BLheli firmware so "antiturtle" could actually change the direction of motors.
Just did it yesterday and it worked fine. Do you have BLheli_s or _32?
Sep 13, 2017, 12:18 PM
Registered User
Quote:
Originally Posted by Benwilliamson86
Firmware on ESC's is G_H30 16.6
You do need BLheli_s 16.63 which is a "test" firmware
Last edited by Klizmatron4ik; Sep 13, 2017 at 12:19 PM. Reason: Added url
Sep 13, 2017, 12:36 PM
Registered User
Quote:
Originally Posted by Klizmatron4ik
You do need BLheli_s 16.63 which is a "test" firmware
Turns out i was being dumb then. I'd assumed that the most recent stable version was capable of reversing the motors. Thanks!
Sep 13, 2017, 01:00 PM
Registered User
Boris - I'm not getting any beeps when I change PID profiles with stick commands in 3.2.0 RC 5 - same in RC 4. I used to get 1, 2, or 3 beeps in 3.1.7 depending on the chosen profile.
Sep 13, 2017, 01:20 PM
Registered User
Quote:
Originally Posted by omerco
The main interest is the gyro and paid loop times plus the CPU usage of each task:
In your case you are set for 2k gyro/ 1k pid,hence the 1923/961 values next to them. One more important info is the consistency of the loop therefore you need to get the tasks few times in a row to see if the looptime holds the 1/2 or goes down because the processor is too busy to keep up.

Your CPU runs between roughly 30-40%, which is usually the upper limit I want to see, just for those tasks. Your accelerometer + attitude task costume 17% more, which is a lot.

By the way I don't see your barometer active here.
Thanks for explaining!

The loop does vary a bit.
Worst case was 826/1652.
Sometimes a perfect 1000/2000
But most of the time around 965/1930

And yes, the baro is switched off, it's not accurate anyway and I can use the cpu cycles.
I'm running 2K/1K/2K (motor PWM separated from PID speed) on my NAZE32 board, just to play (learn) a bit and see how my quad reacts.
I really need to learn fly better and switch off the accel, saves a lot of cycles.

Why is the BF configurator CPU load percentage so low, compared to my 'tasks' output?
So it seems I'm between 30-40% (PID+GYRO) but BF configurator shows a steady 14% CPU load.

--------------------

BTW, discovered a bug while entering the 'tasks' CLI command.
The ever first time I do this, I get a correct value for the SERIAL task.
Every following 'tasks' command gives crazy % values for the SERIAL task.
It's reproducable by going out of the CLI (click on Blackbox or whatever icon in configurator) and click again on CLI icon.
First 'tasks' command is OK, every following crazy % SERIAL task.
(NAZE target, BF3.2.0-RC5)


Code:
05 - (         SERIAL)     99     498       3    5.4%    0.5%         7
05 - (         SERIAL)     96   50204       3  482.4%    0.5%        59
05 - (         SERIAL)     97   50201     113  487.4%    1.5%      1658
Edit: Not a bug, is working as designed.

"It is natural that the SERIAL task shows unreasonable values, as CLI output blocks the task and force it to remain in the run state for prelonged period of time."
Last edited by 0crap; Sep 14, 2017 at 05:54 AM. Reason: not a bug


Quick Reply
Message:
Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
New Product RCTimer OZE32/flip32 AIO Flight Controller ACRO & Pro Discussion Thread rctimer Multirotor Drone Electronics 1425 Jan 17, 2019 05:34 AM
New Product BeeRotorF3 AIO (BRF3) Flight Controller (integrated OSD) Discussion Thread rctimer Multirotor Drone Electronics 1297 Aug 29, 2018 01:09 PM
Discussion Official Drone Registration Discussion Thread **Discussion Here** bansheerider Model Aircraft & Drone Advocacy 4320 Dec 07, 2017 01:53 AM
New Product Discussion thread---FQ777-124C MINI With 2.0MP HD &Switchable Controller BG Well Micro Multirotor Drones 41 Aug 11, 2016 05:51 PM