Hi guys, first time I try the camera gimbal stuff (yeah I am overdue but fixed camera was fine until now)
I am trying to follow the wiki instructions, the new MP screen for the config seems simple enough...
My issue is that when all connected to port 10 and 11 on APM2.5 the servos twitch constantly. With or without CH6 connected to make the camera pitch (yes Ch6 assigned to a rotary switch and MP Radio config redone) How do you guys have it configured for regular 9g servos (analog)?
I tried to play with the min / max and angle but not fun. The gimbal roll and pitch when the frame is moved but there is constant jitters (very fast and a lot) on the entire gimbal. Also when I have CH 6 connected it will not stabilize camera pitch anymore, it will be only manual on control. Very strange.... I was expecting to be able to "take over" with CH6 then give back control to the APM to stabilize.
Anyhow, please help me (it's for a customer, not even for me!)
Having the same problem here. I'm om APM 2.5 (2.7.3 tri). When i select input ch in MP (CH6,7 or 8) i get small random jitters. If i try to connect my Rx to the APM input ch, the whole mount goes haywire randomly changing positions. I have also gone through the camera wiki, and all my settings look good.
Another problem is when trying to setup 3-axis. I enable PAN in the MP and the roll and pitch seem to be switched. Roll becomes pitch and vice versa?
Any help would be greatly appreciated
#NOTE: 23-09-2012 00:26:40 Frame : tri
Ok, i've heard a little about these types of problems so it would be good ot get to the bottom of them.
So jitters must be caused by one of a few things:
1. analog servos can't handle the high update rate. Probably only applicable if you've got your camera servos attached to the 5~8 pins on the back of the APM2 because those run at 490hz while 10 and 11 on the side of the APM2 run at 50hz (I believe). This doesn't sound like the case in your situation 'cuz you're using 10/11.
2. pwm output to the servos is just moving around too much and we need to filter it. We've got this AP_Filter library that makes it quite easy to add standard filters to stuff. If I knock up a slightly modified version of the latest code you know how to download it from git?
3. something else unforseen! :-)
Re CH6....that's weird..it should mix together your input from ch6 to the stabilize output from the apm2. I'm sure I tested that before the 2.7.3 release...Can you check that your MNT_MODE is 3?
By the way, the mission planner's gimbal screen has been updated so we should probably try to do the set-up through that screen. If it doesn't work I'm sure michael Oborne will fix it for us in a heartbeat. I will retest it again with the trunk code shortly.
I just tested again using trunk and the mission planner's gimbal set-up screen and it all worked ok. So that means it can work..now we just need to narrow in on why it's not working on your set-ups.
It looks like maybe your radio inputs for channel 6~8 have not been initialised through the mission planner's Radio Calibration screen. Ch6 is what most people use for their pitch control so could we try using that as a first step?
Also let's get the roll + tilt working first so could you disable the pan which you have connected to output channel 8 for the moment?
thanks for including your parameter list by the way. very helpful!
Hi Randy, pheew fast response, Thanks
Ok, got the pitch/roll adjustment working now with ch6/7, I forgot to calibrate it in radio calibration.. doh
I am using 3 small Fusonic MG-D-9G 0.12sec digital servos. I am seeing a bit of latency on fast movements, so i might have a go with a 0,06sec servo later.
I also figured out why my pitch/roll were swiched when enabling pan. First off i had the pan servo connected to the rc8 right beside rc11/10 instead of the output channel 8.
In the MP standard params the MNT_MODE was set to RC_targeting, resulting in the gimbal wanting to point north all the time. My copter is on my desk pointing east. This must have confused the mount. I was waiting for the pan axis to do some sort of smooth stabilization feature on quick yaw movements. Maybe this can be implemented?
Not so familiar with git and custom firmware yet, but i will give it a try some day if necessary.
I have my gimbal setup jitters too. I've connected to APM Ch10-Ch 7 & Ch11-Ch 8 on a Turnigy 9XR with Frsky Tx,Rx pair. How was the twitching resolved with Henrik.
My servos are 9g analog from HobbyKing. Stabilize works and so does variable Pot inputs on Ch7 & 8. It is just the Jitters/twitching that is a problem. The output rail is at 5.8V.
Is there a way to lower the 50Hz on Ch10 & 11?
Is there any code for smoothing the outputs for the servos? I found a person that has a small code snippet that does a timed average - http://rl337.org/2012/01/11/smooth-analog-input-class-for-arduino/
No, there's no way to lower the 50hz on output channel's 10 and 11. If you're up for some programming you could try to add a smoother in the AP_Mount library's AP_Mount.cpp's update_mount_position function.
I have Interesting results from a quick test.
I'd read from someone (you?) regarding the telemetry radio line interfering with the gimbal motors.
I found it is not within the line but from the radio circuits on the pcb. I placed my hand over my 900MHz radio board on the quad and the camera servo jitters stopped. I removed my hand, etc.... Several times. With the same results. So, if we place a shield over the radio board many jitters will go away.
Solution: RFI Shielding
I wrapped the telemetry pcb with several wraps of plastic food wrap to protect the circuits from shorting against the shielding. I then installed a single wrap of aluminum foil as an RF shield and secured with tape.
Testing: After connecting the quad to power and waiting for all circuits to initialize the servo motors were not twitching. There is a few sporadic twitches in a minute now from bursts of telemetry data between the GCS and vehicle. But, these twitches are very small and do not last. The GCS receives GPS, battery, current and HUD information from the quad. The Tx and Rx have not been affected and the servos respond rapidly and smoothly to instructions from the Tx. :-)
Results and Recommendation:
Problem understood and solved. Use RF shielding on our radios. We should be diligent and quick to build our UAV(s) and then put the radio devices into properly shielded enclosures.
ok, wow. We seem to hit EMI issues fairly often. I've seen other radio issues on the 3.0 thread just now caused by a camera. I guess that this is part of dealing with a wide variety of parts that people are using.