General servo handler - almost done

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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
Posts: 421
Joined: Tue Oct 25, 2011 9:25 am

Re: General servo handler - almost done

Post by nhadrian »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: General servo handler - almost done

Post by Mis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: General servo handler - almost done

Post by Alexinparis »

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 ;)

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

Code: Select all

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

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: General servo handler - almost done

Post by Mis »

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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

@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
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: General servo handler - almost done

Post by Mis »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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
Image
ServoCenter.png
(7.93 KiB) Not downloaded yet



There's a function to save the servosettings to file and copy to Config.h.
Image
ServoCenter.png
(7.93 KiB) Not downloaded yet


Hope this makes sense...

Please test.
/Patrik

Edit
Removed SeriaRC info
Attachments
Servosettings.png
Rcser.png
(4.5 KiB) Not downloaded yet
Last edited by PatrikE on Sat Jun 01, 2013 8:50 pm, edited 1 time in total.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

Ok cool.
I will try next week.

User avatar
polo_fly2
Posts: 34
Joined: Fri Aug 05, 2011 1:12 pm
Location: Munich - Bavaria

Re: General servo handler - almost done

Post by polo_fly2 »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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

User avatar
polo_fly2
Posts: 34
Joined: Fri Aug 05, 2011 1:12 pm
Location: Munich - Bavaria

Re: General servo handler - almost done

Post by polo_fly2 »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: General servo handler - almost done

Post by copterrichie »

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.

User avatar
polo_fly2
Posts: 34
Joined: Fri Aug 05, 2011 1:12 pm
Location: Munich - Bavaria

Re: General servo handler - almost done

Post by polo_fly2 »

Hi Copterritchie,

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

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: General servo handler - almost done

Post by copterrichie »

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.

User avatar
polo_fly2
Posts: 34
Joined: Fri Aug 05, 2011 1:12 pm
Location: Munich - Bavaria

Re: General servo handler - almost done

Post by polo_fly2 »

hey,

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

Georg

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

@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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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
Image
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 }
Attachments
Mixer.png
(4.1 KiB) Not downloaded yet

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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

User avatar
mgros
Posts: 90
Joined: Thu Jan 20, 2011 12:32 am

Re: General servo handler - almost done

Post by mgros »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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

User avatar
mgros
Posts: 90
Joined: Thu Jan 20, 2011 12:32 am

Re: General servo handler - almost done

Post by mgros »

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


Perfect, thanks a lot!!

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: General servo handler - almost done

Post by Sebbi »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: General servo handler - almost done

Post by Alexinparis »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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

Sebbi
Posts: 478
Joined: Sun Jul 08, 2012 1:08 am
Location: Germany
Contact:

Re: General servo handler - almost done

Post by Sebbi »

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
Posts: 10
Joined: Thu Jul 18, 2013 5:20 pm

Re: General servo handler - almost done

Post by gektor »

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
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: General servo handler - almost done

Post by PatrikE »

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
Posts: 10
Joined: Thu Jul 18, 2013 5:20 pm

Re: General servo handler - almost done

Post by gektor »

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! :D 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:

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: General servo handler - almost done

Post by Hamburger »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: General servo handler - almost done

Post by Alexinparis »

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? :roll:

gektor
Posts: 10
Joined: Thu Jul 18, 2013 5:20 pm

Re: General servo handler - almost done

Post by gektor »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: General servo handler - almost done

Post by Alexinparis »

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
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: General servo handler - almost done

Post by Mis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: General servo handler - almost done

Post by Alexinparis »

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
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: General servo handler - almost done

Post by timecop »

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
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: General servo handler - almost done

Post by Mis »

This is high level of "C" coding :lol: : value = condition ? value_if_true : value_if_false; This is easy :D
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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: General servo handler - almost done

Post by Alexinparis »

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

Post Reply