AHRS_ORIENTATION option - mount your APM/PX4 in any orientation

[Andrew Tridgell]

Hi All,

I've pushed a new AHRS_ORIENTATION option to master. I added this
because its needed to support the PX4 in different orientations than the
standard one, but it works with any APM1 or APM2 as well.

Basically set AHRS_ORIENTATION to the orientation of your board and
reboot and re-level your vehicle. We support 26 orientations currently,
including a lot of 45 degree orientations. We can add more if needed.

See the docs here for a list:

https://code.google.com/p/ardupilot-mega/wiki/APM_Parameters#Board_Orientation_%28AHRS_ORIENTATION%29

(we really need to move that to github!)

For the PX4FMU without an IO board I find orientation 8 (ie. Roll180)
most convenient. That has components up.

Cheers, Tridge

[Robert Lefebvre]

Tridge, will this option apply to Arducopter as well?

--

[Randy Mackay]

     I'd say yes but I think we need to check the rate controller's because they work directly off the AP_InertialSensor library and that may not be being rotated by tridge's stuff.

-Randy

---

From: Robert Lefebvre <robert....@gmail.com>
To: drones-discuss <drones-...@googlegroups.com>
Sent: Wednesday, February 13, 2013 8:39 AM
Subject: Re: [drones-discuss] AHRS_ORIENTATION option - mount your APM/PX4 in any orientation

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andrew Tridgell]

Hi Randy and Robert,

yes, this should work on ArduCopter, although it would be good if
someone could give it a test! I've flown it with ArduPlane with an
upside down board, but not with copter or rover.

> I'd say yes but I think we need to check the rate controller's
> because they work directly off the AP_InertialSensor library and that
> may not be being rotated by tridge's stuff.

The AP_InertialSensor is rotated by the AHRS_ORIENTATION setting. The
compass is also rotated. So it should all "just work".

Note that you need to recalibrate your accels after changing this
setting. A reboot would also be prudent :-)

Cheers, Tridge

[Robert Lefebvre]

Good thing you mentioned compass orientation, because I always use an external compass, which would have a different orientation.  I have used the mag orientation #defines, will they continue to work?  What is the interaction in the code between the two orientations?

[Andrew Tridgell]

Hi Robert,

> Good thing you mentioned compass orientation, because I always use an
> external compass, which would have a different orientation. I have used
> the mag orientation #defines, will they continue to work? What is the
> interaction in the code between the two orientations?

both rotations are applied. The orientation in the #define is applied
before the board orientation.

I think we should add a mavlink parameter for compass orientation as
well. It shouldn't be necessary to build APM yourself just because you
use an external compass. Maybe you'd like to add a feature request in
the issues?

Cheers, Tridge

[Robert Lefebvre]

Sorry, little confused by what you wrote.  Both rotations are applied....

Ok, lets say I was to mount the APM with right way forward, but the left side vertical down, right side is vertical up.  Basically rolled 90° on it's left side.  Then, as typical, I would mount the external Mag with the components up, pins forward.

Would I do a #define mag_orientation components_up_pins_forward?  And then adjust the mavlink parameter to reflect the position of the board?

Or are you saying that I would need to do something different with the Mag #define to virtually rotated it back to components up pins forward, because the board rotation parameter also rotated?

Yeah, I can do a feature request.

[Andrew Tridgell]

> Or are you saying that I would need to do something different with the Mag
> #define to virtually rotated it back to components up pins forward, because
> the board rotation parameter also rotated?

yes ... both are applied as the "mag orientation" is usually used to
define the orientation of the component on the board, so if the board is
rotated then the component rotates too.

> Yeah, I can do a feature request.

yes please :)

Cheers, Tridge

[buzz]

Hi All,   (especially tridge)

regarding and AHRS_ORIENTATION .... you mentioned that after changing it, the user should " reboot and re-level your vehicle." ....

I'd like to know if that is strictly necessary, or "just a good idea", because I'm thinking about this as a good way to support for "transitioning vehicles"  that can fly in both the vertical orientation ( typically for takeoff ) and the horizontal orientation ( for sustained flight ).      

Airframes able to take advantage of this might include the following, as they all "transition" ( ie the core airframe changes angle significantly during different flight modes ) :
http://en.wikipedia.org/wiki/Convair_XFY-1
http://en.wikipedia.org/wiki/Lockheed_XFV-1
http://en.wikipedia.org/wiki/X-13_Vertijet
http://en.wikipedia.org/wiki/Heinkel_Lerche

"QuadShot"  - http://www.youtube.com/watch?v=IK_-yTrwNtU'

"Atmos" - http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A968167&commentId=705844%3AComment%3A969002
Coléoptère - http://www.airspacemag.com/history-of-flight/Meet-The-Beetle.html#

and I'm sure many others. 

And, as a bonus, it could also be used to support classic 3D acrobatic RC planes that support doing a "prop hang" manoveur ( eg: http://www.youtube.com/watch?v=1c-aQGJuOLA ) , which would be very exciting to be able to do something like this autonomously.

Yes, I'm probably talking a ArduPlane/ArduCopter hybrid with a couple of those examples there, but on the PX4, the hardware is no longer the limiting factor, is it. :-)

Buzz.

--

[Andrew Tridgell]

Hi David,

> I'd like to know if that is strictly necessary, or "just a good idea",
> because I'm thinking about this as a good way to support for "transitioning
> vehicles" that can fly in both the vertical orientation ( typically for
> takeoff ) and the horizontal orientation ( for sustained flight ).

You'd need some extra code for this to work. In particular, you'd need
to rotate the calibration vectors for the gyro, accel and compass. That
isn't hard (just use the rotate method on Vector3f), so you certainly
could do it in-flight that way.

> And, as a bonus, it could also be used to support classic 3D acrobatic RC
> planes that support doing a "prop hang" manoveur ( eg:
> http://www.youtube.com/watch?v=1c-aQGJuOLA ) , which would be very exciting
> to be able to do something like this autonomously.

I think prop-hang and knife-edge could be better supported other ways. I
have been thinking about those a bit lately, and I think that is needed
is a better set of attitude controllers that don't rely on euler
angles. Instead we'd have a target rotation matrix, and code that works
out how each body frame axis needs to change to move to the new
rotation, which then would feed the servos.

I also think this approach could improve normal non-acro flight. Using
euler angles is very convenient for humans, but isn't great for real 3D
flight.

Basically it would work by looking at our current attitude (as a
rotation matrix) and position (lat/lon/alt) and a target attitude
(another rotation matrix) and position, plus a time to get to the new
attitude and position, then the APM would work out a plan for getting
from the current attitude/position to the new attitude/position based on
what rotational rates about each axis the control surfaces can produce.

If you take this a step further then you can imagine it being used for
multicopters too. A rotor is just a source of thrust+torque.

Cheers, Tridge

[buzz]

I think that having a mixing strategy that lets the airframe implementer describe how much a certain channel or source of data X has control over rotation, for a given body angle Y ( or attitude angle Y in earth frame, if that helps )  would be flexible enough to support just about anything.

eg1:  In a classical shape airframe at normal attitudes and speeds, the ailerons controls (say) 95% of roll ( in earth frame ) , and engine RPM controls 5% of roll ( torque roll in opposite direction).    In a "prop hang" scenario, the earth-frame change means that "roll"  ( in the earth frame) is controlled almost entirely (100%) by rudder ( prop airflow over rudder tilts airframe left-right a bit ) , and engine rpm controls altitude ( 100%) as well as the efficacy of the tail surfaces ( perhaps as a 20% mix ) , and the ailerons only act as anti-torque and yaw surfaces ( 99% mixing to yaw, where 1% is from rpm)?

Yes, all of these control mixings have much different behaviour in different attitudes, so there would be a need for the implementer of the aircraft and/or design to build a mixing table for any major airframe types, but then Quads and Planes and transitioning vehicles could use the same underlying control behaviours.

did I just make sense to anyone, it makes sense in my head.   :-)

Buzz

[Randy Mackay]

     I believe that james goppert tried to do something like that with the APO stuff.  I'm a bit skeptical that trying to abstract it that far is really helpful.  At some point the method used to capture the differences is just as complex as having two separate programs.

-Randy

---

From: buzz <davi...@gmail.com>
To: Andrew Tridgell <tri...@samba.org>
Cc: drones-...@googlegroups.com
Sent: Monday, February 25, 2013 4:23 PM

Subject: Re: [drones-discuss] AHRS_ORIENTATION option - mount your APM/PX4 in any orientation

[buzz]

Hi, Randy,

How would you propose supporting the following then:  a quad/plane hybrid (  which currently would require ArduCopter and ArduPlane to be mashed together ) , or some sort of single-prop aircraft that can "prop hang", and then behave somewhat like a coaxial helicopter?

Buzz.

[Jonathan Challinger]

On Tridge's note, Bill Premerlani has frequently recommended against using euler angles at all.

I'm not 100% sure how to do that, but I suspect a look at matrixpilot would tell us.

[Randy Mackay]

     I should clarify my position though that when I said, "i'm skeptical..." I meant I'm skeptical about the old APO stuff which tried to mash everything together including user input, main loops, etc into one big program.  I agree that there's more sharing we could do across planes and copters if that's what you're getting at.

     for the specific case of the copter and looks like a box kite and can fly sideways, I think that one is much more like a copter so I'd extend the copter code.  For the planes that can land vertically, i think they're basically planes with a special trick when it comes time to land...so i'd use the plane code.

     ..but not trying to be a downer...i'd be very happy if someone with more imagination than me can come up with an elegant method to capture the differences in apparently very different airframes to allow us to bring it together more.

-Randy

---

From: buzz <davi...@gmail.com>
To: drones-...@googlegroups.com
Sent: Monday, February 25, 2013 5:37 PM

[buzz]

my imagination says that in the same way we can proportionally increase aileron throw to account for lower aircraft speed, we could proportionally mix other more complex systems to account for all these kinds of behaviours.    

the key is determining what source data could possibly be relevant for all mixings:, beyond all the usual position/velocity/attitude/acceleration data, the only other things I can see that might need "mixing" are the RC inputs.     I'm no expert but I think other sensors like airpeed and rpm would best be left out of this, as their primary purpose is to make sure the AHRS is correct.

I think each mixer would be critically tied to a primary data source ( such as speed or an attitude angle) , and as that one changes, the mixer would follow.  we are already comfortable with mixing tables for Quad/Hexa/Octa/H/T/+/X/Tri  layouts in copters.  ( for the math, see here: http://paparazzi.enac.fr/wiki/RotorcraftMixing )

I guess I'm proposing that instead of limiting the math to computing the needed "throttle commands for each of the motor controllers.", we could do all control surfaces on all aircraft types?   Maybe.

[buzz]

Actually... can the PX4 built-in mixing already do all of this?        

Lorenz,    Could I setup a PX4 native mixer so that it mixed the control surfaces differently based on the the current *attitude* of the airframe?   Is this available in the PX4 mixer?   ( eg, for prop-hang type scenario? )

[Meier Lorenz]

What you can certainly do is to allow an output driver to load two mixers and blend between them. I think it boils down to how exactly the attitude influences mixing. However, I keep thinking that you need to do this in the controller, since its so vehicle dependent (not only on attitude, but also on speed, amongst other things I can think of). If you fly with a transitioning rotorcraft at 45 degrees pitch its not clear if you're trying to be a quad leaning against the wind or if you're an airplane trying to gain altitude quickly.

-Lorenz

------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/



On Feb 25, 2013, at 11:05 AM, buzz <davi...@gmail.com<mailto:davi...@gmail.com>>
wrote:

Actually... can the PX4 built-in mixing already do all of this?

Lorenz, Could I setup a PX4 native mixer so that it mixed the control surfaces differently based on the the current *attitude* of the airframe? Is this available in the PX4 mixer? ( eg, for prop-hang type scenario? )

On 25 February 2013 19:58, buzz <davi...@gmail.com<mailto:davi...@gmail.com>> wrote:
my imagination says that in the same way we can proportionally increase aileron throw to account for lower aircraft speed, we could proportionally mix other more complex systems to account for all these kinds of behaviours.

the key is determining what source data could possibly be relevant for all mixings:, beyond all the usual position/velocity/attitude/acceleration data, the only other things I can see that might need "mixing" are the RC inputs. I'm no expert but I think other sensors like airpeed and rpm would best be left out of this, as their primary purpose is to make sure the AHRS is correct.

I think each mixer would be critically tied to a primary data source ( such as speed or an attitude angle) , and as that one changes, the mixer would follow. we are already comfortable with mixing tables for Quad/Hexa/Octa/H/T/+/X/Tri layouts in copters. ( for the math, see here: http://paparazzi.enac.fr/wiki/RotorcraftMixing )

I guess I'm proposing that instead of limiting the math to computing the needed "throttle commands for each of the motor controllers.", we could do all control surfaces on all aircraft types? Maybe.

On 25 February 2013 19:16, Randy Mackay <rmac...@yahoo.com<mailto:rmac...@yahoo.com>> wrote:

I should clarify my position though that when I said, "i'm skeptical..." I meant I'm skeptical about the old APO stuff which tried to mash everything together including user input, main loops, etc into one big program. I agree that there's more sharing we could do across planes and copters if that's what you're getting at.

for the specific case of the copter and looks like a box kite and can fly sideways, I think that one is much more like a copter so I'd extend the copter code. For the planes that can land vertically, i think they're basically planes with a special trick when it comes time to land...so i'd use the plane code.

..but not trying to be a downer...i'd be very happy if someone with more imagination than me can come up with an elegant method to capture the differences in apparently very different airframes to allow us to bring it together more.

-Randy


________________________________

From: buzz <davi...@gmail.com<mailto:davi...@gmail.com>>
To: drones-...@googlegroups.com<mailto:drones-...@googlegroups.com>

Sent: Monday, February 25, 2013 5:37 PM

Subject: Re: [drones-discuss] AHRS_ORIENTATION option - mount your APM/PX4 in any orientation

Hi, Randy,

How would you propose supporting the following then: a quad/plane hybrid ( which currently would require ArduCopter and ArduPlane to be mashed together ) , or some sort of single-prop aircraft that can "prop hang", and then behave somewhat like a coaxial helicopter?

Buzz.

On 25 February 2013 18:10, Randy Mackay <rmac...@yahoo.com<mailto:rmac...@yahoo.com>> wrote:

I believe that james goppert tried to do something like that with the APO stuff. I'm a bit skeptical that trying to abstract it that far is really helpful. At some point the method used to capture the differences is just as complex as having two separate programs.

-Randy


________________________________

From: buzz <davi...@gmail.com<mailto:davi...@gmail.com>>
To: Andrew Tridgell <tri...@samba.org<mailto:tri...@samba.org>>
Cc: drones-...@googlegroups.com<mailto:drones-...@googlegroups.com>

Sent: Monday, February 25, 2013 4:23 PM

Subject: Re: [drones-discuss] AHRS_ORIENTATION option - mount your APM/PX4 in any orientation

I think that having a mixing strategy that lets the airframe implementer describe how much a certain channel or source of data X has control over rotation, for a given body angle Y ( or attitude angle Y in earth frame, if that helps ) would be flexible enough to support just about anything.

eg1: In a classical shape airframe at normal attitudes and speeds, the ailerons controls (say) 95% of roll ( in earth frame ) , and engine RPM controls 5% of roll ( torque roll in opposite direction). In a "prop hang" scenario, the earth-frame change means that "roll" ( in the earth frame) is controlled almost entirely (100%) by rudder ( prop airflow over rudder tilts airframe left-right a bit ) , and engine rpm controls altitude ( 100%) as well as the efficacy of the tail surfaces ( perhaps as a 20% mix ) , and the ailerons only act as anti-torque and yaw surfaces ( 99% mixing to yaw, where 1% is from rpm)?

Yes, all of these control mixings have much different behaviour in different attitudes, so there would be a need for the implementer of the aircraft and/or design to build a mixing table for any major airframe types, but then Quads and Planes and transitioning vehicles could use the same underlying control behaviours.

did I just make sense to anyone, it makes sense in my head. :-)

Buzz

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.





--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss%2Bunsu...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.





--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[buzz]

I'm going to discuss the example case of a transitioning quad that has a wing ( since it's easier to think about than a plane becoming a monocopter ) .....

I agree that the input factor/s influencing the mixing of ( for example) "pitch" would be attitude, airspeed, as well as user-requested RC "pitch" control input, and possibly navigational needs too, such that:

* when attitude is near-vertical and airspeed is below "stall speed", control is 100%  quad-like.

* when attitude is beyond (say) 60deg, and airspeed is above stall-speed, then control becomes "airplane-like".

* in-between these two, it's probably a linear relationship, like you suggested.   

consequently, with these two mixing/s, you could "transition" quad -> plane by either:
*  accelerating vertically till you exceed stall speed, then flying it like a 3D capable plane that happens to be going vertically upward, or

* pitching the quad over till it's horizontal speed exceeds stall speed, and it's more than (say) 60 degrees over from vertical.

( either would be ok, and the system would cope)

there would need to be similar mixing control rules for "roll"  ( which as a quad, is 100% motor differential, but as a plane is 100% ailerons ) , and maybe for  "altitude" ( which is 100% throttle as a quad, and a combination of throttle and aileron as a plane ) , and others, I'm sure.

I don't think mixings like these necessarily need to be in the controller, as it's the controllers job to manage position and navigation , not really to tell the airframe how to achieve a given rotation. ( which is all a mixer is doing )   

 So-far, we've always had airplanes that are essentially linear 1-1 relationships between desired rotation, and surfaces ( eg roll = aileron, and pitch = elevator), and quads that although they have a mixing table, it's not tied to speed or attitude or any other variables.

Seems to me like it's (a) a lot more flexible (b) not necessarily complicated to implement (c) static for each airframe style, so not hard on the users ( they need not even know it exists ) (d) probably possible to just tie into the PX4 mixing tables for much of the functionality

What do others think?

Buzz.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Menno Hochstenbach]

Hi Tridge, are these calibration vectors 'global'? If so, what are they called, so I can change them whenever I want?

Op maandag 25 februari 2013 07:49:47 UTC+1 schreef Andrew Tridgell:

[Menno Hochstenbach]

Hi,

How can I manually increase the number of possible rotations to choose from...

I want to add 5,10,15,20,.... degrees pitch as rotations.

So far I've added "38:Pitch45"  to "AP_Math/rotations.h" and "AP_AHRS/AP_AHRS.cpp" and also MP's ParameterMetaData but it did not work. What am I missing.

Thanks, Menno

Op maandag 14 januari 2013 04:18:47 UTC+1 schreef Andrew Tridgell:

[Menno Hochstenbach]

... and I a number in AP_Math/rotations.h (line 67).

Maybe it has something to do with "void Vector3<T>::rotate(enum Rotation rotation)" in AP_Math/vector3.cpp but I don't understand what is being done here and how to expand it...

Menno

Op dinsdag 22 juli 2014 17:13:22 UTC+2 schreef Menno Hochstenbach:

[Menno Hochstenbach]

I finally figured it out. In attachement you'll find a file that tells you how to change the code to add orientations of Pitch5, Pitch10, ... Pitch85.
Its for AC:3.1.2

Regards,

Menno

Op dinsdag 22 juli 2014 17:23:29 UTC+2 schreef Menno Hochstenbach: