Hello and welcome to our community! Is this your first visit?
Register
Page 1 of 6 123 ... LastLast
Results 1 to 10 of 58
  1. #1
    Senior Pilot CupOfTea's Avatar
    Join Date
    Apr 2010
    Location
    New Zealand
    Posts
    183
    Blog Entries
    1
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    0

    Camera Stablisation continued

    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?

  2. #2
    Senior Pilot itod's Avatar
    Join Date
    Sep 2010
    Location
    Belgrade, Serbia, Serbia
    Posts
    731
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    0
    Quote Originally Posted by CupOfTea View Post
    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 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.

  3. #3
    Senior Pilot CupOfTea's Avatar
    Join Date
    Apr 2010
    Location
    New Zealand
    Posts
    183
    Blog Entries
    1
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    0
    Quote Originally Posted by itod View Post
    Can you please remove those yaw-discrimination from your code 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.

  4. #4
    Moderator AeroQuad Technologist Honk's Avatar
    Join Date
    Apr 2010
    Location
    Stockholm
    Posts
    5,442
    Blog Entries
    2
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    1
    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.
    Smart people don't need a signature.
    http://thechive.files.wordpress.com/...rd-signs-3.jpg

  5. #5
    Senior Pilot CupOfTea's Avatar
    Join Date
    Apr 2010
    Location
    New Zealand
    Posts
    183
    Blog Entries
    1
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    0
    Quote Originally Posted by Honk View Post
    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?

  6. #6
    Moderator AeroQuad Technologist Honk's Avatar
    Join Date
    Apr 2010
    Location
    Stockholm
    Posts
    5,442
    Blog Entries
    2
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    1
    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.
    Smart people don't need a signature.
    http://thechive.files.wordpress.com/...rd-signs-3.jpg

  7. #7
    Senior Pilot lokling's Avatar
    Join Date
    Jul 2010
    Location
    Oslo, Norway
    Posts
    512
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    0
    Quote Originally Posted by CupOfTea View Post
    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/
    Beware of programmers who carry soldering irons

  8. #8
    Senior Pilot itod's Avatar
    Join Date
    Sep 2010
    Location
    Belgrade, Serbia, Serbia
    Posts
    731
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    0
    Good read lokling, going through it whole morning and not finished yet

    Quote Originally Posted by CupOfTea View Post
    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 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) 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?
    Last edited by itod; 12-05-2010 at 12:26 PM.

  9. #9
    Moderator AeroQuad Technologist Honk's Avatar
    Join Date
    Apr 2010
    Location
    Stockholm
    Posts
    5,442
    Blog Entries
    2
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    1
    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.
    Smart people don't need a signature.
    http://thechive.files.wordpress.com/...rd-signs-3.jpg

  10. #10
    Senior Pilot CupOfTea's Avatar
    Join Date
    Apr 2010
    Location
    New Zealand
    Posts
    183
    Blog Entries
    1
    Downloads
    0
    Uploads
    0
    Reputation Points (Add)
    0
    Quote Originally Posted by Honk View Post
    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.


 
Page 1 of 6 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •