General servo handler - almost done

PatrikE · Post by **PatrikE** » Wed May 15, 2013 8:27 pm

MWiiConfig with servosettings uploaded in _shared.

For those who want to testrun The gui before next dev.
MultiWiiConf.zip
Use together with r1440 or newer.

Save servosettings to a file.
Copy/paste to config.h to load as default at reset.

Heli 90.
Dual & singleCoters Is not supported yet!

nhadrian · Post by **nhadrian** » Wed May 15, 2013 8:45 pm

PatrikE wrote:MWiiConfig with servosettings uploaded in _shared.

For those who want to testrun The gui before next dev.
MultiWiiConf.zip
Use together with r1440 or newer.

Save servosettings to a file.
Copy/paste to config.h to load as default at reset.

Heli 90.
Dual & singleCoters Is not supported yet!

Hi,

could you enable Servo settings tab when Tricopter or Camstab presents?
Generaly that would be great to have servo settings in every case any servo presents...
Thanks in advance.

BR
Adrian

PatrikE · Post by **PatrikE** » Wed May 15, 2013 8:57 pm

The servoTab should be enabled for all models with servo and gimbals on any copter.
Tri is Fixed for both to work with both servoalternatives.

Test and report back if there's any problems.

/Patrik

Mis · Post by **Mis** » Wed May 15, 2013 9:28 pm

I think that serial communication is too fast. I must click several times on "Read" button for get BOX'es and enabling servo TAB.
And, the servo tab implementation is only partial. You must add an way to setting "servo middle value" for using RC channel as source of middle position.
In this case the servo middle value should be 0 for "ROLL" channel, 1 for "PITCH" channel. ... ,4 for "AUX1" channel, and up to 11 for "AUX8" channel (on 12CH PPM receivers).
And, on GIMBAL settings, you forgot CAMTRIG servo settings.
But camtrig setup have middle value used in different way.
Setup middle value for camtrig servo in range 0..11 enable camtrig interval control from RC channel (like middle point of others servos).
Setup it above 1000 generate camtrig interval in miliseconds, and should have MAX value about 30000 (not 2000 like others servos).

Alexinparis · Post by **Alexinparis** » Fri May 17, 2013 5:25 pm

Hi,

I see many things in r1440 and r1441 I'm not agree with:

- reintroduction of MSP_SET_MISC_CONF : no, I suppressed and merged it with MSP_SET_CONF it in r1418.

- some special tricks to indicate the servo usage depending on hardware: no, I said no dependency with hardware to identify right servo id
(see conf.servoConf[5].middle = 0) .

- modification of MSP_STATUS message including DYNBAL in sensor status: no, dynbal has nothing to do with sensor. capability variable sounds good for this.
globally, I'm still not ok with the way DYNBAL is working. It should be independant of RCSERIAL.

- armingTimer tricks to simulate aarming yaw sticks and arming: no. the clean way is to send directly motor or channel values, not to simulate sticks input.

- removal of variable length indication in GUI MSP_MISC: I don't understand why, it was an indication for ezio requesting this info

- modification of timing request:
there is a problem with time4 (twice used), values are added twices and exclusion request (! toggle) are are not protected. that's explain the problem MIS mentionned
(failled to read conf because of congestion)
there is a problem with time7
I don't see any reason to exclude MSP_RC in some situation: it just complexifies everything. same for toggleRead and requests depending on active tab

other things seems in the good direction

Hamburger · Post by **Hamburger** » Sat May 18, 2013 9:32 am

again some hours wasted to find a horrible copyNpaste error that breaks the
lcd_param_ptr_table structure, making the config.menu unusable:

Code: Select all

- &lcd_param_text38, &conf.servoConf[TRI_SERVO-1].middle, &__SE, &__SE,
+ &lcd_param_text38, &conf.servoConf[TRI_SERVO-1].middle, &__SE,

bummer

Hamburger · Post by **Hamburger** » Sat May 18, 2013 10:28 am

Code: Select all

328p     m32u4     2560    | type                       
---------------------------------------
   .       .        .      | Gimbal
   .       .        .      | BI
  ok      .        .      | TRI // hamburger-r1444
   .       .        .      | FlyingW
   .       .        .      | Airplane
   .       .        .      | singlecopter
   .       .        .      | dualcopter
   .       .        .      | heli90
   .       .        .      | heli90+yawmotor
   .       .        .      | heli120
   .       .        .      | heli120+throttleservo

Mis · Post by **Mis** » Sat May 18, 2013 1:03 pm

Problems with different hardware solved. From r1445 the servo[0] is always CamPitch, servo[1] is always CamRoll, and tri servo is always servo[5].
On special cases like MEGA_HW_PWM or A0_A1_PIN_HEX, the outpust is moved to desired pins, but for GUI and other config are still the same.
To other developers: DO NOT remove the TRI_SERVO definition from def.h. This is needed for propper servo sorts.

Hamburger · Post by **Hamburger** » Sat May 18, 2013 1:17 pm

@Mis,
that sounds like your last change could have made servo handling easier again.
Only thing is it has become confusing. Can you please write a summary of the servo stuff (or compile from what you have written in previous posts) ?
It should describe the current mappings and mark changes to prior MWii versions
- servo-nr <-> pin used for each mcu type
- servo-nrs used for the coptertypes ( some changed to prior existing versions and pictograms, right? )

and if neccessary mention possible conflicts - but you put some effort to resolve conflicts, so maybe there are none.

Mis · Post by **Mis** » Sat May 18, 2013 3:48 pm

Current servos assignment (servos numbers from 1 to 8)
All models:
Servo1 - Camera Pitch
Servo2 - Camera Roll
Servo3 - Camera Trigger or Traditional flaps on Airplane
On SERVO_MIX_TILT setting, servo1 and servo2 are mixed for gimbal control
BI:
Servo5 - Left wing
Servo6 - Right wing
TRI:
Servo6 - Rear servo
Flying Wing:
Servo4 - Wing Left
Servo5 - Wing Right
Servo8 - Motor (if no Motor1 output is used for motor)
Airplane:
Servo4 - Left Aileron
Servo5 - Right Aileron
Servo6 - Rudder
Servo7 - Elevator
Servo8 - Motor (if no Motor1 output is used for motor)
Single Copter:
Servo4 - Left side
Servo5 - Right side
Servo6 - Front
Servo7 - Rear
Dual Copter:
Servo5 - Pitch servo
Servo6 - Roll servo
Heli90:
Servo4 - Pitch
Servo5 - Roll
Servo6 - Yaw servo
Servo7 - Collective
Servo8 - Motor (if no Motor1 output is used for motor)
Heli120 CCPM:
Servo4 - Pitch CCPM
Servo5 - Left CCPM
Servo6 - Yaw servo
Servo7 - Right CCPM
Servo8 - Motor (if no Motor1 output is used for motor)

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

SERVO PINS (from Servo1 to Servo8):
Mega Boards : (34 and 44),(35 and 45),(33 and 46),37,6,2,5,3
Mega Boards with MEGA_HW_PWM_SERVOS : 44.45.46.11,12,6,7,8
On MEGA with MEGA_HW_PWM_SERVOS selected, the TRI servo is at pin 11
On MEGA with MEGA_HW_PWM_SERVOS selected, we can use simultanously:
-Motor1,Motor2 and all 8 Servos OR
-All 8 motors and Servo1-5
On MEGA with MEGA_HW_PWM_SERVOS we can use heli YAW motor on Motor2 output. BUT ONLY IN THIS CASE!.

Promini (328p) : A0,A1,A2,12,11,3,10,9
On HEXA with A0_A1_PIN_HEX selected, the gimbal Pith and Roll servos are on pins 12 and 11.

Promicro (32u4) : A0,A1,A2,(4 or A3),5,6,10,9
I not have more info for 32u4 boards...

PatrikE · Post by **PatrikE** » Wed May 22, 2013 2:47 pm

I committed a new Gui to _shared with all models included.
NonProcessing folks can find compiled it here.
MultiWiiConf.zip

Servo center sliders have Dual Ranges.
Pull slider to min and it will change to Roll,Nick....... AUX8
Pull slider to Max and it will change to CenterPos ~1500

ServoCenter.png: (7.93 KiB) Not downloaded yet

There's a function to save the servosettings to file and copy to Config.h.

ServoCenter.png: (7.93 KiB) Not downloaded yet

Hope this makes sense...

Please test.
/Patrik

Edit
Removed SeriaRC info

Hamburger · Post by **Hamburger** » Fri May 31, 2013 9:13 am

coptertype heli_120 with 4 servos works on both 328p and m32u4. (no more destroyed servos, adjusting via GUI seems to work too, handheld pid-tuning/flying ok)

One thing I could not resolve:
servos of different brands may move in opposite directions; in those cases one has to invert the values for that servo (e.g. NICK_SERVO) to reverse the heli.pidmix. This cannot currently be done via GUI / force.servo.rates ?

PatrikE · Post by **PatrikE** » Fri May 31, 2013 4:25 pm

Code: Select all

    /* Servo mixing for heli 120
                         {Coll,Nick,Roll} */
    #define SERVO_NICK   { +10, -10,  0 }
    #define SERVO_LEFT   { +10, +5, +10 } 
    #define SERVO_RIGHT  { +10, +5, -10 }

Nine values is kind of hard to fit in three rates from gui.

If we have the table like this in config.
Only Positive Values.
{ 10, 10, 0 }
{ 10, 5, 10 }
{ 10, 5, 10 }
And change directions from gui could work.

But to have the Mixtable in gui
would mean adding a new msp for the mixer i think.

Hamburger · Post by **Hamburger** » Fri May 31, 2013 4:42 pm

PatrikE wrote:

Code: Select all

    /* Servo mixing for heli 120
                         {Coll,Nick,Roll} */
    #define SERVO_NICK   { +10, -10,  0 }
    #define SERVO_LEFT   { +10, +5, +10 } 
    #define SERVO_RIGHT  { +10, +5, -10 }

Nine values is kind of hard to fit in three rates from gui.
.

No. For this other type of servo all three signs of nick.servo would have to be changed together. That should be possible to fit in in the servo.rates array. I can do the mwii part easily myself but not the gui. I do the mwii part next week and you take the gui part please?

PatrikE · Post by **PatrikE** » Fri May 31, 2013 4:52 pm

Every servo need three revese bits.
FlyingWing & BI uses 2 bits We just need to extend it to use 3 bits.
(SERVODIR(x,1)
(SERVODIR(x,2)
(SERVODIR(x,3)

I'll be in India next week and can't ...
But if you fix the mwii part i can fix Gui when i get back.

Hamburger · Post by **Hamburger** » Fri May 31, 2013 4:56 pm

Ok cool.
I will try next week.

polo_fly2 · Post by **polo_fly2** » Tue Jun 04, 2013 10:55 am

Hello,

I just have installed the shared dev_1457 on a new tri with a 32u4 (nanowii). In combination with the
last zipped GUI from PatrikE everything seems to work fine. A short flighttest was just as I like it.

But one thing I do not understand: Why does the tailservo jitter during the initialisation process that much.
It seems to me that this exercise is very uncomfortable for the health of the servos, and decided to install a dip switch
on the signal wire of the servo. So I can wait untill initialisation finishes, than I can switch on the tail servo function and fly.

is there any another (software) way to avoid this jittering ? Maybe somone can help me .

Thank you
Georg

PatrikE · Post by **PatrikE** » Tue Jun 04, 2013 11:05 am

Earlier the servos was centered at initialization. Mary somthing changed lately.

polo_fly2 · Post by **polo_fly2** » Tue Jun 04, 2013 11:25 am

I cannot remeber that it was jitterfree before. On all tris I have built , (since mwi 2.0) it was always there.
Btw. The new GUI is great improvement for adjusting the servo travel and midpoint, without recompiling and uploading
the whole software again and again. Thank you :-)

georg

Hamburger · Post by **Hamburger** » Tue Jun 04, 2013 2:36 pm

servo jitter upon startup seems to be related to arduino hardware/firmware initialization. If correct, then nothing to be done about that

copterrichie · Post by **copterrichie** » Tue Jun 04, 2013 2:55 pm

Hamburger wrote:servo jitter upon startup seems to be related to arduino hardware/firmware initialization. If correct, then nothing to be done about that

This is the very reason, I power up the Arduino/sensors prior to any of the Servos/ESCs. Much clearer and safer in my opinion.

polo_fly2 · Post by **polo_fly2** » Tue Jun 04, 2013 6:03 pm

Hi Copterritchie,

.. so do you have a separate 5V powersource for the arduino ?

copterrichie · Post by **copterrichie** » Tue Jun 04, 2013 6:17 pm

polo_fly2 wrote:Hi Copterritchie,

.. so do you have a separate 5V powersource for the arduino ?

No, I used the Battery's Balance plug to power a UBEC and that powers the electronics. Another hidden advantage by using the balance plug is, the voltage is much cleaner.

polo_fly2 · Post by **polo_fly2** » Tue Jun 04, 2013 6:31 pm

hey,

that sounds perfect clever and simple ... thank you a lot :-)

Georg

Hamburger · Post by **Hamburger** » Thu Jun 06, 2013 12:03 am

PatrikE wrote:Every servo need three revese bits.
But if you fix the mwii part i can fix Gui when i get back.

I have a version that seems to work as expected. I would rather test it some more and downside is it takes an additional 420 bytes. That is because of helipidmix the SERVODIR macro gets invoked 4 times per servo, so 12 times for swash. I even tried a servodir() function which was even worse.
Also, this gets executed every cycle, while it could be computed once into left_servo[], right_servo[], nick_servo[]. Not sure if that is worth the trouble and possible confusion? Rather stick with the way the mixing and direction/rate gets done for other coptertypes and do it late and in place?

Hamburger · Post by **Hamburger** » Sat Jun 08, 2013 11:20 am

@Patrik
in r1460 you will find the swash mixing with inverting via the rate variables like you suggested. I use bit2 for Collective, bit1 is nick, bit0 is roll.
To reduce re-computation, I reformatted the helipidmix macro at the last moment - that is not tested, sorry, running out of time.
The lcd.configuration for servo inversion is in the code now too, not really tested, but hopefully non-critical.

PatrikE · Post by **PatrikE** » Sat Jun 08, 2013 1:19 pm

Hamburger wrote:@Patrik
in r1460 you will find the swash mixing with inverting via the rate variables like you suggested. I use bit2 for Collective, bit1 is nick, bit0 is roll.
To reduce re-computation, I reformatted the helipidmix macro at the last moment - that is not tested, sorry, running out of time.
The lcd.configuration for servo inversion is in the code now too, not really tested, but hopefully non-critical.

Great I'm back at home and can check it out during the week.

PatrikE · Post by **PatrikE** » Sun Jun 09, 2013 4:05 pm

I use bit2 for Collective, bit1 is nick, bit0 is roll.

Actually you use Bit 3,1,& 0..

I was puzzeld before i noticed it!... :?:

I have uploaded to MultiWiiConf_shared

Use the Export function to add the Default values in config after setup is ready.

Maby we could remove the signs in this table as it's also set in FORCE_SERVO_RATES.

Code: Select all

    #define SERVO_NICK   { +10, -10,  0 }
    #define SERVO_LEFT   { +10, +5, +10 }
    #define SERVO_RIGHT  { +10, +5, -10 }

Hamburger · Post by **Hamburger** » Sun Jun 09, 2013 7:32 pm

PatrikE wrote:
I use bit2 for Collective, bit1 is nick, bit0 is roll.

Actually you use Bit 3,1,& 0..
I was puzzeld before i noticed it!...

Are you sure? That tells me I know even less about bit manipulation than I thought.

Code: Select all

  #define SERVODIR(n,b) ((conf.servoConf[n].rate & b) ? -1 : 1)

The macro uses on a signed var 'v & b' (but not 'v & (1<<b)'). I thought v & b would require b=1 for bit0, b=2 for bit1, b=4 for bit2, b=8 for bit3 etc.?

Well, to correct my mistake, then what should the code look like to use bits 2, 1, 0 , instead of my

Code: Select all

      servo[3]  =  HeliXPIDMIX( ( SERVODIR(3,4) * nickMix[0]), SERVODIR(3,2) * nickMix[1], SERVODIR(3,1) * nickMix[2]);   //    NICK  servo

PatrikE · Post by **PatrikE** » Sun Jun 09, 2013 7:55 pm

Change servodir(3,4) to (3,3) To use bit 2
If you do that I'll need to adjust guide accordingly.
It works as it is now.

I can't swear I'm correct but it seem like that.
Mary some one can give a correct explanation?

Edit.
After some checking i think you are Correct my friend.
Leave the code as it is.

Hamburger · Post by **Hamburger** » Thu Jun 13, 2013 11:53 am

New HW PWM servos for 32u4 mcu - WARNING remapped servo <-> pin assignment

/* HW PWM Servo outputs for 32u4 NanoWii, MicroWii etc. - works with either the variable SERVO_RFR_RATE or
* one of the 3 fixed servo.refresh.rates *
* Tested only for heli_120, i.e. 1 motor + 4 servos, moves..
* motor[0] = pin 6 = motor
* servo[3] = pin 5 = nick servo
* servo[4] = pin 10 = left servo
* servo[5] = pin 11 = yaw servo
* servo[6] = pin 9 = right servo
*/
//#define A32U4_4_HW_PWM_SERVOS

mgros · Post by **mgros** » Tue Jul 02, 2013 8:12 pm

I'm using r1504 compilation in a HEX6X with GIMBAL
I'm using too, the last MultiwiiConf (r1504) and i have a problem to set GIMBAL Servo Rates using MultiwiiConf.
No matter what values change in GUI that when i WRITE it in EEPROM it seems that MultiwiiConf save 0 in both variables. (no more gimbal movement) and no READ original values in any cases.

In order to configure correctly gimbal i need to use "ServoMiscConf.exe" (Mis application) this application Works perfectly.

Any one has noted this problem?
There is a way to solve the problem and use MultiwiiConf ?

Thank in advance for your help.

Mariano.

PatrikE · Post by **PatrikE** » Wed Jul 03, 2013 7:48 pm

Fixed.
Test r1513.
Thanks for the find.
/Patrik

mgros · Post by **mgros** » Wed Jul 03, 2013 8:23 pm

PatrikE wrote:Fixed.
Test r1513.
Thanks for the find.
/Patrik

Perfect, thanks a lot!!

Sebbi · Post by **Sebbi** » Mon Jul 15, 2013 7:31 pm

Hello there,

setting up a gimbal was never easy, but with the new code ... well it took me a while to understand the options. Is this documented somewhere? Comments in config.h should mention that you have to set the first two SERVO_MID values to AUXx and AUXy if you want to control the gimbal via AUX channels (I know it is GUI setable, but I like to keep a config_me.h with all my settings). Bonus points if SERVO_MIX_TILT and SERVO_TILT differences would be explained in comments, too.

Thank you and great work.

Alexinparis · Post by **Alexinparis** » Mon Jul 15, 2013 11:16 pm

Sebbi wrote:Hello there,

setting up a gimbal was never easy, but with the new code ... well it took me a while to understand the options. Is this documented somewhere? Comments in config.h should mention that you have to set the first two SERVO_MID values to AUXx and AUXy if you want to control the gimbal via AUX channels

I think for the moment everything is described in this thread and a little bit scattered, right.

I know it is GUI setable, but I like to keep a config_me.h with all my settings

So now we can set everything in GUI, and in a very configurable way, you ask for config.h compatibility

I think it should be solved via load/save in the GUI instead (still to develop)

PatrikE · Post by **PatrikE** » Tue Jul 16, 2013 8:16 am

You can use the savve to file button in gui to get the servosettings table to paste in config.h

Sebbi · Post by **Sebbi** » Tue Jul 16, 2013 2:56 pm

Aren't the initial values read from what I set in config.h? As long as something needs to be configured there, I'd like to be able to configure everything (the default values that get set when clicking on "reset") there, so I don't have two place to look for configurations when moving to a new MultiWii version. That's still the case, just some documentation missing ;-)

gektor · Post by **gektor** » Thu Jul 18, 2013 7:28 pm

Hello Servo Programmers!

First of all, I would like to express that the Idea of implementing all the servos in one place and allowing GUI Configuration for the Servos is great!

I'm trying to configure my Tricopter which has Crius AIOP 2.0 Board (Arduino Mega 2560) with the newest dev. Release: MultiWii_dev_2013_07_15_r1539.

First of all, I was surprised, that the Servo Pin was changed from Pin 2 (MultiWii 2.2) to Pin 11. Well, It's fine. But why can't I set the Servo Min-Max Values at all? I've tried to set them in the config.h and in the GUI as well. The GUI Reverse functionality works fine, by the way.

I've set the PID handler to AlexK Mode:

Code: Select all

    /* choose one of the alternate PID control algorithms
     * 1 = evolved oldschool algorithm (similar to v2.2)
     * 2 = new experimental algorithm from Alex Khoroshko http://www.multiwii.com/forum/viewtopic.php?f=8&t=3671&start=10#p37387
     * */
    #define PID_CONTROLLER 2

Does it affect the new Servo Implementation somehow?

In order to try out the Servo Min-Max Setting, I've set them to the following extreme Values in the config.h

Code: Select all

    #define  SERVO_MIN  {1400, 1400, 1400, 1400, 1400, 1400, 1400, 1400}
     #define  SERVO_MAX  {1600, 1600, 1600, 1600, 1600, 1600, 1600, 1600}
     #define  SERVO_MID  {1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500} // (*)
     #define  FORCE_SERVO_RATES  {30, 30, 100, 1, 100, 100, 100, 100} // 0 = normal, 1= reverse

And still, the Servo on my Tri goes all the way round. Which is too much.

In the MultiWii 2.2 I had the following settings, which worked fine:

Code: Select all

  /********************************    TRI    *********************************/
    #define YAW_DIRECTION -1
    //#define YAW_DIRECTION -1 // if you want to reverse the yaw correction direction
    /* you can change the tricopter servo travel here... war 1020 und 2000 */
      #define TRI_YAW_CONSTRAINT_MIN 1200
      #define TRI_YAW_CONSTRAINT_MAX 1800
      #define TRI_YAW_MIDDLE 1500 // (*) tail servo center pos. - use this for initial trim; later trim midpoint via LCD

How can I change the travel Rate with the new Servo Implementation? Is it a bug, or am I doing it completely wrong? :roll:

PatrikE · Post by **PatrikE** » Thu Jul 18, 2013 8:08 pm

I think it's a bug in MEGA_HW_PWM_SERVOS on TRI!
MAx and Min seems to be ignored in output.
Try to disable MEGA_HW_PWM_SERVOS and run the Yawservo on original pin.

gektor · Post by **gektor** » Thu Jul 18, 2013 9:21 pm

Thank you for the fast reply, PatrikE!

I've disabled the Hardware PWM:

Code: Select all

    //#define MEGA_HW_PWM_SERVOS

And well, it works!

Thank you so much!

The Yaw Servo is now indeed at Pin 2, as it was before.

And I can change my Servo Min-Max Settings, even using the GUI - sweet! 8-)

Now that we've found a bug (no Servo Min-Max effect at Arduino Mega i.e. Crius AIOP2 when using HW-PWM in TRI-Mode): Who can localize it in the code and try to fix it? :mrgreen:

Hamburger · Post by **Hamburger** » Thu Jul 18, 2013 11:32 pm

I think it works for me. Will need to check later.

Alexinparis · Post by **Alexinparis** » Thu Jul 18, 2013 11:33 pm

Hi,

It should be corrected in last rev.
It was a wrong mix with GUI and FC sketch about TRI servo number.
The GUI is now unaware of the internal servo numbering for tricopter.
It is always 5 as it should have been coded before.

gektor wrote:Hello Servo Programmers!

First of all, I would like to express that the Idea of implementing all the servos in one place and allowing GUI Configuration for the Servos is great!

I'm trying to configure my Tricopter which has Crius AIOP 2.0 Board (Arduino Mega 2560) with the newest dev. Release: MultiWii_dev_2013_07_15_r1539.

First of all, I was surprised, that the Servo Pin was changed from Pin 2 (MultiWii 2.2) to Pin 11. Well, It's fine. But why can't I set the Servo Min-Max Values at all? I've tried to set them in the config.h and in the GUI as well. The GUI Reverse functionality works fine, by the way.

I've set the PID handler to AlexK Mode:
Code: Select all
    /* choose one of the alternate PID control algorithms
     * 1 = evolved oldschool algorithm (similar to v2.2)
     * 2 = new experimental algorithm from Alex Khoroshko http://www.multiwii.com/forum/viewtopic.php?f=8&t=3671&start=10#p37387
     * */
    #define PID_CONTROLLER 2
Does it affect the new Servo Implementation somehow?

In order to try out the Servo Min-Max Setting, I've set them to the following extreme Values in the config.h
Code: Select all
    #define  SERVO_MIN  {1400, 1400, 1400, 1400, 1400, 1400, 1400, 1400}
     #define  SERVO_MAX  {1600, 1600, 1600, 1600, 1600, 1600, 1600, 1600}
     #define  SERVO_MID  {1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500} // (*)
     #define  FORCE_SERVO_RATES  {30, 30, 100, 1, 100, 100, 100, 100} // 0 = normal, 1= reverse
And still, the Servo on my Tri goes all the way round. Which is too much.

In the MultiWii 2.2 I had the following settings, which worked fine:
Code: Select all
  /********************************    TRI    *********************************/
    #define YAW_DIRECTION -1
    //#define YAW_DIRECTION -1 // if you want to reverse the yaw correction direction
    /* you can change the tricopter servo travel here... war 1020 und 2000 */
      #define TRI_YAW_CONSTRAINT_MIN 1200
      #define TRI_YAW_CONSTRAINT_MAX 1800
      #define TRI_YAW_MIDDLE 1500 // (*) tail servo center pos. - use this for initial trim; later trim midpoint via LCD
How can I change the travel Rate with the new Servo Implementation? Is it a bug, or am I doing it completely wrong?

gektor · Post by **gektor** » Fri Jul 19, 2013 6:49 am

Dear Alex,

Thank you for your reply!

I thought, I am using the latest rev. (MultiWii_dev_2013_07_15_r1539), no?

I'm new here, so please excuse me if I've overlooked something.

By the way: what is the Advantage of using Hardware-PWM Mode?

Alexinparis · Post by **Alexinparis** » Tue Jul 23, 2013 11:28 pm

gektor wrote:I thought, I am using the latest rev. (MultiWii_dev_2013_07_15_r1539), no?

no, MultiWii_dev_2013_07_15_r1539 is just one time to time "snapshot" based on dev code.
if you want the very last dev code, you must compile it by yourself.

gektor wrote:By the way: what is the Advantage of using Hardware-PWM Mode?

hardware pwm is jitter free and is the best solution we can have to drive a servo.

Mis · Post by **Mis** » Wed Jul 24, 2013 2:02 am

Alex, your change in output.cpp ( "servo[5] = constrain(..." ) is not needed. The constrain is done with "for(i=SERVO_START-1; i<SERVO_END; i++) {" loop.

Code: Select all

servo[i] = constrain(servo[i], conf.servoConf[i].min, conf.servoConf[i].max); // limit the values

The servo[5] limits is only ommited if the HELICOPTER and YAWMOTOR are defined. Not with TRI.

Alexinparis · Post by **Alexinparis** » Thu Jul 25, 2013 12:14 am

Mis wrote:Alex, your change in output.cpp ( "servo[5] = constrain(..." ) is not needed. The constrain is done with "for(i=SERVO_START-1; i<SERVO_END; i++) {" loop.
Code: Select all
servo[i] = constrain(servo[i], conf.servoConf[i].min, conf.servoConf[i].max); // limit the values
The servo[5] limits is only ommited if the HELICOPTER and YAWMOTOR are defined. Not with TRI.

Hi,

in this part,
with mega and HW servo on a tri, servo[3] is used (SERVO_START-1 = 3)
with a soft PWM servo, servo[5] is used (SERVO_START-1 = 5)

in both case, servo[5] is used by PIDMIX and by GUI (agnostic)
if you omit "servo[5] = constrain(...", the setting from GUI is not taking into account for this servo in case of mega+HW+tri

timecop · Post by **timecop** » Mon Sep 30, 2013 3:30 pm

Code: Select all

// get servo middle point from Config or from RC-Data
int16_t get_middle(uint8_t nr)
{
    return (conf.servoConf[nr].middle < RC_CHANS) ? rcData[conf.servoConf[nr].middle] : conf.servoConf[nr].middle;
}

what the HELL is this???
Why is this kinda idiocy not commented at all?
rcData[] indexed by servoconf.middle (which is "1500" by default?!?!) If this is some hack that expects servoconf to be filled with zeros or something at beginning... hooly shit, put some COMMENTS down explaining it.

Mis · Post by **Mis** » Mon Sep 30, 2013 6:47 pm

This is high level of "C" coding :lol:

: value = condition ? value_if_true : value_if_false; This is easy

If sevo[nr].middle have value less than RC_CHANS (e.g 0..11) this function return value from rc channel table indexed by servo[nr].middle. Example: If servo.middle have value of 5, then this function return value from rcData[5] that is eqievalent of AUX2 value. This is a part of conditional "(conf.servoConf[nr].middle < RC_CHANS)" statement before ":" if the condition is true.
In other case, if servo.middle is bigger than 12 (e.g 1500 or 1700) this function return directly the servo.middle value (1500 or 1700 in this case). This is a part of conditional "(conf.servoConf[nr].middle < RC_CHANS)" statement after ":" if the condition is false.
With this way you can assign predefined value for servo middle position, or assign any RC Channel for control servo middle position (setting value 0..11).

Alexinparis · Post by **Alexinparis** » Mon Sep 30, 2013 10:47 pm

timecop wrote:
Code: Select all
// get servo middle point from Config or from RC-Data
int16_t get_middle(uint8_t nr)
{
    return (conf.servoConf[nr].middle < RC_CHANS) ? rcData[conf.servoConf[nr].middle] : conf.servoConf[nr].middle;
}
what the HELL is this???
Why is this kinda idiocy not commented at all?
rcData[] indexed by servoconf.middle (which is "1500" by default?!?!) If this is some hack that expects servoconf to be filled with zeros or something at beginning... hooly shit, put some COMMENTS down explaining it.

I admit it is not intuitive, but it's a very powerful feature.
It's a suggestion of Mis which I personally find brilliant

It is obviously interesting for Gimbal (you can move the center of each axis with the rc chan you want, everything tunable via GUI)
But not only: it can also be used to tune via AUXn the center servo of every servo multi type (tri, wing, plane, ...)

Documentation will follow in the wiki.
First piece is hidden here in this post and in this zip: viewtopic.php?f=8&t=4037&start=20#p41590