Is the camera control functioning in the MP-H?

[Marc-X]

Hello,

Do you HAVE to assign input channels for the camera axis that you want
to use for stabilized flight?

I tried to assign camera output channels only, but that did no good.
Only when I assign an input channel for direct camera control, it will
follow the movements of the UDB in stabilized mode, otherwise it
doesn't move at all. Is this by design, or a "flaw"? Wouldn't it been
nice if at least the camera TILT worked in stabilized mode without any
input channels assigned to have it point at a suitable angle to look
forward. Panning in stabilized mode is of no use, neither is roll as
long as the camera doesn't track an object.

Cheers!

Marc

[Marc-X]

Hello again,

I have now tested the current MP-H code with camera stabilization
active. It looks rather "shaky". I'm now starting the process of
porting the code to MP3.x format.
My understanding to how the camera control works TODAY is that you
HAVE to have an input channel assigned to each axis you will have
movement in regardless of mode (STABILIZED or MANUAL)? Is this correct
or have I damaged something when poking around in the code?

Cheers!


/Marc

[John McClelland]

Marc

As stated in the MP-H documentation, ONLY roll/pitch stabilization is
currently supported in the code. MP-H started with MP 2.0 and I just turned
off or noted in options.h other options (like camera stabilization) that
were not supported AT THIS TIME. Note also that the camera code is whatever
was in MP 2.0 and I'm sure it has progressed a lot since then. It may work
in the old mode, but I have not tested it, so did not say it was supported
at this time. It could be updated, but would be good to know what has
changed and how extensive the changes would be.

Bill and I have been working on Heading Hold with a magnetometer for yaw
stabilization and we have made good progress but weather has stopped test
flights for now. I expect to include HH in the next release of MP-H.

Serial output is supported for debug. It should not be a big deal to update
to include whatever telemetery is needed now.

The roadmap and thoughts on navigation in the documentation describe our
plans to impliment waypoint navigation for helis once we have all the basics
working. The MP airplane code will not work for helis.

In reading the threads I was surprised to hear you are launching off to
migrate MP-H into the most recent MP code (perhaps I got this wrong). I am
not sure this is the most efficient thing to do at this point. There are a
lot of fundamentals that need to be addressed. I spent A LOT of time
converting our original heli code to MP 2.0. I would not do that agian
until we have thought things out much more. Of course, you are free to do
what ever you want...I may not be much help to you if the codes diverge
much. Just think a more coordinated approach would be best in the long run.

Best,
John

[Marcus Fahlén]

John,

Camera issue first:

I just wondered if the camera was supposed to work the way it does
here on my bench (no gyro compensation without assigned input
channels).

Code base:

I was of the impression that there was an coordinated move towards the
new style (libUDB and libDCM) for the heli development as well as
fixed wing. I started to try to implement HIL simulation suport in the
current (MP_H_V2) heli code when someone told me that migration to the
MP3.x was the right way to go. I took this as a challenge and
opportunity to learn a bit of C-coding and started to look at the
project from that point of view and what was involved.

I have no intentions to step on your (or anybody else's) toes by
pulling away from a planned route, I just started to do what I thought
was according to the main plan. I have posted dozens of questions /
remarks regarding this without any opposition until now.

As I said, I was of the impression that porting to the "new" 3.x style
would make development of the heli code much easier, and integration
of the different new modules (Peters camera routines for example) more
painless..

Now I don't know what to do, but I have another "issue" to hammer
flat, so I can deal with that for a while instead...

Best regards

/ Marc

[Marcus Fahlén]

John,

First of all, I want to wish you a happy new year and I hope you had a peaceful X-Mas.

What I want to ask you is if you could help me a little with modification of the MP_V2 camera code?

Today gyro stabilization of the camera demands that you have one rc channel assigned for each axis that is to be stabilized.

Since there is no support for PPM input the number of inputs is severely limited. (5) That means I can't offer two rc channels to have gyro stabilization of the camera. It must be possible to use a constant instead of the PWM of an rc channel?

What I want to do is modify the "cameraCntrl.c" so that it takes a defined value as input instead of the PWM values

of the "CAMERA_PITCH_INPUT_CHANNEL" and "CAMERA_YAW_INPUT_CHANNEL".

I have tried to hack the file, but my limited C-skills makes the progress not very promising:

I defined two constants for PITCH and YAW:

#define CAMERA_PITCH_FACTOR 1500

#define CAMERA_YAW_FACTOR 1500

Then I tried to use them instead of the PWM from the CAM_AXIS_INPUT_CHANNEL: 

// cam.WW = REVERSE_IF_NEEDED(CAMERA_PITCH_CHANNEL_REVERSED, __builtin_mulss( rmat[7] , camera_pitchkp )) ;

// pwOut[CAMERA_PITCH_OUTPUT_CHANNEL] = pulsesat(pwIn[CAMERA_PITCH_INPUT_CHANNEL] - cam._.W1) ;

cam.WW = REVERSE_IF_NEEDED(CAMERA_PITCH_CHANNEL_REVERSED, __builtin_mulss( rmat[7] , camera_pitchkp )) ;

pwOut[CAMERA_PITCH_OUTPUT_CHANNEL] = [CAMERA_PITCH_FACTOR] - cam._.W1) ;

This obviously doesn't work. Could you help me a little and point me in the right direction to do what I want to achieve? (Having gyro stabilized camera with STATIC input values instead of PWM from a RC channel)

Best regards

/ Marcus     

[Marcus Fahlén]

John,

I actually solved it by studying and then manipulating the "radioIn.c" this way:

I added the following lines of code:

I defined the "CAMERA_GYRO_ONLY" constant in "options.h"

#if (CAMERA_GYRO_ONLY == 1)

pwIn[CAMERA_ROLL_INPUT_CHANNEL] = pwTrim[CAMERA_ROLL_INPUT_CHANNEL] = 3000 ;

pwIn[CAMERA_PITCH_INPUT_CHANNEL] = pwTrim[CAMERA_PITCH_INPUT_CHANNEL] = 3000 ;

pwIn[CAMERA_YAW_INPUT_CHANNEL] = pwTrim[CAMERA_YAW_INPUT_CHANNEL] = 3000 ;

#endif

and finally set the following in "options.h":

#define CAMERA_ROLL_INPUT_CHANNEL CHANNEL_UNUSED

#define CAMERA_PITCH_INPUT_CHANNEL CHANNEL_UNUSED

#define CAMERA_YAW_INPUT_CHANNEL CHANNEL_UNUSED

This way I now have a working gyro stabilized camera without using any radio channels for it to work.

If you see anything that might give me unwanted side effects, please shout out!

Cheers!

/ Marc 

[Marc-X]

Followup:

I have now moved the camera code out from the "radioIn.c" and placed
it in modified form in "cameraCntrl.c" instead. Looked like it "fits"
better there.
Overall I'm satisfied with the result. I have some strange YAW
behavior, but I can't say anything for sure since my UDB has a
drifting yaw gyro.
The problem is that after a while the YAW compensation changes
direction. It's like I switch the "REVERSE_SWITCH".
Looks almost like a variable overflows and flip sign.
This ONLY happens in the YAW axis. The PITCH works perfectly booth
with and without radio channel assigned or input.
There is also an unwanted yaw when the pitch exceeds 45 degrees. I
guess that this is inherited from the very early cameraCntrl.c
I.I.R.C there were some yaw "issues" in MP2.0. I know that Peter did a
heavy makeover in MP2.5, and an even heavier one in MP3.x
I tried to use the MP2.5 camera routines, but there were too many
changes needed for my C-skills so I let it be for the moment. I guess
that you are working on the camera code as well as the rest of the MP-
H code.

Cheers!


/ Marc

On Jan 1, 4:36 am, Marcus Fahlén <marcus.fah...@gmail.com> wrote:
> John,
>
> I actually solved it by studying and then manipulating the "radioIn.c" this
> way:
>
> I added the following lines of code:
>
> I defined the "CAMERA_GYRO_ONLY" constant in "options.h"
>
> #if (CAMERA_GYRO_ONLY == 1)
> pwIn[CAMERA_ROLL_INPUT_CHANNEL] = pwTrim[CAMERA_ROLL_INPUT_CHANNEL] = 3000 ;
> pwIn[CAMERA_PITCH_INPUT_CHANNEL] = pwTrim[CAMERA_PITCH_INPUT_CHANNEL] = 3000
> ;
> pwIn[CAMERA_YAW_INPUT_CHANNEL] = pwTrim[CAMERA_YAW_INPUT_CHANNEL] = 3000 ;
> #endif
>
> and finally set the following in "options.h":
>
> #define CAMERA_ROLL_INPUT_CHANNEL CHANNEL_UNUSED
> #define CAMERA_PITCH_INPUT_CHANNEL CHANNEL_UNUSED
> #define CAMERA_YAW_INPUT_CHANNEL CHANNEL_UNUSED
>
> This way I now have a working gyro stabilized camera without using any radio
> channels for it to work.
>
> If you see anything that might give me unwanted side effects, please shout
> out!
>
> Cheers!
>
> / Marc
>

> >> > ----- Original Message ----- From: "Marc-X" <marcus.fah...@gmail.com>

[Marcus Fahlén]

Update on the camera modification:

I have now made a few minor changes to the code. Most noticeable is that there is no need to specify which channels you want to to stabilize without an input channel. It reads the channel configuration from the standard set of channel definitions in "options.h"

I have also tried to make the camera servos ignore the "SERVOSAT" setting. My setting limits the swash servos to 65%, but also limits the camera movement with the same amount. I have now made a "fix" for this which works well for the YAW axis, but not for PITCH. I am working on solving this.

The "issue" with yaw "lockup" that I wrote about earlier is no "issue". It's a natural consequence of how the camera routine and DCM works, and the fact that I don't have a magnetometer in my setup. This makes the DCM unaware of the nose attitude and thereby offsets the camera with yaw drift.

(This is a private initiative in the meantime waiting for a new "official" release of MP-H. Nothing written herein is endorsed by the established development team.)   

I hope to get someone else to help me working on this. If you are interested I have a repository where you can get the modified source.

The source is clearly marked where it diverges from the "stock" version. There is also a "fix" for the "868 MHz Xbee DC problem" in this code. Mail me for the URL.

/ Marc