Mysterious problem with camera pitch.

VCD

Joined
Nov 7, 2016
Messages
165
Reaction score
47
Age
44
I have+know at least four Solo's with this issue.
OpenSolo 3.0.0 , ArduCopter 3.5.7.

The problem;
The camera pitches up, at 3second interval, with logarithmic steps.
It does so if the last input was a slight "up" (look up) command, not if the last was down.
- not sure if it's related, but the actual camera motion is within 0...60° , 61...90 has no effect.

What I tried:
I observed the pot output using runStickcal.sh , and it seems perfectly healthy.
I did check the controllers, and swap one potentiometer, it did not help. (5kOhm pot that senses the camera pitch input)
Used the command sololink_config --set-ui-sweep 0 90
I did a factory reset on the controller.


Facts:
The graph below illustrates the problem, I have the camera looking down (red line down, 1000us on RC6) , then let ut up a bit using the paddle, then it keeps on increasing every 3 seconds, in logarithmic steps, until it's looking forward (90°)
So the Cube, (which control the gimbal over mavlink, MNT_TYPE=2) recieves that RC command, and forwards it to the gimbal (MNT_RC_IN_TILT=6)
If it was the potentiometer or A/D that caused that "pulse" (every third second), it should be seen during runStickcal.ch , but it's not , the stickcal values are perfectly smooth.

Screenshot from 2018-11-07 15-46-28.png


This is how it looks:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
Last edited:
First, you'll get more attention leaving out the master reference. I can't recall anyone going by that name here, maybe on FB however....

Can't say I've seen exactly that before. But I have experienced an issue with the tilt paddle having a mind of its own. I'm sure you've already done the obvious, check connectors, wires and solder points for issues in the controller.

From my experience, I blew out the tilt paddle with 100psi compressed air, basically operating the paddle and hitting every crevice both inside and out of the controller. This appeared to be the fix for what I was dealing with. I figured something got lodged or a fuzzy bunny was shorting a contact.

Maybe it's complex like you've displayed, but stuff does happen that resolves with simple solutions... Good luck!
 
I get your suggestion that this is some dirt, a precisely timed dirt.
This is the full story what I tried before posting here:
I swapped the potentiometer, (also opened it up after desoldering, it is really simple, the resistive surface was and unscratched and clean. (checked under a microscope)
(The ALPS gimbal under the paddle uses only one of the two potentiometers)
When I did calibration , I observed the AD input: it starts off with similar min/max AD/Values, for example, 5500:5510 - is rock solid.

then I do some careful, minimal inputs. let's say it changes to 5300:5600. .. still stable AD data, regardless of the last direction.
I complete the calibration, and there is no way to cause this big changes to the attitude by moving the paddle as little as I did in the previous step, whatever happens, every third second is much faster than that.

do you have a clue what can cause the gimbal to move just between 61..90° ? - not 0...60 ? mavlink data shows perfectly smooth PWM change, even at low rate.
 
The problem has to be on the controller. There is no manipulation of the RC channel outside the Artoo code. So I think you can safely rule out a problem on the Solo (pixhawk, IMX, gimbal, etc). I don't anywhere programatically that can cause this, either in how the stick is read or in how it is transmitted to the Pixhawk. Which leads me to believe it's a hardware problem. I'm not sure what to suggest that hasn't already been done though.

Did you actually do the stick calibration procedure, moving all the sticks and paddle to their maximums? Or did you just observe the output? If the former, do the full stick calibration.

The gimbal paddle has a hard coded deadzone of 250us as shown here (OpenSolo/artoo). So even a little bit of dirt shouldn't be causing enough stick jitter to actually move anything.
 
Yes, I re-did the calibration several times, in relation to the fact that the problem is not there if last input was "pitch down" - I also tried to have different last directions when calibrating.
I agree that it "should be" a controller problem.
the three-second interval is a complete mystery that is very difficult to explain.
I did not mention this not to confuse people, if the last movement is down, this won't happen... actually, if I pitch fully down (0°) , then up to 1..2° this will still not happen, only after 3° ... this drives me crazy.
is there a debug method to see what input the controller is sending to Solo ? - (w/o compiling)
 
Based on the video alone, it appeared the controller indicated the change and then the gimbal tilt followed. The only exception was at the end when it went full 90 and then the controller lagged to the indication.

Recalling back to my fix. The other component was the gimbal sweep preset dial and buttons. I blew those out as well. If I recall correctly, the buttons were gritty and then the wheel (time) was indicating sporadically when moved. FWIW, You can stop the preset sweep by depressing the opposing same button mid travel. And then also you can go past the preset stop by again pressing the directional preset button. I'd give preset input a look over.

Also noticed, your preset 1 is set at 32 and then 2 is set to 89. Not sure that is a factor, seems counter intuitive being reversed, 1 is up and 2 is down for how I've used the presets.

Edit to correct which button
 
Last edited:
Sweep is programmed randomly as I checked whatever it influenced the situation in any way.
The gimbal is "scaled" to move/respond to 0..60° , not 0..90° , the camera is 90° when the controller indicates 60° .
Fun fact: if I control the gimbal in air over mavlink, it is perfectly precise (so the gimbal itself, can look at 70° , and actually know that it is pointing at 70° just fine.)

Today I tried another controller.. for precise comparsion, it's exactly the same, ... 3seconds , and 0...60° - reinstalling OpenSolo 3.0.0 right now..
 
WOW ! - reflashed OpenSolo issue is gone ! , scaling is 0..90° , like it should be...
will compare parameters & firmware for clues..
 
Fun fact: if I control the gimbal in air over mavlink, it is perfectly precise (so the gimbal itself, can look at 70° , and actually know that it is pointing at 70° just fine.)

Today I tried another controller.. for precise comparsion, it's exactly the same, ... 3seconds , and 0...60° - reinstalling OpenSolo 3.0.0 right now..
Wow, that is really interesting. This technical stuff is way over my head...I see it as magic...;)
WOW ! - reflashed OpenSolo issue is gone ! , scaling is 0..90° , like it should be...
will compare parameters & firmware for clues..
This will be interesting, how can a parameter change without input....
 
This has something todo with the fact that I upgraded AC3.5.4 -> AC3.5.7
It's no longer on ArduPilot firmware : /Copter , does somebody here have proper firmware
what I have , I renamed to ArduCopter-v3-3.5.7.px4
md5sum a20fec66527ab12d81a09c8208186422
 
I don't have a 3.5.7 version with Solo's defaults baked in online anywhere. But you can get the 3.5.4 version with Solo's defaults baked in (included with Open Solo) from our github. Right click save as on the raw button. OpenSolo/documentation. After installation, I suggest doing a parameter reset to default. You'll need to redo you level and compass calibrations afterwards.
 
I no not need solo defaults baked in, can restore or compare, and base on backup from clean openSolo with 3.5.4 - it's just the 3.5.7 I have that I am not-so-sure about anymore..
 
If you're comfortable doing that, then you'll need to use the previous versions function of Mission Planner's firmware installer. The older 3.5.7 compiled px4 file is not readily available for download elsewhere I know of.
 
no problem, I can just compile it myself.
Do you know anybody that is looking into 3.6 compatibility problems with Solo (Artoo ?)
 
no problem, I can just compile it myself.
Do you know anybody that is looking into 3.6 compatibility problems with Solo (Artoo ?)
Why yes. Me. :)

Just got home from work. It's pouring rain (again), so no yard work to do. So instead I'm compiling Copter 3.6.1 stable, with solo parameter defaults baked in, and getting it up to Solex and Side Pilot. The package will include some updated files for the python files for the IMX too. Should be up in a few hours. The above will all eventually be part of the next full open solo release. I'm just really hoping to get the slew rate and ChibiOS stuff into that too, so waiting game.
 
  • Like
Reactions: Saijin_Naib
Fantastic, please tell where you upload the files, I'll test it.
 
Wow, that is really interesting. This technical stuff is way over my head...I see it as magic...;)

This will be interesting, how can a parameter change without input....

It does it by operating on Murphy’s Law of Mechanical devices , which is if it can fail or f@&k up it will.
 

Members online

No members online now.

Forum statistics

Threads
13,093
Messages
147,741
Members
16,047
Latest member
pvt solo