MultiWii

doughboy

you will have to edit PL_PIN_ON and PL_PIN_OFF defines for it to work. using A2 will work as well. Make sure you modify the right PL_PIN define (under PROMINI). I think it my previous instructions, I forgot to add the step to configure the pin for output. So you may just need to add pinMode(9,OUTPUT...

doughboy

to use pin 9 instead of pin 8, look for these lines under PROMINI section in def.h #define PL_PIN_ON PORTB |= 1; #define PL_PIN_OFF PORTB &= ~1; and change to #define PL_PIN_ON PORTB |= (1<<1); #define PL_PIN_OFF PORTB &= ~(1>>1);

doughboy

Horizon is just angle, so it uses the same PID settings. You can tune in angle or horizon mode. But I think you should tune in horizon mode when hovering around, when moving forward, how the angle-correction acts when you release the sticks... this is incorrect and misleading information. read the ...

doughboy

ok, it seems all the description of horizon mode given above is actually angle mode + acrotrainer. According to the code, horizon mode uses a different PID calculation. This is the only difference between angle and horizon. horizon takes portion from acc and portion from gyro. there is no threshold....

doughboy

I must be missing something, if so, kindliy point it out. acrotrainer, adds a threshold so angle mode will switch to acro mode when sticks go past the threadhold. which is the same description given above for horizon mode, except the threshold is not tunable. so basically, angle mode + acrotrainer =...

doughboy

Horizon is basicly the same as Angle. The differense is In horizon mode The Pids for leveling is dynamic depending on stick input. At full throw it will behave almost as in acro mode. Kind of semi acrobatic. It's able to flip with large inputs and returns to level when sticks is centered. I only us...

doughboy

doughboy

doughboy

I use an Arduino UNO with LCD keypad shield loaded with LCD_Config sketch. It emulates TextStar LCD. Google search LCD_Config.

doughboy

in which cases do the problems occur?How come it that nobody reported it yet.I think if there is a bug, we should fix it and not circumvent it. Not all users are smart enough to circumvent this. I would apply the patch if it is save and tested. nils I evaluated this further, and so far, the only ot...

doughboy

I would not recommend this fix, imagine the surprise a user would get if they used trial and error to get the right mapping in config.h, then apply this fix then find out the stick function now are all different. My last suggested fix, although it looks drastic, is safer because users will be forced...

doughboy

jevermeister wrote:Hi,
has this been changed recently? I have no problems in <=2.1...

Nils

if you follow my explanation, you can see proof the code does not work for all cases, I used phenolics channel order as example. and the result is exactly what he found out, yaw and roll are reversed.

doughboy

another fix that is consistent with PWM code.

viewtopic.php?f=8&t=2756&p=26815#p26815

doughboy

another possible fix to make this more intuitive and easier to understand. This is consistent with PWM code, where ROLLPIN is defined and is assigned the pin number. in config.h //#define SERIAL_SUM_PPM //assign rx ppm channel number to function #define PPMROLL 3 #define PPMPITCH 2 #define PPMYAW 1 ...

doughboy

actually it is really convoluted. I tried a few more combinations and it does work as is for some but not for others. but a fix is needed to make it work for all.

see
viewtopic.php?f=8&t=2756&p=26812#p26812

doughboy

I tried a few more combination and the previous suggested fix won't work for other combination. like THROTTLE, YAW, PITCH, ROLL order I think that's why it works for some as is, but not for others. In the above sequence, the original code works as is. I think the actual fix should be to reverse the ...

doughboy

Its a little bit convoluted, but I can confirm this is a bug in multiwii code. phenolic is correct tthat the mapping is reversed. so lets say you defined SERIAL_SUM_PPM as YAW, PITCH, THROTTLE, ROLL (we'll just do the first 4 for simplicity) as your channel order. and rcChannel array is initialized ...

doughboy

Its a little bit convoluted, but I can confirm this is a bug in multiwii code. phenolic is correc tthat the mapping is reversed. so lets say you defined SERIAL_SUM_PPM as YAW, PITCH, THROTTLE, ROLL (we'll just do the first 4 for simplicity) as your channel order. and rcChannel array is initialized a...

doughboy

so if this worked for you #define SERIAL_SUM_PPM 3,1,0,2,AUX1,AUX2,AUX3,AUX4,8,9,10,11 that means your RX channel - function order is channel 0 is yaw channel 1 is pitch channel 2 is throttle channel 3 is roll hence in your first post you said you initially defined it as #define SERIAL_SUM_PPM ROLL,...

doughboy

or create a new enum as follow enum rxchannel { RXCHAN0,RXCHAN1,RXCHAN2,RXCHAN3,RXCHAN4,RXCHAN5,RXCHAN6,RXCHAN7}; then //map your RX channel order to MultiWii order //ROLL, PITCH, YAW, THROTTLE, AUX1, AUX2, AUX3, AUX4 //so if your actual channel order is chan0=throttle,chan1=pitch,chan2=roll,chan3=y...

doughboy

I see what you are saying. There are two channel orders here. 1. Multiwii channel order, defined as enum rc { ROLL, PITCH, YAW, THROTTLE, AUX1, AUX2, AUX3, AUX4 }; so ROLL is 0, PITCH is 1, YAW is 2 and THROTTLE is 3. in SERIAL_SUM_PPM , you assign the actual channel according to the above order so ...

doughboy

Also, remapping the channels on the TX does fix it. As far as I can tell something is wrong with the MultiWii code. I'm thinking the definitions do not match what they are called. In other words, ROLL isn't actually the roll channel, YAW isn't yaw, etc. I can guarantee you roll is roll and yaw is y...

doughboy

The mix order on er9x must match the order you specified in the define. If you are saying is you got it to work by simply rearranging the mix order, then I'd say you may have multiple defines in your config.h or made some inadvertent change in your code. It should not happen in stock code.

doughboy

If switching roll and yaw did not fix the problem, I highly doubt rearranging the mix will fix it. They do the same thing, it will rearrange the sequence of the pulse. You may try tweaking the timing on ppm sum pin interrupt handler. By default, a pulse gap >3000us will cause channel to reset to fi...

doughboy

I just edited my post.
You can change the ppm protocol setting in er9x, so you may want to try that first.

doughboy

If switching roll and yaw did not fix the problem, I highly doubt rearranging the mix will fix it. They do the same thing, it will rearrange the sequence of the pulse. You may try tweaking the timing on ppm sum pin interrupt handler. By default, a pulse gap >3000us will cause channel to reset to fir...

doughboy

got mine today

doughboy

Sorry but I know you we're exaggerating to point out my solution is inferior to another solution and I had to set the record straight since you we're giving misleading information with absolutely no technical basis but hearsay on a subject you seem to know very little about. I don't claim to know ev...

doughboy

It's a good idea to at least test compile a change (with the option enabled) before checking in. It is not the first time I encountered and reported this type of issue. I discovered this by accidentally checking out MultiWii instead of MultiWii_shared.

doughboy

Hamburger wrote:Howard posted an easier rig consisting of only a couple of diodes&transistor. Not sure whether that works with all rx but looked easy enough to try it out.

There you said a "only a couple of diodes".

That was quite a stretch from the truth.

doughboy

This is one of the references I used as basis on how I generated the output. (channel 8 is present but pulse is not shown in diagram) I also based the use of 300us ppm pulse width based on how open9x (and probably er9x) do the ppm protocol. the default ppm pulse width they use is 300us. It's basical...

doughboy

can someone fix MultiWii.ino in trunk (NOT shared).
it is missing a declare for variable static uint8_t AlarmArray[16];

see line 408 on shared MultiWii.ino

doughboy

Thank you Doughboy, I thought I read that but overlooked it when I went back looking for that. Lets just keep it simple, I will use the 8 mhz too. its not a big change. please try this. the wiring is in the comments #define PPMHI PORTD |= _BV(7); #define PPMLO PORTD &= ~_BV(7); //written by dou...

doughboy

How about with only 6ch receiver? Need modify the sketch to only using pb0 to pb6? or just leave ch6 & ch7 unconnected? no need to change the program, just leave 6 and 7 unconnected and it will work as it should. if you look at my logic analyzer capture, I only hooked up the 4 stick channels an...

doughboy

Question Dougboy, what would be the harm in using the Crystal or resonator and running running the 328 at 16 mhz verse 8 mhz? As I mentioned in the comment, the program as is will not work on circuit with oscillator. the program needs to be modified to work with cpu with oscillator. This is because...

doughboy

Please search for simple ppm sum in posts by howardhb. Multiple diodes one transistor. I found it and it is not two diodes and a transistor lol. I think It won't work if the pwm is perfectly aligned or overlaps since all it does is simply OR the pwm signals. It is counting on pwm signals having a s...

doughboy

the only possible difficulty I can think of for anyone trying this is the setting up of the cpu to run at 8mhz, meaning, burning the 8mhz bootloader which sets the fuses to the correct value. I used the atmega "breadboard" profile but modified the uploader to use usbasp and I uploaded the ...

doughboy

yes, failsafe kicks in if you turn off the transmitter.
if I am not mistaken, the "find me" alert works similar to failsafe (in terms of detecting the presence of RX signal), except it works when quad is not armed while failsafe works while quad is armed.

doughboy

Question, does the present code detect the lost of signal and past this on to the MWC to active FAILSAFE? how does it work for an actual ppm RX? does it skip the ppm pulse for the missing channel? if it is all or none (which I suspect it is), then this will work the same way. like if I turn off the...

doughboy

As long as the RX sends out PWM one right after another, then this will work. Even if the RX sends out PWM signal simultaneously, all that is needed here is a program change, as the program can detect all 8 pwm pulses and can serialize them to ppm. That was actually my first program, then I realized...

doughboy

I needed to use all 8 channels on my Turnigy RX but my 328 based FC can accept only 6 channels, so I added a circuit to convert the 8 channel PWM into a Serial Sum PPM signal. The circuit consists only of an atMega328 chip with a simple 20 line program. Chip is running using internal oscillator at 8...

doughboy

the not many people using is meant to answer your question why no one is interested in responding to this thread and has nothing to do with a bug getting fixed or not. which is along the same line as people not famiiar with the code will not respond. I'd follow hamburger's advice to contact and work...

doughboy

I don't think many people use this feature, but I can confirm what you are saying.
question with that change. if boxarm is not assigned to aux, can the quad still be armed via yaw?
I see the problem in arm and disarm. perhaps to simplify things, the boxarm option should just be removed?

doughboy

Level PDF is buggy. Search for one of my post asking for this option to be removed. Normal angle mode code works great.

doughboy

dramida wrote:An example of how Multiwii CAMSTAB works on roll-pitch axes i show here
http://www.youtube.com/watch?v=XbEjQSneakk

Thanks everyone for supporting me.

can you do a demo using aux3 and aux4 on potentiometer and using aux3 and aux4 to control gimbal pitch and roll?

doughboy

or if you verified your tilt is initialized to 0, then the other possible cause is if(abs(gyroADC[axis] - previousGyroADC[axis]) > 8) is always true. if this is really due to temp issue, adding a define to disable the fix does not really address the temp issue. the problem is still there. nobody is ...

doughboy

rebuilt the code again with the fix enabled and maybe reinitialize your eeprom just to make sure. the calibration should only take less than 1 second. if you are seeing it continue forever (led does not go off), then something is wrong with your setup. yes I have tested this thoroughly and I can sha...

doughboy

thanks for the clarification. I see how it works now.

doughboy

I always calibrate the gyros by combo before first start. my landing skid is vety wobbly so I have to wait for it to calm down. I changed the code.the function is now enclosed by a define. everyone is now happy. nils you can still do that even with the fix, no? imho, adding yet another define will ...

doughboy

I think this feature makes sense and should be left as it is. I think the main point is to get the gyro calibrated properly. if you remove this change, then the user will be worse off, plus its not like the issue you described will go away if this change is backed out. not saying the issue you descr...

Search found 252 matches