PDA

View Full Version : Camera Stablisation continued



CupOfTea
12-04-2010, 07:22 PM
I'm assuming the other thread was closed by accident....


Now to interesting stuff, first what I like:
- separte mCamera and bCamera variables for each axis, I thought about it (my roll servo may need to go at different speed because of mount mechanics) and you did it already. I also needed a way of reversing the servo action... because of the mount mechanics. ie by making mCamera -ve


- pitchbCamera = 1300; - nice touch, camera pointing slightly down initially, but why rollbCamera = 1300; ? Wouldn't it make it tilted when started?Not sure why my roll servo wasn't centered to start with... assumed it was cheap servo weirdness but maybe I need to double check the mechanics.


What I don't like: Why did you commented out the yaw pin and put in all those ifdef's for the yaw motor? if you don't need it just don't connect the motor to the pin, or even comment it out in your version, code should be as general to everybody as possible.I just assumed that not creating a servo instance would save space and not executing the code save time. I wasn't wanting pick to on yaw, I was going to do it for all axis but got lazy.




CupOfTea & Itod, I've been meaning to ask you guys, in the past I've had problems with having PCINT on for reading receiver pins and using servo.h for controlling servos at the same time. It would jitter pretty consistently. Did something happen in 0021, or did you somehow optimize this to work together now? I glanced at Itod's first implementation, but it seemed like he just used the built in libraries?

Woohoo if it works automatically now! It's still using the servo.h... and the servo's still jitter. Just tried it with the receiver on for the first time... taken the wind from my sails a bit. Did you have any ideas about how to fix this?

itod
12-04-2010, 08:00 PM
I just assumed that not creating a servo instance would save space and not executing the code save time.

Can you please remove those yaw-discrimination from your code :rolleyes: before Mikro pulls your changes to master branch so it would be perfect to everyone? Believe it or not when people talk of 2-axis stabilization they generally think of yaw + pitch, not roll + pitch, they call it "pan and tilt stabilization". Also rollbCamera = 1500; for everyone would be nice.

How much is this servo command execution time for all three servos actually? Maybe Mikro would measure that on his fancy scope so we will know exactly. They are probably not significant in general picture, and people will probably include or exclude all camera stabilization generally.

Interesting, there is no jitter on my side, you can see that on the video I posted. Only explanation I have is that I use Mega and you Duemilanove.

CupOfTea
12-04-2010, 10:08 PM
Can you please remove those yaw-discrimination from your code :rolleyes: before Mikro pulls your changes to master branch so it would be perfect to everyone? Believe it or not when people talk of 2-axis stabilization they generally think of yaw + pitch, not roll + pitch, they call it "pan and tilt stabilization". Also rollbCamera = 1500; for everyone would be nice.
I've pushed a change to AeroQuad.h that uncomments the yaw pin definition, returns roll to it's original orientation and centers all servos at 1500.

Assumptions again.... I assumed that a yaw servo on the quad would point the camera at the frame and motors which wasn't desirable. But I guess that's only true when the camera points straight ahead... but then if the camera points straight down... roll is panning so yaw would be...arrrgh I get confused too easily

maybe subliminally I'm a yaw bigot... It just doesn't have the glamor :)


How much is this servo command execution time for all three servos actually? Maybe Mikro would measure that on his fancy scope so we will know exactly. They are probably not significant in general picture, and people will probably include or exclude all camera stabilization generally.I left the ifdef's in on the basis that they don't do any harm and if Mikro doesn't like em he doesn't need to take em.

In my very first post was a question no-one picked up on.....

I've since realised it includes the code to turn the camera routines on. Is it better to tidy that up or to submit the code as tested?Are we submitting release ready code, or providing a branch with code that can be easily compiled, tested and then cherry picked if required.


Interesting, there is no jitter on my side, you can see that on the video I posted. Only explanation I have is that I use Mega and you Duemilanove.
Unfortunately I suspect that if you connect your receiver and turn on the transmitter you will see jitter on the servo. It doesn't look good.... I googled combinations of servo jitter arduino pcint etc and all I got was AeroQuad and Mikro looking for answers.

Honk
12-04-2010, 10:13 PM
About the jitter: 1280 got more independent hardware timers and also more hardware interrupts, therefore it should (and in my case is) more stable when using servos and radio.

CupOfTea
12-04-2010, 11:35 PM
About the jitter: 1280 got more independent hardware timers and also more hardware interrupts, therefore it should (and in my case is) more stable when using servos and radio.

You are using oilpan? or do you have mega V2 as well. Mine is mega with V2 shield.... which arduino pins are your servos connected to?

Honk
12-05-2010, 12:50 AM
Hmm, that makes it stranger. I've never had problems with pin 6 and 7 on the mega to use as servo pins. I have never noticed difference in jitter when radio active/inactive. Maybe it's just something you have made "wrong"? Tried just putting your servo's directly to the receiver?

I have no name for my many setups, but it's 1280's for the moment. Never tried servo driving on 328's.

lokling
12-05-2010, 09:58 AM
In my very first post was a question no-one picked up on.....
Are we submitting release ready code, or providing a branch with code that can be easily compiled, tested and then cherry picked if required.


I think thats up to us to define. I think we should strive to have commits of the right size and clearly labeled so its easy to cherry pick for mikro if needed. At work we prefix each commit with the issue number. In our case it could be something like "Removing warnings: ... detailed commit message"

It also helps branching of for experimental work. Im going to try keep my master branch in a "flyable" state - meaning that anyone downloading that will be pretty ok - just because I think its a risk people will do that without looking into the details.

There is a git workflow adopted by many that adresses some of the practical arrangmenets of using a distributet scm: http://nvie.com/posts/a-successful-git-branching-model/

itod
12-05-2010, 12:17 PM
Good read lokling, going through it whole morning and not finished yet :)


Unfortunately I suspect that if you connect your receiver and turn on the transmitter you will see jitter on the servo. It doesn't look good.... I googled combinations of servo jitter arduino pcint etc and all I got was AeroQuad and Mikro looking for answers.

I'm seriously considering offloading some work to another very small arduino. Than we would not have a problem with these kind of stuff, for instance slave one would read the sensors and drive a camera, and the main one would listen to the receiver and execute the rest of the stuff from the main loop like driving the motors, and it would be trivial for each other to talk. BTW, since yesterday Arduino Pro Mini is depreciated at SparkFun, this (http://www.sparkfun.com/products/9219) is the weakest and cheapest arduino now, essentially Duo without USB. I wonder if it is compatible with Shield 1.8 (there is 3.3V version (http://www.sparkfun.com/products/9221)) to offload all the sensors and camera control on it. Maybe we can even squeeze DCM in it, so main arduino would only get nine DCM float numbers from slave one, and be free from that long, 2ms DCM calculation. Some kind of AeroQuad IMU with camera control logic. What do you think?

Honk
12-05-2010, 01:49 PM
I looked through that workflow too. Nice pictures! Will have to read it over and over... :)

Itod, WHATWHAT? I love the Pro Mini, it's great for everything! Well, that other slimmed board should be pin compatible with the Due/Uno's, but I don't know if it's the optimal solution. I really like the APM with both a 328 for radio and a 1280 for main processing, but well, if we have to use Due/Uno's, then the Arduino Pro would probably be a good solution.

CupOfTea
12-05-2010, 06:32 PM
I've never had problems with pin 6 and 7 on the mega to use as servo pins.

pins 6 & 7? - is this a pin numbering confusion or are we using different pins? Itod and I are using the first 3 servo pins on the version 2 shield which map to arduino pins 33 34 and 35.

CupOfTea
12-05-2010, 06:41 PM
I'm seriously considering offloading some work to another very small arduino.

It looks like Mikro came to a similar conclusion.... Aeroreceiver (http://code.google.com/p/aeroquad/source/browse/#svn/trunk/Documentation/Shield/AeroReceiver_v0.1)

CupOfTea
12-05-2010, 07:09 PM
Really helpful.... Thanks. Having an eye to the big picture and planning commits would seem to be key. I may have to rethink the shotgun approach :)

Honk
12-05-2010, 07:18 PM
pins 6 & 7? - is this a pin numbering confusion or are we using different pins? Itod and I are using the first 3 servo pins on the version 2 shield which map to arduino pins 33 34 and 35.

UUh.. :) On the Arduino Mega board it says in white silkscreen: "6 7" and when you program it, you type "6" and "7" to be the pins for the two servo's. ? Maybe those are coupled to a left-over or less loaded hardware timer. You should try it. It shouldn't be hard just soldering on a wire or pin sideways on it.

For reference, here you can see them in the "PWM" marked area:
http://arduino.cc/en/uploads/Main/ArduinoMega.jpg

itod
12-05-2010, 09:45 PM
It looks like Mikro came to a similar conclusion.... Aeroreceiver (http://code.google.com/p/aeroquad/source/browse/#svn/trunk/Documentation/Shield/AeroReceiver_v0.1)

He is keeping the most interesting projects secret from us ... in the repository.

Mikro
12-05-2010, 10:14 PM
Hey, do you guys want to beta test the AeroReceiver PCB board? It supports a Pro Mini and connects GPS, OSD, and separates receiver input so that you can do servo control on the AeroQuad Shield with no jitter. If you are in the US I will ship it to you for free, otherwise I'd ask if you can pay for shipping to an international address. Please PM if you are interested. I have the Pro Mini already and FDTI port available in the AeroQuad Store.

CupOfTea
12-05-2010, 10:20 PM
pin 7 & 8 are perhaps a little better, but basically the same as pins 33-40 continuous jitter if transmitter on and an occasional jit with it off

isn't pin 6 LEFTMOTORPIN line 145 motors.h

Honk
12-05-2010, 10:37 PM
Mikro: I can test it without you sending hardware across the world, I have the stuff already... Well no OSD/GPS but receiver... :) Just tell me what to do.

Cup: Well ok. I never had any trouble with it but still... Are you sure the problem is in the Arduino/code? I can imagine a ton of other things... Sort of.
I use whatever pins I like for the motors! :)

chris1seto
12-05-2010, 10:46 PM
I'm interested in testing. Will it work with the 2.0 shield?

CupOfTea
12-05-2010, 11:32 PM
Are you sure the problem is in the Arduino/code?
No... but it seems very likely given the effect occurs when transmitting and goes away when not transmitting. There's not much other than the code could do that... is there?

hmmm Ok... There is still the small occasional jit when not transmitting to account for...

Would be interesting to hear from anyone else who has a chance to try it.


I use whatever pins I like for the motors! :)You're not going shieldless are you? That would be like not wearing underwear. :)

Honk
12-06-2010, 12:19 AM
Well, there's bad servo's, interference, bad receiver and so forth. But ok, it's probably got to do with the timers. That's why I wanted you to try different ports.


You're not going shieldless are you? That would be like not wearing underwear.

Maybe I don't wear underwear?! :P

UndCon
12-06-2010, 06:40 AM
Good read lokling, going through it whole morning and not finished yet :)



I'm seriously considering offloading some work to another very small arduino. Than we would not have a problem with these kind of stuff, for instance slave one would read the sensors and drive a camera, and the main one would listen to the receiver and execute the rest of the stuff from the main loop like driving the motors, and it would be trivial for each other to talk. BTW, since yesterday Arduino Pro Mini is depreciated at SparkFun, this (http://www.sparkfun.com/products/9219) is the weakest and cheapest arduino now, essentially Duo without USB. I wonder if it is compatible with Shield 1.8 (there is 3.3V version (http://www.sparkfun.com/products/9221)) to offload all the sensors and camera control on it. Maybe we can even squeeze DCM in it, so main arduino would only get nine DCM float numbers from slave one, and be free from that long, 2ms DCM calculation. Some kind of AeroQuad IMU with camera control logic. What do you think?

I don't know if I miss something..

but the Arduino Pro Mini (http://www.sparkfun.com/products/9218) is in Sparkfun shop
(not deprecated)


I use this on my MultiWii and I have 2 servos out for camera control - works great(pins A0/A1)

itod
12-06-2010, 08:31 AM
I don't know if I miss something..

but the Arduino Pro Mini (http://www.sparkfun.com/products/9218) is in Sparkfun shop
(not deprecated)

Well I can't prove it to you right now, but it said so yesterday, that's how I found out about Arduino Pro 328. Must be they got a torrent of complaints from buyers. It makes little sense for them to have two products with the same price when one is clearly superior, but maybe that big size difference is the key (18mmx33mm vs 54mmx52mm).

UndCon
12-06-2010, 12:50 PM
Actually it could be more convenient to use the Arduino Pro as you can mount the Wii-sensors on top of that board
(if you use the wii-sensors)

If they drop Pro Mini I will order a few to cover my Tricopter/Quadcopter fleet :)

ala42
12-07-2010, 12:11 AM
It's still using the servo.h... and the servo's still jitter. Just tried it with the receiver on for the first time... taken the wind from my sails a bit. Did you have any ideas about how to fix this?
I have just checked the arduino-0021 sources. The Servo class toggles the ports by software, so it has to jitter. Just use analogWrite, as the Motors_PWM class does and the jitters are gone. On the a ATmega1280 or ATmega2560 hardware timers for PWM are available on pin 2-13 and 45-46. They somehow forgot part of the the code to support pin 44.
You could also check the Motors_ArduCopter class on how to access the timers directly, which gives you better precision, 16 bit against 8 bit and you can set the timer periode and precision directly.
Here is the mapping of pins to timer taken from the pins_arduino.c file:


TIMER3B , // PE 4 ** 2 ** PWM2
TIMER3C , // PE 5 ** 3 ** PWM3
TIMER0B , // PG 5 ** 4 ** PWM4
TIMER3A , // PE 3 ** 5 ** PWM5
TIMER4A , // PH 3 ** 6 ** PWM6
TIMER4B , // PH 4 ** 7 ** PWM7
TIMER4C , // PH 5 ** 8 ** PWM8
TIMER2B , // PH 6 ** 9 ** PWM9
TIMER2A , // PB 4 ** 10 ** PWM10
TIMER1A , // PB 5 ** 11 ** PWM11
TIMER1B , // PB 6 ** 12 ** PWM12
TIMER0A , // PB 7 ** 13 ** PWM13
TIMER5C , // PL 5 ** 44 ** D44
TIMER5B , // PL 4 ** 45 ** D45
TIMER5A , // PL 3 ** 46 ** D46

Honk
12-07-2010, 02:25 AM
Thanks ala for the idea! And taking out the documentation. Wonder why we didn't think of this... Hmm, but anyways, yes using the timers directly should be the best! Also, with the documentation we can optimize so we use only one hardware timer per servo if we want.

Yes, I know they missed pin 44, but if you look in the routines in there it's quite easy to copy-paste support for that pin too. However I like the real method better where you can decide every parameter yourself. This should be the best solution, not the most readable (for the calculations you gotta read the Atmel 4 million pages datasheet :) ), but the best way to get it to run as smoothly as possible.

Luckily I believe there's already finished calculations/setups for 2 specific pins/timers for driving servo's in 50Hz (that period could be changed to push the servo to be updated faster!) already in the ArduCopter routines in the AeroQuad code. For future use. Which seems to be now? :)

ala42
12-07-2010, 06:30 PM
Right, you will understand how to setup the timers with these examples, should be no problem.

CupOfTea
12-07-2010, 09:27 PM
Yeeha!.... I have 2 servos working on timer1.... no transmitter jitter

Is it possible to use pin 11 / OCR1A or is it commented out for a reason?

tried timer5 but cant get it working for some reason.

will play some more when I get time. Thanks ala :)

ala42
12-07-2010, 11:11 PM
pin 11 should be free for use, I see no reference to it or OCR1A in the sources for AeroQuadMega_v2.
Post the code part you used to get timer 5 running.

CupOfTea
12-07-2010, 11:34 PM
On the version 2 shield pins 43-49 are connected to the LED driver chip, could that be the problem using timer5.

The code is pretty much stolen direct from Motors_ArduCopter.

I don't understand quite how the timing works either. The AQ code maps +/-90 degrees to 1000-2000 centered 1500. But I am seeing 180 degrees on the servo with only 45 degrees movement on the quad.


//Camera.h
// ************************************************** *********************
// *********************** CameraServo ***************************
// ************************************************** *********************
class cameraServo {
public:
cameraServo(void) {
// Init PWM Timer 1
//pinMode(11,OUTPUT); // (PB5/OC1A)
pinMode(12,OUTPUT); //OUT2 (PB6/OC1B)
pinMode(13,OUTPUT); //OUT3 (PB7/OC1C)

//Remember the registers not declared here remains zero by default...
TCCR1A =((1<<WGM11)|(1<<COM1B1)|(1<<COM1C1)); //Please read page 131 of DataSheet, we are changing the registers settings of WGM11,COM1B1,COM1A1 to 1 thats all...
TCCR1B = (1<<WGM13)|(1<<WGM12)|(1<<CS11); //Prescaler set to 8, that give us a resolution of 0.5us, read page 134 of data sheet
//OCR1A = 3000; //PB5, none
OCR1B = 3000; //PB6, OUT2
OCR1C = 3000; //PB7 OUT3
ICR1 = 40000; //servo

// Init PWM Timer 5
pinMode(44,OUTPUT); //OUT1 (PL5/OC5C)
pinMode(45,OUTPUT); //OUT0 (PL4/OC5B)
//pinMode(46,OUTPUT); // (PL3/OC5A)
TCCR5A =((1<<WGM51)|(1<<COM5B1)|(1<<COM5C1));
TCCR5B = (1<<WGM53)|(1<<WGM52)|(1<<CS51);
//OCR5A = 3000; //PL3,
OCR5B = 3000; //PL4, OUT0
OCR5C = 3000; //PL5, OUT1
ICR5 = 40000; //50hz freq (standard servos)
}
void move (int roll, int pitch, int yaw) {

OCR5B = pitch * 2;
OCR1C = roll * 2;
// OCR1A = yaw * 2;

}
};

Honk
12-08-2010, 01:26 PM
For the motors (ArduCopter_Motors), the timers expect 2000-4000 to be written to them, so to write: 1000 normal value (1ms) is written as 2000 and 2000 (2ms) is written to timer as 4000. Then you'll have to consider the range of your servo.

For example I've had servo's requiring 0.7ms-1.6ms, getting to be 700 - 1600 and to the timers in this case 1400 - 3200. That is IF the calculations are the same for the servo's in 50Hz mode has the same proportional numbers as the motors in 300Hz. Steal the motor driver code instead of the servo driver code is a suggestion and test how 300Hz mode is driving the servo's.

Also try searching for proper documentation and tutorials on the "proper" methods: http://www.societyofrobots.com/member_tutorials/node/231

ala42
12-08-2010, 05:13 PM
The calculations are the same on 50Hz or 300Hz mode.
Some basics about the 16 bit timer:
- The timer counts clock ticks derived from the CPU clock. Using 16MHz CPU clock and a prescaler of 8 gives a timer clock of 2MHz, one tick every 0.5µs. This is also called timer resolution.
- The timer is used as cyclic upwards counter, the counter periode is set in the ICRx register. IIRC periode-1 has to be set in the ICRx register.
- When the counter reaches 0, the outputs are set
- When the counter reaches OCRxy, the corresponding output is cleared.
In the code above, the periode shall be 20ms, so the ICRx register is set to 40000 ticks of 0.5µs/tick. It probably should be 39999, but who cares about this 0.5µs for the periode.
The high time shall be 1500µs, so the OCRxy register is set to 3000. A change of the timer periode does not change this setting, as the clock rate is still one tick every 0.5µs. If the prescaler was changed, the OCRxy register value would be different.

Honk
12-08-2010, 08:01 PM
Thanks for the plain explanation. Then my numbers before apply. Makes it very simple!

CupOfTea
12-09-2010, 03:10 AM
ok got pin 11 working. but thats about it for progress today.

brain hurts... been reading the data sheet....

why would ICR1 not be observed as TOP given this



// Init PWM Timer 1
pinMode(11,OUTPUT); // Pitch (PB5/OC1A)
pinMode(12,OUTPUT); // Roll (PB6/OC1B)
pinMode(13,OUTPUT); // Yaw (PB7/OC1C)
// WGMn1 WGMn2 WGMn3 = Mode 14 Fast PWM, TOP = ICRn ,Update of OCRnx at BOTTOM - page 148 Mega Datasheet
TCCR1A =((1<<WGM11)|(1<<COM1A1)|(1<<COM1B1)|(1<<COM1C1)); // Clear OCnA/OCnB/OCnC on compare match, set OCnA/OCnB/OCnC at BOTTOM (non-inverting mode).
TCCR1B = (1<<WGM13)|(1<<WGM12)|(1<<CS11); //Prescaler set to 8, that give us a resolution of 0.5us
ICR1 = 39999; //50hz freq (standard servos) 20ms = 40000 * 0.5us
OCR1B = 3000; //init each servo to center
OCR1C = 3000;
OCR1A = 3000;
Took a while but I was able to prove ICRn is being ignored by changing it and seeing no difference in the servo behavior. It's counting I guess until it overflows giving me servo movement when the counts happen to sync. If motors_ArduCopter works then this should work??? what might be different?

Honk
12-09-2010, 01:24 PM
If motors_ArduCopter works then this should work??? what might be different?

They certainly work, but are you sure you have included the needed includes correctly? That is the only thing I can imagine. Or some other conflicting code when using motors_ArduCopter at the same time as motors_PWM... ? Try just using motors_ArduCopter first separately.

ala42
12-09-2010, 10:19 PM
Took a while but I was able to prove ICRn is being ignored by changing it and seeing no difference in the servo behavior. It's counting I guess until it overflows giving me servo movement when the counts happen to sync.
No guessing needed, let the CPU check if the counter does what it should do. After the initialization run this (untested) code:


{
uint8_t oldSREG = SREG;
unsigned short tmax=0;
unsigned short t;
cli();
while ((t = TCNT1) >= tmax) {
tmax = t;
}
SREG = oldSREG;
Serial.print("Timer 1 max: ");
Serial.println((long)tmax, 10);
}

This loop hangs if the timer does not count at all, but as you already know it counts, that does not matter.

Mikro
12-10-2010, 01:20 AM
Hey guys, sorry didn't get a chance to chime in sooner. We could use analogWrite() with no problem to command servos, but I think the update rate are too fast and reading through Arduino forums seems to cause some trouble for analog servos. But... what if we spec out to use digital servos? I've ran those with no apparent issue in the past.

CupOfTea, sounds like you were able get direct timing programming working? Honk has been pushing to look at ArduCopter method of writing to motors, but I need to sit down and make sure the pins they are using are compatible with AeroQuad Shield (or at least code can be used such that it doesn't interfere with other AeroQuad reserved digital pins). Before I take time to do this, does anyone already know if there isn't a compatibility issue?

CupOfTea
12-10-2010, 02:08 AM
Arrrrgh.....Got it! oop-age : something to do with the way I was declaring the class

just pushed to my git (https://github.com/CupOfTea/AeroQuad/tree/Camera) there is now a camera.h

That was a lot of good learning about stuff that had nothing to do with the problem.

The next is identifying which Timers or pins we can/should use
Just looking through the code for the Mega I get


Pin MegaV2 Arducopter
Timer 1A 11
B 12 Motor
C 13 LEDPIN Motor
Timer 3A 5 Motor
B 2 Motor
C 3 Motor
Timer 4A 6 Motor PPM input
B 7
C 8
Timer 5A 46 LED
B 45 LED Motor
C 44 LED Motor if there is nothing else using these timers/pins then it looks like a choice of Timer1 or 5 for MegaV2 and Timer3 for Arducopter? I am a little concerned that the Arducopter code only appears to use 2 channels per timer... does anyone know the reason for this? I've used all three pins on all 4 timers happily on a bare mega.

other things to consider?
servos move ~180 degrees not all mounts do
if a mount only move 90 degrees where does it point when centered?
some mounts reverse the servo action. -ve mCamera

Honk
12-10-2010, 02:46 AM
Mr. Tea, great! I read though your git and it looked very tidy and well laid out to be as configurable as possible for different port uses when attaching servo's. Nice. I like that because all the different setups will be able to use it then.

About your findings of timer usage: didn't you get your conclusion mixed up? The MegaV2 uses Timer3A,3B,3C and Timer4A while Arducopter uses 2 channels on Timer1 and 2 channels on Timer5. There is very little to be afraid/concerned about using all the 3 channels, the whole AeroQuad has done it all along indirectly through the analogWrite API function!

So, Mikro, just use the same code but change it to use Timer 3A/3B/3C/4A and it will work as before on a MegaV2 shield, but with more accurate/faster output.

Correct me if I'm wrong, but doesn't this also save code space/RAM and such? If we never called analogWrite we should gain something. I mean for the 328 based flight boards.

CupOfTea
12-10-2010, 07:46 PM
About your findings of timer usage: didn't you get your conclusion mixed up? The MegaV2 uses Timer3A,3B,3C and Timer4A while Arducopter uses 2 channels on Timer1 and 2 channels on Timer5.
:confused:Isn't that what the table says? Does the Arducopter not actually use Timer4 for reading PPM?


There is very little to be afraid/concerned about using all the 3 channels, the whole AeroQuad has done it all along indirectly through the analogWrite API function!Of course doh! they're commented out just to make the pins available for other things.


So, Mikro, just use the same code but change it to use Timer 3A/3B/3C/4A and it will work as before on a MegaV2 shield, but with more accurate/faster output.I no one else does I'll have a go at this when I get a replacement ESC from HK to test with.

CupOfTea
12-11-2010, 02:28 AM
I made table of all the pin outs, initially to figure out the timers on the 328, but I got carried away. Don't have a Arducopter schematic so I gave up there.

https://spreadsheets.google.com (https://spreadsheets.google.com/ccc?key=0AoZ5bZF0qNerdDBPdjQ5cm1GU2Y0ZHBxa2FaZmVYe VE&hl=en&authkey=CJP8mtsF)

dbdb2000
12-19-2010, 09:30 PM
can someone help me in getting the servo's working. my quad flies fine and i have now remade from wooded frame to aluminium and am looking to try a small camera. i have changed the comment to #ifdef Camera on the first tab and added to the servo.h library to aeroquad folder.
what other items do i need to define as when i upload i get the following errors- what does it mean by does not name a type?
in aeroquad.h to camera is defined leaving
#ifdef Camera
#define ROLLCAMERAPIN 33 // Servo 1 signal pin
#define PITCHCAMERAPIN 34 // Servo 2 signal pin
#define YAWCAMERAPIN 35 // Servo 3 signal pin
// map +/-90 degrees to 1000-2000
float mCamera = 11.11;
float bCamera = 1500;
Servo rollCamera;
Servo pitchCamera;
Servo yawCamera;
#endif
Thanks


error message when uploading

In file included from AeroQuad.cpp:82:
AeroQuad.h:229: error: 'Servo' does not name a type
AeroQuad.h:230: error: 'Servo' does not name a type
AeroQuad.h:231: error: 'Servo' does not name a type
AeroQuad.cpp: In function 'void setup()':
AeroQuad:354: error: 'rollCamera' was not declared in this scope
AeroQuad:355: error: 'pitchCamera' was not declared in this scope
AeroQuad.cpp: In function 'void loop()':
AeroQuad:404: error: 'rollCamera' was not declared in this scope
AeroQuad:405: error: 'pitchCamera' was not declared in this scope
AeroQuad:406: error: 'yawCamera' was not declared in this scope

Honk
12-19-2010, 10:43 PM
dbdb2000, you just forgot to include the servo library...

However, I think it's better if we use the direct timer access as suggested in this thread.

wilafau
12-20-2010, 02:42 PM
@dbdb2000 - Honk is right - I got that error too and it was because I had not uncommented the "#include <servo.h>" on about line 80 of AeroQuad.pde. You will also need to change "byte CameraLoop = OFF;" to "ON" at about line 281 in AeroQuad.h.

Finally, after I made those changes my servo's were still not working. I discovered on the 2.0.6 shield that the Servo "+" pin for Servos 1,2,3 & 4 is connected to the ESC PWM #1 "+" pin, it is NOT connected to the Arduino's regulated 5V. I believe this is so that the Servos inductive loads don't overtax the Arduino's power supply. Instead it uses the BEC function from ESC #1 to get its power. If your ESC doesn't have a BEC this could be a problem for you.

dbdb2000
12-23-2010, 09:25 PM
I still can't get any movement from the servos at all.
I am running the grd,+5v lines from the servo to a second battery just to check they are getting power and they do move when first plugged in (small turn, still movement in servo range).
The signal line is going to servo 1, sig pin on the shield (ver 2.0.6)

I downloaded a fresh copy of the quad software and changed.

aeroquad ss
line 35 #define AeroQuadMega_v2
line 64 #define Camera
line 65 #define CameraTimer1
line 80 #include <Servo.h>

aeroquad.h
line 281 #define DEBUG
and checked cameraloop was already=on

do i need to insert a servo.h library file anywhere in the aeroquad file or do anything else however simple and stupid it may seem to mention to do first.
you don't have an aux switch to turn it on?
change anything in camera.h, pin number, servo range ect?
as i still haven't got any movement whilst the aeroquad is powered like in the video shown before. I'm sure i haven't defined something athough I am running a mega and since the upgrade to green shield light has stayed off although when downgraded works again.
thanks

ala42
12-23-2010, 10:08 PM
Did you connect the GND of the second battery with the GND of the shield ?

dbdb2000
12-23-2010, 11:07 PM
no, but what i have just tried is taking the signal line from the servo and putting it on signal on pin1 servo shield then putting the remaining power and ground to the arduino shield.
This then takes 5v+ and ground straight from the shield so taking the battery out of the equation.
i'm sure it is software related by me not doing something that I should be or ticking something that i shouldn't.
If you have the servos working does it only work when the quad is armed? or is it always on when the board is powered?

Mikro
12-24-2010, 09:40 PM
OK, guys... was working on camera stabilization on the Mega 2560, got it working based on CupOfTea's latest input. Was getting caught up here and looks likeyou guys are also playing with this too. I uploaded everything to the "working" branch on GitHub (https://github.com/AeroQuad/AeroQuad/tree/working)... after a short vacation this week, I'll wrap this up into the next beta release along with some user config values through the Configurator.

In addition to minor software changes, you'll need to mod the v2.0 shield a little. I was hoping to use the Servo library which allows you to use any digital pin, but for now CupOfTea is writing directly to timers and their corresponding pins, so we need to route those signals to the correct pins on the v2.0 shield.

I put these same comments directly in the code where you enable the new camera stuff:

// Servo output goes to D11-D13
// If using v2.0 Shield place jumper between:
// D12 to D33 for roll, connect servo to SERVO1
// D11 to D34 for pitch, connect servo to SERVO2
// D13 to D35 for yaw, connect servo to SERVO3
// Please note that you will need to have battery connected to power on servos

An interesting thing to note, that as you rev the motors up, you'll start to see the camera start to jitter more. This is not the same jitter as the old code... it would jitter when motors were on or not. I think it's because DCM sees the jitter during flight... which makes me think that this would also affect Stable Mode. I believe this goes back to proper tuning of Kp and Ki in the DCM code. We could just cheat and put a low pass filter on the angle going into the camera class, but I think the right fix would be to tune DCM right.

As far as I can tell (maybe jihlein can tell us better), Kp get's the sensors to report the right angle faster, while a higher Ki starts to remove noise in the filter. We still need to play more in this area.

Anyway, it's really cool to look right into the camera, shake the quad and have the camera always pointed straight at you... almost like the quad is a little robot always wanting to look at it's master. :)

THANK YOU CupOfTea for this contribution... it looks like it's going to be really fun to work with next!

CupOfTea
02-07-2011, 11:59 PM
I'm about to tidy up a few things in the camera stabilisation code.... any observations or requests before I go in there?

Bluerex
02-10-2011, 08:47 PM
Any chance of TX input to "aim" the camera, and then have your code look after the stabilisation? I have a couple of TX channels left over - but also thinking that a second operator could fly the camera using a "trainer cable" hooked into my transmitter.

c

CupOfTea
02-10-2011, 10:31 PM
Any chance of TX input to "aim" the camera, and then have your code look after the stabilisation? I have a couple of TX channels left over - but also thinking that a second operator could fly the camera using a "trainer cable" hooked into my transmitter.

As far as the camera stabilisation code goes if you drive camera.setCenterAxis() in real time you will get what you want. The problem is getting real time commands to the camera code. The idea of the mode variable was to enable people to be able to select behaviors in real time.

mode 0 - Off save battery till needed
1 - Computer Stabilises around a preset center (current default)
2 - Human controls the center about which the computer stabilises in real time
3 - Human only control.

This isn't currently implemented but could be pretty easily using serial comms and xbees. As we are only driving a camera servo we don't really need a binary error checking protocol (would be a good low risk way to test such a protocol though).

I'm not sure whats involved in getting support for more tx channels, you would have to ask one of the guys who was involved with setting up the pcint stuff. If you can get the extra channels supported then it should be easy to point the incoming data at the camera code.

I will pursue a xbee solution as I get time but I'm afraid someone else will have to do the pcinit thing. (I have xbee but not extra channels)

Stuart 73
03-19-2011, 06:56 PM
Hi all, just a quick question how do i go about reversing servo direction ?
the camera stabilisation works well on my quad, but i have had to make a custom made pan tilt unit to fit into a tight space on the quad
it would be good to be able to reverse the direction of the servo's
i have very limited knowledge of computer code! but plenty knowledge of engineering and mechanical so i have got around the problem for the moment
but would be nice to make simpler.
any help or simple instructions how to change the code would be good for all,
thanks,,,

itod
03-19-2011, 08:08 PM
Hi all, just a quick question how do i go about reversing servo direction ?

Change those 11.11 values for servos you want to reverse to -11.11 in this fil (http://code.google.com/p/aeroquad/source/browse/trunk/AeroQuad/Camera.h)e, lines 69, 70 & 71.

Please report if it works as expected, we may put this in FAQ, you will not be the only one with that need.

Revwarguy
03-19-2011, 11:14 PM
Actually, this is already in the Wiki, but its not all that easy to find.

Stuart, If you are using the camera stabilization code, I highly recommend you look at the docs for it at

http://aeroquad.com/wiki/index.php/Software_Documentation#Camera.h

Avalonnw
03-09-2014, 12:25 PM
Hi guys, I just found some interesting piece of magic. I'm playing with camera stabilization, and the thing is, I cannot load any parameters using the Configurator. There is that message coming up that the values are wrong or something like that. The fun part, when I use Terminal and push a string like that
P1;1600;1150;1500;-900;-900;11.11;1100;650;1000 ;2100;1650;2000;1 all seems good, camera is centered (Tx control not working however), and when I send the "p" i get a response:
1,1600,1150,1500,-900.00,-900.00,11.11,1100,650,1000,2100,1650,2000,0, which is reasonably good (there is last 0 instead of 1 for some reason). BUT! If I just simply restart the system, and send "p" again, the response will be like that:
1,1870,1500,1500,1273.20,636.60,318.30,1000,1000,1 000,2000,2000,2000,1,
the second value (1870) can be different at different times.
What is that? What should I do? It looks like EEPROM data for camera gets rewritten every time I restart the board...

wooden
03-09-2014, 07:38 PM
Did you send a 'W' to actually write the parameters to EEPROM before restarting?

Avalonnw
03-09-2014, 11:18 PM
Hmmm... No? I'll try that.

wooden
03-10-2014, 12:43 AM
When updating values manually over serial connection, they aren't actually written to the EEPROM until you send a 'W'. They are stored in global variables that get used while flying so they'll be updated for this power cycle but unless you save them to EEPROM with 'W', they'll be lost once you power down.

Avalonnw
03-10-2014, 04:55 AM
Yeah, it worked, thanks.