Agreed… I’m just not sure I want to further complicate the aux channel selection yet. Somehow we will get it in an intuitive means.
I finished support for spi rx in the AlienwhoopZero target last night and it’s flying well. I used the little module taken out of the toy transmitter as my receiver. Currently using the clock pin for the 3rd radio wire. I think that will just be a draft for now and we might open a dedicated pad on the final board release.
Hi all,
is anyone succesfully building on linux?
I cloned a fresh copy of the github repo today and followed the linux installation instructions. I get stuck in the build phase due to the following error:
/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: bwhoop.elf section `.text' will not fit in region `FLASH'
/usr/lib/gcc/arm-none-eabi/5.4.1/../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 1460 bytes
collect2: error: ld returned 1 exit status
Makefile:52: recipe for target 'bwhoop.elf' failed
make: *** [bwhoop.elf] Error 1
Has anyone encountered this issue before (I’m on ubuntu)?
I wonder if compiling with gcc makes a bigger file. The f0 is close to full as is. Silver (I think) has mentioned that keil does a better job.
I know nothing about linux but maybe this link is useful, not sure:
https://simonernst.com/silverware/
@littlrussian The build is too big to fit into 16K of flash memory. That’s what the error is telling you.
Depending on the board you are trying to flash, you can increase the limit to 32K.
The easiest thing is probably disabling features in config.h until the build is under 16K.
@NotFastEnuf May I ask what this addition is in aid of;
#define ADC_REF 1.17857f , is it related to Alienwhoop Zero
Yeah, that’s a correction for the mcu voltage reference in the toys since they all run on a 2.8v regulator instead of 3v3. I had to create a variable and pull that coefficient into the target defines section since the alienwhoop zer0 is using a 5 volt buck feeding a 3v3 and needed a different reference voltage for adc calculations.
Speaking of the zer0… we are currently in our third major revision and the board just keeps getting better. I think this one will be only a few minor changes away from production. Also I have flown bayang spi receiver and frsky sbus back to back now and I can say that there is no noticeable latency penalty for sbus. It feels great which is good news.
On a side note … has anyone tried loading firmware using a ftdi over the uart pins when the f0 is in bootloader mode?? This could be a viable alternative to the dreaded st link woes.
http://www.st.com/en/development-tools/flasher-stm32.html
Looks like all we need the the correct option byte set for boot 1 and to pull boot 0 pin high during power up and we can just side load firmware right in through a uart. That should be either pins pa2 and pa3 or pa9 and pa10 i think???
hey NotFastEnuf,
(I’m 0a23cb7af4d242 on rcgroups)
first, congrats to your great fork! I tested it a bit and I’m really tempted to switch over to it for my h8 mini blue boards (great layout, defines for different boards, inclusion of joelucids yaw drift fix, features like torque boost etc. are definitely worth it), the only thing that prevents me from doing it atm is the airmode/idle up/arming/safety-topic, it seems that I can’t configure it the way I am used to. I never used betaflight which probably adds to my confusion.
I’m not sure if you are aware of the AIRMODE_HOLD_SWITCH-feature in silverware? It never made it into the bwhoop-branch, and I feel like I’m the only one who ever used it. As far as I understand, it is the same like your idle-up function, but a) it makes also sure that all motors stop when the configured channel is triggered and b) it is only activated after initial throttle has been given. Maybe it can help you figuring out how to prevent the props spin up when binding, I don’t know. I’m using it on all my silverware quads (H8S/H101, H8 mini green and blue boards) and mapped it to the throttle kill/hold-switch.
In addition, I’m using the “sticky throttle hold” on all my devo modelfiles like described here: https://www.deviationtx.com/forum/how-to/1953-how-to-create-a-sticky-throttle-hold . I think it is basically the same like your arming-function.
Now here is my confusion: when I’m mapping the arm and idle-up function to my hold-switch and toggling it, the props start spinning, regardless of the trottle position. It seems to me that idle-up overrides the arm safety function, also the sticky throttle hold is being ignored.
I really like your high-configurable approach, so I think that it might be even much better than AIRMODE_HOLD_SWITCH, but it seems that I can’t figure out how it is supposed to work. Do i need to map both functions to different channels when I don’t want the props to start immediately, or is there something wrong in my configuration?
Let me see if I can explain it all for you in a way that helps you understand. First let’s talk about arming. If you undefine (comment out) arming the quad will always be armed - just like stock silverware. With arming feature defined, any time you have the assigned aux channel in the low position - the motors can not spin up - no exceptions! If you toggle the aux channel assigned to arming high - and your throttle is above the throttle safety value - your throttle will be overridden to zero (motors dead) and the leds will rapid flash to indicate a safety condition. Dropping your throttle back below the safety limit will clear the flag on arming and motors will be live/led will stop blinking. Now what does live motors mean … well that depends on idle up. If you separate idle up and arming features … and idle up is off but you are armed… your props will not be spinning at zero throttle but they will as soon as you cross 5% throttle. If idle up is on… and you arm (with throttle stick below the safety limit)… props are going to spin at the throttle percent that you set for idle up - default is 5%. Also … mix increase throttle is what allows the fc to raise throttle as needed to individual motors when you’re in the air with the throttle stick down but needing more stabilization than 5% throttle gives you( like a building dive). But since that can be a little jumpy on the ground before taking off … there is another flag that requires a cycle from disarmed to armed and then for throttle to pass the safety value - this flag indicates you should be in the air. Mix increase can’t run unless you satisfy that flag. So it’s not active on the ground during pre takeoff. I suggest keeping arming and idle up linked together on channel 5 aux. This makes getting in the air easy. Props will spin as soon as you arm, mix increase will kick in right as you take off. Props will stop if you disarm. If you try to arm and throttle is too high - leds blink and motors don’t run.
Now, I have one safety bit left to code that I have not gotten around to. Consider the following scenario: your transmitter’s arm switch is left in the armed position and the throttle is all the way down - you have arming and idle up linked together on the same switch. You power up your quad and your tx… props are going to spin. Throttle safety check only checks to make sure your stick is below the limit. If it is below, it does not override throttle to zero. There is not currently a check to make sure you start disarmed. Which brings us to your setup…
Clear out all your mixers. Don’t over think it. Leave my aux channel assignments bat defaults and set up a simple switch on channel 5. Make sure the channel is going from high to low in your output monitor. It will behave properly. I think your tx must always have the arming aux channel output high. Which means as soon as I update the last safety check requiring you to be in a disarmed state at least once before arming can take place - you’re gonna be grounded with flashing leds… cause your tx is telling the quad to always be armed if your props are spinning no matter what. That’s is the only way that’s possible other than disabling arming completely while idle up is enabled. Hope that all helps. And you are right that these behaviors would all be more expected if you had flown betaflight. Once the last safety is in place it will be very similar
can someone explain how to adjust theese? i would like to smooth out or lower sensitvity on roll and pitch and yaw on auto level mode
#define ACRO_EXPO_ROLL 0.80
#define ACRO_EXPO_PITCH 0.80
#define ACRO_EXPO_YAW 0.60
#define ANGLE_EXPO_ROLL 0.55
#define ANGLE_EXPO_PITCH 0.0
#define ANGLE_EXPO_YAW 0.55
Just to update this topic, I started working on the last arming safety features tonight. I have it working on sbus. Basically that’s the block if your transmitter is armed when you bind. Requires a disarm to clear the flag. I’m gonna work on bayang protocols later this week then update it. I’ll probably drop a lot of the older protocols at rat time just to clean it up a bit.
Unrelated… I’m also gonna restore my old angle pids. I know a few of you guys are flying the new angle pids and like them … but I don’t know how the heck you do. I think it feels terrible. Lol. So angle pids will be presented like rate pids… my favorite settings will be the default … but there will be other settings saved there that you can uncomment to change feel to know good values without having to guess.
@Whoopingtits Well there are a few settings you can adjust for auto level mode.
ANGLE_EXPO_ROLL, PITCH, and YAW would be one of them. Increasing these values closer to 1.0 will make the sticks less sensitive near center stick only.
You could also change MAX_ANGLE_HI from 70f down to 55f. This wouldlower the max bank angle down to 55 degrees.
You could assign low rates to an aux channel and change the low rate multiplier value to be any fraction of high rates that you choose.
BUT. … my personal suggestion would be to open the angle pids document and change the kp value from 13 down to 7 … and change the kd value from 5 down to 0. I was peer pressured into changing these settings and I personally hate them. Lol. They don’t feel smooth to me … so I’d suggest you start there. These values change the leveling strength and I feel like they are way too twitchy. Or you could just wait a day or two and check in here … cause I’m gonna change the defaults back to my old settings. I’ll announce it here when I do and you could download a new copy and flash it then.
Thanks for your detailed reply, I seem to slowly understand what is actually happening. I started with an empty model file as you said and the arming feature started to working, I couldn’t see the LEDs blinking before with the sticky throttle hold. I also wouldn’t have expected that with idle-up the props start to spin when going below the 5% limit, I thought they would when going above it (or when crossing this mark again), so it explains why the props start to spin immediately when using sticky throttle hold instead of the arming feature. I also realized that the sticky throttle hold is actually working in a sense that the props are spinning very mild until the minimum of the throttle curve is reached, at least when the quad is on the ground (during my initial tests I held the quad tight between my fingers and it felt like full throttle, so I thought the sticky throttle hold isn’t working at all). I’m still puzzling why the arming feature doesn’t work in conjunction with the sticky throttle hold, but maybe it will after the last safety features are implemented.
Thanks again
Sticky throttle hold is bypassing the internal safeties. Those safeties look for a signal of a low throttle and clear flags based on if you are sending a low throttle signal. That is exactly what sticky throttle is doing - sending a low safe throttle. I do see strange behavior when throttle commands outside of the normal range are sent that I do not understand yet. Sticky throttle also does this. I do not recommend sending commands to the fc that are outside the normal range until I know why that happens.
5/9/18 UPDATE: I just pushed up changes to update the last arming safety feature. PLEASE TEST WITH CAUTION!!! Expected behavior if arming feature is enabled - AND - you attempt to bind while your transmitter is ARMED -------> should override throttle to 0 and rapid blink the leds till you disarm to clear the flag. That’s the last safety feature on my list. No longer can you connect up accidentally already armed and have props spin by surprise. I will add this - if you have already bound to your quad - and you toggle your radio on and off - this safety will allow you to link back up in an armed state and have props spin. That is intentional and purely just my preference.
There are alot of protocols that all behave slightly differently during the bind process. I tried to test this as thoroughly as possible before pushing up this change. If you by any chance uncover a particular scenario where you power up your transmitter in an armed state and props DO SPIN - PLEASE PLEASE make note of as many details as possible and safely (I stress safely) try to recreate the scenario so I know how to test it. It really took me some time to try to get all the possible scenarios and combinations cleared up but I think I got it.
ALSO: I updated one of the 6mm whoop pid sets (the Team Alienwhoop Pids), I changed my angle pids (leveling strength) back to my personal preferences, I lowered my rates a bit from recent defaults, and finally the biggie:
Happy testing
Oh yeah … ONE MORE THING!!
I added a new feature to check your stick throws and make sure you are reaching exactly 100% at endpoints. The feature is called #define STICK_TRAVEL_CHECK. When you enable this feature - it will take over that old stick gesture auxiliary channel. You know the RIGHT-RIGHT-DOWN and LEFT-LEFT-DOWN one…
So here is what to expect with it turned on - RIGHT-RIGHT-DOWN will disable throttle and rapid blink the led if you move your sticks to 100% in any direction. If you don’t get a blink - scale up your throws in your TX till you do. If you do get a blink, consider scaling down just a bit to see if the blink goes away - then scale it back.
There are so many multiprotocol modules now, and with the ALIENWHOOP ZER0 being focused on SBUS receivers, and with plans hopefully to support DSMX soon - you just gotta wonder if your sticks are actually reaching the endpoints. I came about this conclusion after moving to SBUS on FRSKY myself and found I was under rotating my rolls. So I wrote the code and sure enough I needed to scale up my sticks about 5% in my transmitter. Anyway, once your done you can use RIGHT-RIGHT-DOWN to go back to regular flying or can reflash again with the stick check disabled.
OK…Happy Testing
Can these features be disabled if needed? Can be mix_increase_throttle_3 be continue to be used without this?
Without what? Without being 100% or without waiting to kick in till youve taken off? You can change it back to 20% authority by uncommenting the strength define. As for the safety features … they are all hard linked to the arming feature. What exactly would you not want to have out of these changes?
I’m not sure there is a scenario where any of the safety features need to be disabled - at least I cant imagine one.
All three of these are condidered set in stone standards in every other major firmware.
As in this stuff doesn’t impact on mix_increase_thrttle_3 if safety isn’t defined. Sorry, early morning/lack of sleep for me not being clear
Having trouble with setting up the channels. I have a E011C board, and flashed it with these settings:
RX_BAYANG_PROTOCOL_TELEMETRY_AUTOBIND
ARMING CHAN_5
LEVELMODE CHAN_6
RACEMODE CHAN_7
HORIZON CHAN_8
I have a Taranis Q X7 with the chap Banggood multimodule:
https://banggood.app.link/GvwgAzNYNM
However none of the defines switches are working. Only when I flip the switch that is mapped to channel 6, the motors start to spin and I can fly in acro mode. Al the other switches I defined seem tot do nothing: No arming switch, no level mode.
Could the multoprotocol module I use be the cause of the problems, or is it just my brain that gives me trouble?