AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

[Randy Mackay]

Tridge,

 

     If you have a moment could you review my febe-gimbal3 branch which has an attempt at splitting the AP_Mount library into a frontend/backend?

            https://github.com/rmackay9/rmackay9-ardupilot/tree/febe-gimbal3/libraries/AP_Mount

 

     The main purpose is to add support for MAVlink enabled mounts so you’ll see there’s a new AP_Mount_MAVLink class.  It’s still not fully functional though because I haven’t come up with a way to set the sysid and component id for the gimbal.  I plan to somehow pull that from the GCS_MAVLink::MALink_routing class.

 

      Some other changes include:

·         Moving support for a 2^nd gimbal into the library itself instead of having 2 separate mount objects created in the autopilot

·         Renamed the MODE parameter to DFLT_MODE (i.e. default mode) and added a separate _mode variable.  I did this because the only purpose of having the MODE parameter was so we could set the mode to a default mode at various times including startup and after a ROI command has completed.

·         Removed some configure_cmd and control_cmd which did nothing

·         Other bits of cleanup like replacing pointers with references

 

-Randy

[Matthias Badaire]

Thanks Randy,

Quite interested by this as I am trying to implement the serial protocol to Alexmos and I do need this rewrite.

I am not sure about one or two things. 

1 - The conversion from rc inputs to angle done in RC_TARGETING mode, should it not be done by the front-end ?

2 - The conversion from gps pos to angles, could we keep that in frontend as well ? otherwise my backend would have to redo the same thing as the servo class

3 - send_angle_target() does not seems to be called from anywhere.

Cheers

--
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/d/optout.

[Randy Mackay]

Matthias,

 

     It’s really great you’re working on the AlexMos support.  We discussed on the dev call the issue with the Z-axis drift so not sure how we’re going to deal with that.

 

     For #1 and #2, I’ll move some helper functions to the front-end so they can be reused by the Servo or the future AlexMos class.

 

     Thanks for checking out the code.  I’ve left send-angle-target there assuming that the MAVLink gimbal developers will want the flight controller to send the angle targets when we’re in RC_Targetting and GPS_Targeting mode.  Theoretically the gimbal could do it all by itself but let’s see.

 

     Next step is to add in the sysid and component id discovery, get Tridge’s review and then push to master.  I’m happy to help you merge your code into this if you’d like or you can do it after it’s gone into master.

 

-Randy

[Randy Mackay]

Matthias,

 

     I’ve now moved the all the rc-targeting and gps-targeting logic into the “backend” so when you’re ready to integrate the AlexMos stuff, hopefully you won’t need to implement as many functions as before.  It’s still in the same febe-gimbal3 branch.    https://github.com/rmackay9/rmackay9-ardupilot/tree/febe-gimbal3

 

     I’ll likely push this new lib to master on Fri/Sat after Tridge/Grant have branched ahead of their next Plane release.

 

-Randy

 

From: Randy Mackay [mailto:rmac...@yahoo.com]
Sent: 13-Jan-15 12:40 PM
To: 'drones-...@googlegroups.com'
Cc: 'Andrew Tridgell'
Subject: RE: [drones-discuss] AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

Matthias,

 

     It’s really great you’re working on the AlexMos support.  We discussed on the dev call the issue with the Z-axis drift so not sure how we’re going to deal with that.

 

     For #1 and #2, I’ll move some helper functions to the front-end so they can be reused by the Servo or the future AlexMos class.

 

     Thanks for checking out the code.  I’ve left send-angle-target there assuming that the MAVLink gimbal developers will want the flight controller to send the angle targets when we’re in RC_Targetting and GPS_Targeting mode.  Theoretically the gimbal could do it all by itself but let’s see.

 

     Next step is to add in the sysid and component id discovery, get Tridge’s review and then push to master.  I’m happy to help you merge your code into this if you’d like or you can do it after it’s gone into master.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Matthias Badaire
Sent: 13-Jan-15 6:08 AM
To: drones-...@googlegroups.com
Cc: Andrew Tridgell
Subject: Re: [drones-discuss] AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

Thanks Randy,

[Luis Vale Gonçalves]

Matthias

Take a look at this from the STorM32 Gimbal controller:

http://www.olliw.eu/storm32bgc-wiki/Serial_Communication

brgds

Luis

[OlliW]

Hey Randy, and Everyone else

Luis has mentioned this discussion to me. I'm developping the STorM32 gimbal controller and a primary goal I've set for myself for this year is to work on a better integration of flight controller and gimbal controller. This seems to be also the topic here.

So I'm here, with some - very stupid and basic questions, since I simply lack the knwoledge and insight into APM to understand what all the talk means.

The goal of this Mount thingy, is it to "just" function as a sort of bridge between a ground control and the gimbal, such that commands from the ground control are passed through APM to the gimbal controller (in MAVlink format, or any other format), or that gimbal controller parameters are send to the ground control and become adjustable from there?
Is it also included in the concept that some flight controller data, such as e.g. the attitude, altitude are made available to the gimbal controller?
If so, what would be the "frequency", i.e. would it come at fixed periods of time, in irregular tim steps, or what?

Thx,
Olli

BTW: The STorM32 controller doesn't have the yaw issue.

[Bernardo Diaz]

I use this controller (I have two and two more coming) and it´s a great product. The hardware is well designed and the software has regular update with new features and bug fixes. There is now a new version coming from GLB (v1.31) with better motor drivers to even support 6s. THE MOST IMPORTANT THING-->The price is U$S 19.88!! So expect many requests from people in the low/mid segment to support it.

[Luis Vale Gonçalves]

I've replaced my AlexMos Controllers by STorM32 and I only regret the time I've lost setting up the AlexMos controllers (both 8 and 32 bit)......

Luis

[Matthias Badaire]

Randy,

I have a problem with the current implementation as I need to pass the serial port as a parameters during init. I hard coded it to start with 

Here is the PR :https://github.com/rmackay9/rmackay9-ardupilot/pull/3

I did not had time to test it and it only support 8 bit version for the moment.

Cheers,

Matthias

[Randy Mackay]

 

     This STorM32 is quite interesting, they’ve even put some effort into a (sortof) MAVlink interface!

         http://www.olliw.eu/storm32bgc-wiki/Serial_Communication#Mavlink_Communication

 

     If someone has one of these and a pixhawk I could try to write another gimbal lib to talk to it and we could go from there.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Luis Vale Gonçalves
Sent: 16-Jan-15 2:06 AM
To: drones-...@googlegroups.com
Cc: tri...@tridgell.net
Subject: Re: [drones-discuss] AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

I've replaced my AlexMos Controllers by STorM32 and I only regret the time I've lost setting up the AlexMos controllers (both 8 and 32 bit)......

[Randy Mackay]

Matthias,

 

     Ok, that patch is looking pretty good so far.  I’ve got a couple of comments that I’ll add to the PR but I’ve merged it into my branch as well.  Looking forward to your tests showing it can move the gimbal.

 

     The issue of which serial port to use needs to be fixed for the MAVLink-gimbal lib as well.  The hard-coded method you’re using for the moment is fine.  We can fix that for sure.

[OlliW]

the serial MAVlink-type protocol of the StorM32 is not written in stone, I'm perfectly willing to modify it
ideally there would be a set of "standardized" gimbal MAVlink commands, for both communication between gimbal and ground state and communication between gimbal and flight controller
I'm perfectly willing to make the STorM32 fully compatible with any such MAVlink commands
I just need to understand the things (in detail), and these commands would need to be worked out and defined

which set of commands is needed I think is the more challenging issue, since I see several different goals and task, and the different task can be arranged differently as regards which component (gimbal, FC, ground control) is doing what. But it needs to be determined.

Olli

[Matthias Badaire]

Hey,

Fix defines and stuff : https://github.com/rmackay9/rmackay9-ardupilot/pull/4

It has just been tested this morning and it still works. roll/pitch/yaw control in RC mode and GPS ROI works

M

[Randy Mackay]

Matthias,

 

     Very nice.  I’ve merged in your latest patches to my febe-gimbal3 branch and Tridge will give a final review before we push to master.  During that review we will add that final bit to allow the dynamic setting of the serial port for both the MAVLink and AlexMos versions.

[Matthias Badaire]

Thanks a lot

I might not have access to a laptop this weekend (yes it is possible), so if he is really unhappy with it, just remove it and I will resubmit later. I will monitor my emails anyway

M

[Luis Vale Gonçalves]

Hi

I do have a STorm32 gimbal and the PixHawk on my Hexa controlled by the Taranis.

brgds

Luis

[Randy Mackay]

Olli,

 

      Thanks for chiming in.

 

     The Mount library’s primary purpose is to let the flight controller control the angle of the camera gimbal so it can do things like “ROI” (i.e. point at a “region of interest”) or move to a particular angle during a stage of the mission.  In the future we will probably add other features like allow the flight controller to tell the gimbal to relax in some situations (maybe when the vehicle is disarmed).  To do this the gimbal should respond to a COMMAND_LONG message (http://mavlink.org/messages/common#COMMAND_LONG) which contains a DO_MOUNT_CONTROL command (search for #205 on http://mavlink.org/messages/common).  The link below shows where the mount library sends this message out:

         https://github.com/rmackay9/rmackay9-ardupilot/blob/febe-gimbal3/libraries/AP_Mount/AP_Mount_MAVLink.cpp#L137

 

     Sending the heartbeat message at 1hz would be great because it would broadcast the gimbal’s presence to the FC (flight controller) and GCS.

          http://mavlink.org/messages/common#HEARTBEAT :

                   type = 26 which is the new entry we will add to the MAV_TYPE enum for gimbals

                   autopilot = whatever you want, could be a new entry in the enum if you like

                   base_mode – could leave this as zero or maybe make it a value that best matches one of the items from MAV_MOUNT_MODE

                   custom_mode – fill this is with whatever number you like to represent the mode that the gimbal is in

                  system_status – see instructions in MAV_STATE enum

                  mavlink_version – no need to fill in

        In the heartbeat message (and all others) you’ll also need to send a system-id and component id.  Ideally the system id should match the vehicle’s system id (which defaults to 1 for arducopter, plane, etc) so you might want to make it configurable.  The component id can be any number above 1 (the flight controller uses “1”).

       If the GCS ever sends messages with the gimbal’s sysid/compid over the telemetry link to the FC, the FC will forward the message onto the gimbal.

 

     It would probably be good to support the SET_MODE message and/or the COMMAND_LONG with DO_SET_MODE inside it.

 

     The parameter related messages would be good to implement so that ground stations like MAVLink can be used to update the gimbal’s parameters.

PARAM_REQUEST_LIST  - when the gimbal receives this it should send a PARAM_VALUE message for each of its parameters

PARAM_REQUEST_READ – gimbal should respond with a PARAM_VALUE for a single parameter

PARAM_SET – gimbal should set the parameters value

 

     To provide detailed status the gimbal could implement the SYS_STATUS message.

 

     To get data from the flight controller the gimbal should send a REQUEST_DATA_STREAM message to the flight controller with the stream-id and rate it wants the data at.  I think the highest rate possible is 50hz.  The “stream-id” is really a group of messages but sadly it’s not well defined what’s in each group.  For arducopter you can figure it out by looking here: https://github.com/diydrones/ardupilot/blob/master/ArduCopter/GCS_Mavlink.pde#L821.  So for example, the ATTITUDE message is in “STREAM_EXTRA1”.  If look on the common page (http://mavlink.org/messages/common ) in the MAV_DATA_STREAM table you’ll see MAV_DATA_STREAM_EXTRA1 is “10”.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of OlliW

Sent: 15-Jan-15 10:55 PM
To: drones-...@googlegroups.com
Cc: tri...@tridgell.net

--

[OlliW]

Randy

THX a lot for these very detailed instructions. I guess I won't make it to implement them all at once, but would do it step by step. It seems to me that the first thing to do is the COMMAND_LONG message -  DO_MOUNT_CONTROL message, and then the heartbeat. Some further small questions

1) The angles send by the COMMAND_LONG message -  DO_MOUNT_CONTROL message, are they with respect to earth or with respect to the copter? I presume they are with respect to earth.
If so one actually would need to focus on getting the copter attitude from the FC.

1b) Is this command supposed to be acknowledged by sending a MAV_CMD_ACK thing?

2) I've never understood the heartbeat thing, or, more generally how arbitration is done on the mavlink link. I mean, there are now at least two items sending heartbeats, the FC and the gimbal, what happens when their heartbeats overlap, or other messages overlap? How is that handled or avoided by MAVlink?

2b) Does the heartbeat thing imply that also the FC is sending a heartbeat to the gimbal controller?

3) What would be the serial speed of MAVlink?
Since quite some data is needed the standard 115200 could be too slow.

4) The data stream initiated via REQUEST_DATA_STREAM, how tightly is it scheduled in time, I mean, then it's 50Hz, how reliable are these 20ms, is it 18-22ms, or what? What are the rules here?
Obtaining the FC attitude is IMHO most important, otherwise things wouldn't work well if at all, so I'm trying to figure out if a MAVlink link is suitable for that, or if one should not better consider establishing a dedicated communication channel with some specific priorities.
Another, and maybe better method would be to get a data stream which includes both the attitude and the target angles (maybe both in quaternion form).

THX again,
Olli

[Randy Mackay]

Olli,

 

Response inline..

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of OlliW

Sent: 17-Jan-15 1:40 AM
To: drones-...@googlegroups.com

Subject: Re: [Bulk] Re: [drones-discuss] AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

Randy

THX a lot for these very detailed instructions. I guess I won't make it to implement them all at once, but would do it step by step. It seems to me that the first thing to do is the COMMAND_LONG message -  DO_MOUNT_CONTROL message, and then the heartbeat. Some further small questions

1) The angles send by the COMMAND_LONG message -  DO_MOUNT_CONTROL message, are they with respect to earth or with respect to the copter? I presume they are with respect to earth.
If so one actually would need to focus on getting the copter attitude from the FC.

>>> They are with respect to the earth.

1b) Is this command supposed to be acknowledged by sending a MAV_CMD_ACK thing?

>>> Yes, according to the MAVLink spec it should although on the flight controller side we don’t do anything with the ACKs.  If it was coming from a ground station then it might do something with them (although I’ll bet it doesn’t either).

2) I've never understood the heartbeat thing, or, more generally how arbitration is done on the mavlink link. I mean, there are now at least two items sending heartbeats, the FC and the gimbal, what happens when their heartbeats overlap, or other messages overlap? How is that handled or avoided by MAVlink?

>>> all mavlink messages have a source system-id and component-id so the receiver knows where the message (including the heartbeat msg) came from.  Many messages (but not all) also have a target-system-id/target-component-id which allows the sender to specify which item on the serial bus should take note of the message.

>>>As a side note, in AC-3.3 the flight controller maintains a routing table of serial ports to system-id/component-id pairs so it knows where each device can be reached.  It then forwards messages received on one serial bus to the other serial buses.  In this way the gimbal’s heartbeat will make its way down to the ground station and conversely the ground station will also be able to send commands to the gimbal.

2b) Does the heartbeat thing imply that also the FC is sending a heartbeat to the gimbal controller?

>>> Yes, I think it will.  I haven’t actually checked but I think so.  The gimbal may even receive heartbeats from the ground station.  Normally the gimbal should be able to differentiate what is sending the heartbeat by checking the messages’s MAV_TYPE but we’re only recently getting into this multiple devices/vehicles on the same bus so I think it could be messed up in some cases.  Still, we can fix that if you find issues.

3) What would be the serial speed of MAVlink?
Since quite some data is needed the standard 115200 could be too slow.

>>> I’ve tested with a companion computer doing up to 1.5Mbps but Tridge (plane lead) says he’s seen drop-outs and recommends not going above 921khz.  The baudrate is set on a Pixhawk/APM2 with the SERIALX_BAUD parameter (where X can be 0=USB,1=Telem1,2=Telem2).  It seems we don’t have a parameter to control the speed of Serial4 which is probably where the gimbals should go so I’ll talk to Tridge about adding that.

4) The data stream initiated via REQUEST_DATA_STREAM, how tightly is it scheduled in time, I mean, then it's 50Hz, how reliable are these 20ms, is it 18-22ms, or what? What are the rules here?

>>> I’ve never tested the scheduling but I’ll bet it’s not fantastic.  I could easily imagine fairly regularly that you’d see slips of 4ms and occasional slips of up to 10ms.  I think the info in the messages would be recent (within the last 2.5ms) but it’s low on the scheduler priority list so it’s timing will vary.

Obtaining the FC attitude is IMHO most important, otherwise things wouldn't work well if at all, so I'm trying to figure out if a MAVlink link is suitable for that, or if one should not better consider establishing a dedicated communication channel with some specific priorities.
Another, and maybe better method would be to get a data stream which includes both the attitude and the target angles (maybe both in quaternion form).

>>> I guess we could do some special stuff in the Mount driver for the STorM that sends out the vehicle attitude information and target angles at 50hz so we wouldn’t necessarily have to force the gimbal to go through the whole REQUEST_DATA_STREAM bit.  There are alternative messages we could use (see http://mavlink.org/messages/common) like: MAV_CMD_DO_MOUNT_CONTROL_QUAT and ATTITUDE_QUATERNION (#31).  We could send those instead.

 

>>> if having a Pixhawk would be useful for this work I think Craig Elder can send you one.  I’m sure he’s reading this thread.

THX again,
Olli

[OlliW]

Randy

thanks again so much for this

2) I've never understood the heartbeat thing, or, more generally how arbitration is done on the mavlink link. I mean, there are now at least two items sending heartbeats, the FC and the gimbal, what happens when their heartbeats overlap, or other messages overlap? How is that handled or avoided by MAVlink?

>>> all mavlink messages have a source system-id and component-id so the receiver knows where the message (including the heartbeat msg) came from.  Many messages (but not all) also have a target-system-id/target-component-id which allows the sender to specify which item on the serial bus should take note of the message.

I think I understood the id thing, but my question was more related to the fact that then two "transmitters" are sending on one of the same "cable", they shouldn't send simultaneously. Often this is achieved through some master/slave thing like in i2c or spi, some arbitration like in can, or whatever method, but I can't see anything of this with MAVlink. I also can't see how MAVlink could reliably recover, i.e. find the start. I understand the "magic" byte thing, which is also discussed at length in the mavlink web pages, but unless there is a full backstepping search implemented which would be extremely resource hungry it can't. Often a timeout mechanisms is used. I can't see anything of all that, at the moment it looks to me as if any sort of collision happens messages are just dropped and if some error happens one is just hoping for the best. Might be OK for low transmission rates, but for a good gimbal-fc link this wouldn't be OK. I may of course miss the point, hence my question.

Thx, Olli

[Randy Mackay]

Olli,

 

     Ah ok.  So there aren’t two transmitters on a single serial cable, but because the flight controller at least has multiple serial connections it can transmit info from multiple sources down a single cable.  So for example commands from the ground station would be received by the FC on telemetry 1.  The FC checks each message’s target and sends those meant for the gimbal down Serial4 and it might send its own attitude info down that line as well but the packets would be sent one after the other.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of OlliW
Sent: 18-Jan-15 9:46 AM
To: drones-...@googlegroups.com
Subject: Re: [Bulk] Re: [drones-discuss] AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

Randy

[OlliW]

Hey Randy

thanks a lot, the explanations are very valuable to me. Sorry for not having come back earlier, I have little spare time these days.

So, the FC ensures that e.g. the gimbals heartbeat is delayed if needed. Poor FC, has to do quite some scheduling job then :) .
The whole id thing of mavlink isn't very well thought out, IMHO.

Anyway, I analyzed the concept a bit more, and I kind of concluded that the mavlink isn't really well suited for establishing the strong link between gimbal and FC. I mean, the mavlink data format is fine, but not how the communication is scheduled. One IMHO will need some dedicated communication channel, where the FC will have to ensure that it sends real-time data. If it can't be timed accurately, then it should be time stamped and send out with little latency.

For the moment, I think you gave me some great hints, as first step I would attempt to support the COMMAND_LONG - DO_MOUNT_CONTROL message. If I got it, with this command alone would be sufficient to do all the gimbal control things. Not sure the heartbeat is needed, I would think that there is already a parameter which needs to be configured when a gimbal is used, but if it fits better into your scheme I'll be happy to do that too.

As regards the PARAM_REQUEST_LIST, I'm not sure that's what one wants. I admit it's kind of cool to also configure the gimbal via the ground control, but this would add another over 100 parameters ... ;), I think a well chosen small set of commands, and a dedicated "plugin" for the ground control would serve the users needs better.

I anyway first need to set up a APM system. LOL. With regards to gimbals I'm still stuck with my coax heli, no suitable quad yet.
BTW, the new AP_MOUNT, would this also go into the 8-bit code branch? I'm obviously having the Walkera QR X350 pro in mind here. For me it would be a quick entry into the APM world, and providing unique gimbal features for it would probably get a lot of attention.
(although I couldn't yet find the location of the Walkera source code, so not sure how easy it actually is to integrate a new AP_MOUNT here LOL)

Thx again. I'll let you know whenever I should have accomplished anything :) (march/april might be a good time)
Cheers, Olli

[Randy Mackay]

OlliW,

 

     I think you could skip sending the heartbeat.  We’re going to write a custom SToRM  library to talk to the gimbal anyway so we can be more flexible than a general use MAVLink channel would be, we could even not use MAVLink if necessary although it’s a little more work for us (the AlexMos library doesn’t use MAVLink).  As you guess, it’ll have a parameter (MOUNT_TYPE) that the user will set to specify they’re using a SToRM gimbal.

 

     For the setup through the ground station, I was thinking the full set of parameters is visible, settable through those MAVLink PARAM_* commands and then the ground station developers could come up with custom screens in their various applications.  This is really just a nice-to-have and we’re a ways from that.

 

     We won’t be able to port this functionality back to the 8-bit controllers.  Of course, it’s open source so somebody can try but it will be difficult.  I suspect that Walkera (and others) will all switch to 32bit CPUs in their next generation of vehicles.  I’m sure Craig will send you at least a Pixhawk to help you get a dev env going.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of OlliW
Sent: 23-Jan-15 11:32 AM
To: drones-...@googlegroups.com
Subject: Re: [Bulk] Re: [drones-discuss] AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

Hey Randy

--

[OlliW]

Hey Randy,

well, huh, that's now a very important information, and it doesn't come to early ... I was already figuring out the details and close to implementing the mavlink stuff LOL :)
(the main thing I was missing was the exact number for the special crc hihi)

I appreciate your decision however a lot, I think it will eventually pay off. As regards the startup work, I have not searched for the AlexMos library, but I will, and I will be happy to use it as a template and fill in the StorM32 specific stuff. The first incarnation might not be perfect, but, well, it would be a start LOL

I agree that it's a good idea to expose all parameters to the gc, as you suggest. But I think that's not the most important step to start with. It can be figured out once I got a bit more familiar with the whole stuff.

Sad to hear that it won't go into the 8-bit, but I was kind of expecting that; from your perspective it's certainly an absolutely logical decision. I'm humbled by your suggestion as regards the PixHawk, but I won't accept it, be assured that it's just due to my strange personality that I'm hesitant here. I have to get me a "dev env" anyhow, since I went to Mobius gimbals and my coax can't carry them. The walkera QR X350 would have been an appropriately priced quick start; well, I have to figure out something else LOL.

BTW, the Euler angles as they are calculated by APM are not "gimbal compatible", so one would want the quaternion and calculate gimbal compatible Eulers, would it be appropriate to have the FC doing this, or would the FC be relieved if it would be done by the gimbal?
(in short, could this be packed into the AP_MOUNT lib?)

thx, Olli

[OlliW]

Hey Randy, Luis, everyone,

I've now a first test version with some mavlink/AP_MOUNT support. It's really not fully fletched out, it's a start though. See firmware v0.63e here: http://www.rcgroups.com/forums/showpost.php?p=30753665&postcount=3540.

In contrast to my previous post, I went with Mavlink instead of a dedicated STorM32 AP_MOUNT. I've looked at the AM case, but just from the AM example it wasn't clear enough to me what the AP_MOUNT needs to get. I'm still not sure that this is the best approach, but for the moment being it's the fastest approach to get into it ...

The firmware supports heartbeat, param_value, param_request_list, param_set, param_request_read, command_long with the do_mount_control command, command_ack.

The heartbeat is emitted only via the UART or BT module, not USB. That's needed to not break the possibility to configure the STorM32 via its GUI. The heartbeat needs to be activated by the respective parameter in the Expert window. It is emitted every 1s, if not other communication postpones it (STorM32 is single-threaded). I've checked, with heartbeat activated, Mission Planner finds the STorM32, and allows to handle the parameters (read/write). Not sure that is of any use however. When configured as component of a system, I assume that the system (APM here) does all handling correctly. I think it would be better if it would not need/use the STorM32's heartbeat when.

As regards the command_long-do_mount_control command, note these:
* The specified angles are with respect to the gimbal system, i.e., the gimbals motors/axes.
* They are subject to the min-max limits. (I plan to remove this limit of course)
* The axes must be set to "absolute" for this command to work (I plan to remove this limit of course)
* In contrast to how other things might work and in contrast to how the AP_MOUNT (mode) seems to be designed, the STorM32 adds up all inputs (or mixes them 1:1 if you like that wording better). That is, the camera orientation set via the command_long-do_mount_control command and e.g. an RC signal or joystick are added. This might be confusing at first, but obviously provides nice options.

This functionality might not yet be what is needed for follow me, but it should allow to test if the integration is working, one should e.g. be able to control the camera orientation by a ground control station. Once that is OK we/I can go from there.  

I myself do not yet have a system to test, I've ordered a XUAX-X2 which is supposed to come by the end of February, but luis seems to have a STorM-pixhawk system, as well as rcgroups user GekoCH, and both seem to be happy to help. If this drone-discuss environment is not the appropriate place to continue this topic, I'll be happy to open a thread somewhere else if that is preferred.

[Luis Vale Gonçalves]

Ok Randy.

I'll assume that we need to get this going: If the latest release of Olliw is already supporting Mavlink commands how can we connect to the PixHawk?? I'll assume using serial 4/5 on the PixHawk to the UART port of the STorM32 board?? 

Then, how to enable the AP_Mount to use the Mavlink via Serial 4/5 to talk to the gimbal controller ?? I couldn't find much documentation on the AP_Mount.

best regards

Luis

On Friday, January 16, 2015 at 4:41:37 AM UTC, Randy Mackay wrote:

[Randy Mackay]

Luis,

 

     Thanks for the help with this.  I think the first test should be to check talking with the storm gimbal over mavlink to read it’s parameters.

 

     So load up the Pixhawk with the latest firmware.  “ArduCopter-v2.px4” from http://firmware.diydrones.com/Copter/latest/PX4-quad/

 

     Somehow wire up telem1 or telem2 to the gimbal’s serial port.  The Pixhawk pin info is here: http://copter.ardupilot.com/wiki/common-pixhawk-overview/#pixhawk_conector_pin_assignments

 

     Set the SERIAL1_BAUD or SERIAL2_BAUD to match the baud of the gimbal.  I guess it’ll be “57” (=57600) or “115” (=115200).  Make sure to reboot the board after changing these parameters.

 

     The connect to the Pixhawk with the mission planner.  If the hearbeats successfully pass from the Storm gimbal to the MP, a little “SysId Selector” dialog box should pop-up asking which device (i.e. vehicle or gimbal) you want to connect to.  If it doesn’t you can try pressing Ctrl-X.  I’ve attached a pic of what it looks like.  If that works then go to the MP’s Config/Tuning page’s full parameter list and the Gimbal’s params should be visible.

 

     It’s a bit of a miracle if you get this far without any problems.

 

     The next step would be to test the do-mount-control messages.  I think the best way to do that is for me to write a small AP_Mount_SToRM32 library.  It’ll be very similar to the AP_Mount_MAVLink but it’ll let us customise what we send down.  That won’t take me too long I think.

 

-Randy

P.S. I’m ordering a SToRM32 board immediately.

[Lorenz Meier]

Hi Randy,

Are you sure you want to introduce special case handling per gimbal? The resulting proliferation of unnecessary small differences will increase fragmentation in the gimbal interfaces, and generally make it harder on users and developers.

I'm fully aware it would be the past of least resistance, but it's not doing good in the medium term.

I will put up a MAVLink acceptance test suite onto the agenda for the next DroneCode TSC meeting and the term "MAVLink compatible" will become defined with more rigor in the future. It would be nice if APM could become the reference implementation for the gimbal profile.

-Lorenz

<StormTesting_MPSysIdSelector.png>

[OlliW]

Hey,

the STorM32's default are
* System ID 71 (='G')
* Component ID 67 (='C')
* heartbeat off
* 115200 bps 8N1

you can set the SysID, CompID, and the heartbeat in the Expert Tools window accessible via the Tools menu, you need to Write (hit Write button) and or Write+Store (click checkbock and hit Write+Store button)
you can set also the baudrate via a tool in the Tools menu, but maybe one wants to stick with 115200

the pixhawk needs to be connected to the UART port on the STorM32, it's the three pins next to the AUX port on the "bottom", see here http://www.olliw.eu/storm32bgc-wiki/File:Stom32-bgc-v130-ports-and-connections-01.jpg (it's identical for all boards, v1.1, v1.3, v1.31)

btw, for MAV_AUTOPILOT I've claimed 83 (='S')(like STorM32 LOL)

btw, with the heartbeat enabled and the pixhawk connected to UART one still can communicate "normally" via USB, e.g. with the GUI. It may happen that the GUI connection is sometimes lost, when the activity on the UART port takes too long, but that's just a nuisance. This can be useful for testing, you may e.g. change a parameter in the MP, and check it in the GUI by a Read.

I would think that at this stage one wouldn't (yet) need a STorM32 AP_MOUNT, since it's just few native MAVLINK commands which are used/involved. Said otherwise, I would hope that it would work with the standard MAVLINK AP_MOUNT.

Testing the communication should be possible by just flashing the firmware on "any" F103RC development board. If it happens you have one around, tell me the type (or a web link), and I will check.

As regards a MAVLINK standard for gimbals I think, or actually predict, that this is not going to fly. As much as you wouldn't want to use APM's MP for an autoquad copter or AQ's QGC for a APM copter, you wouldn't wanted to be narrowed down in function by a generic gimbal support. No one wants to be restricted to MAVLINK's parameter support but wants to enjoy the convenience of the dedicated widgets. And so on and forth. And at the end of the day it's really just less than a handful of controllers. If ever more controIler need to be supported I would think one should have the AP_MOUNT that well structured and documented that any mount builder can more or less easily write their AP_MOUNT, concept-wise it could be somewhat like with drivers, i.e. the mount builder is also responsible for the AP_MOUNT. Just my 2 cents.
Anyway, I think it's too early for any standard anyhow, I would not be surprised to see things changing significantly in the course of the development.

[Lorenz Meier]

Hi Olli,

I fully agree it's too early to define a standard, but there is no reason to not strive for compatibility.

As you will have noticed MAVLink is similarly to HTML a very loose standard. It doesn't mean that absolutely everything would be defined.

At the end of the day the requirements of each gimbal widely overlap. It is that overlap that we need to try to capture. Consider the systems talking to the gimbal: Autopilot, tablet GCS, desktop GCS, DroneAPI, ROS adapters and many more. So minimizing special cases considerably reduces development work.

And that in the end means that your gimbal is supported by more systems and will see wider adoption.

-Lorenz

--

[Randy Mackay]

Olli,

 

     FYI - I’m planning to buy from roswell57 which seems partnered with gimbal24 and includes the 2^nd IMU and 25cm cable.  Sound like a decent choice?

            http://www.roswell57.com/control_boards.html

 

-Randy

--

[Luis Vale Gonçalves]

IMHO, expensive.

The controller already has an IMU on the board which you can be superseded with an external IMU#2. IMU#1 goes to the camera support. So the use cases for the external IMU#2 are diminished by the inclusion of the onboard one. I do have 2 controllers and 3 external IMU's :) 

Example usage on STorm32 wiki

Storm32-wiki-2nd-imu-configurations-01.jpg

[OlliW]

Randy

please understand that I'm not commenting on the vendors' offers, I try to stay object (as much as that is possible LOL). I'm happy enough that there are vendors at all selling this thing. There are plenty options now with varying combination of boards, price, accessories, shipping, support to choose from; a fairly complete list you may find here: http://www.olliw.eu/storm32bgc-wiki/Where_to_buy_STorM32_boards#Board_Configurations.

from the technical side the v1.1/1.3 and v1.31 boards differ in their voltage regulator and motor drivers, besides the effect on the voltage range (2S-4S vs 3S-6S) it's not clear yet what the practical impact is, one may speculate though that the v1.31 does better on "bigger" gimbals.

[OlliW]

EDIT: the configuration (3) in the figure Luis linked too is NOT supported by STorM32

[OlliW]

Hey Lorentz

I perfectly understand what you're saying, however, in some sense, this applies only to communication between one system to another (FC to MP). The communication between FC and gimbal will - if what I have in mind works out as I have it in mind - need a "special" communication link, which, as much as I see, doesn't fit well with MAVLINK, see the above discussion. So, I would not be surprised to see that later on we're going to ditch MAVLINK completely for the FC-gimbal communication, i.e. the FC will have to pretend to the MP that there is a MAVLINK gimbal, but talk different language to the gimbal. This here is just the very first start, the real coll stuff is still to come LOL. Anyway, we will see where we end up. :)

[Glenn Gregory]

Hi Guys,

Just to confirm I was able to successfully upload the parameters from the STorM32 controller via Mission Planner through the Pixhawk connected to TELEM1. I had the cables already so thought I'd quickly try this. Unfortunately I don't have too much free time to help out with writing the library.

Let me know if you want any tests done though.

[Luis Vale Gonçalves]

Hi all.

Just remembered to hack the Bluetooth cable to connect the STorM32 to Telem2 port and after changing the required parameters on serial 2 everything went smoothly.

Please Randy, enable Serial4 or 5 to connect the AP_Mount devices.

Great work Olliw, and Randy.

Unrelated: Randy, are we transforming the PixHawk into a Tamagotchi with all the beeps and melodies on that build you pointed ?? :)

[OlliW]

FANTASTIC

next step: moving the camera via the MP and or Piwhawk through the mavlink channel, i.e. to test the command long do mount configure command (what a great name for a command)

[Glenn Gregory]

Olli do you also support MAV_CMD_DO_MOUNT_CONTROL? Can you give examples of values you are expecting? I.e MAV_MOUNT_MODE

[Randy Mackay]

 

     I’ve taken a first stab at a SToRM32 mount library.  It’s very unlikely to work straight off but it’s a start especially in case anyone else wants to hack away on it (I will be away in Taiwan this week so I won’t be too responsive).

 

     The new library is in my repo’s storm32-wip1 branch.  It’s the last two commits shown here:

            https://github.com/rmackay9/rmackay9-ardupilot/commits/storm32-wip1

 

     A pre-compiled binary for a pixhawk can be found here:

           https://dl.dropboxusercontent.com/u/3852647/SToRM32/ArduCopter-v2-stormVer1.px4

 

     The easiest way to test whether the gimbal is pointing properly is to:

·         Load up above pixhawk firmware to board using MP’s install firmware, custom firmware link

·         Load up the randy-storm32-param.param file to the pixhawk using MP’s “Full Param List” or “Full Param Tree” screen and press “Write Params” button

·         Set vehicle’s MNT_DEFLT_MODE to “1” (i.e neutral)

·         Reboot board

·         On MP’s “Full Param Tree” screen set MNT_NEUTRAL_X (for roll) and MNT_NEUTRAL_Y (for pitch) parameters to desired lean angle.  Mount should move to these

·         If the above method works try setting the MNT_DEFLT_MODE to “3” (RC_Targeting = pilot controlled tilt) and move ch6 tuning knob on transmitter to see if mount moves properly

 

     Some more detailed notes on the library:

·         hard-coded to send the MAVlink messages on Telem2 (or whatever SERIALX_PROTOCOL = “2”).  We will make this more flexible later.

·         hard-coded to send to SysId=71, CompID=67

·         sends a command-long containing the MAV_CMD_DO_MOUNT_CONTROL (see http://mavlink.org/messages/common)

o   param 1 ~ 3 are pitch, roll and yaw in degrees.  These are “earth frame”.. i.e. absolute tilt or heading angles that have not been adjusted based on the vehicle’s tilt angle.  If this is no good we can change this.

o   Param 7 (the mode) is always sent as “2” = MAV_MOUNT_MODE_MAVLINK_TARGETING.  My guess is we will eventually need to add more possible values to the MAV_MOUNT_MODE enum found on this page: http://mavlink.org/messages/common.  Maybe “Relaxed” and “Rate” will be needed.

o   I know it’s confusing that both the mount and vehicle have a “mount mode” and they can be different but this is because only the vehicle can handle most modes like “mav-mount-mode-gps” while the gimbal is only responsible for pointing in a particular direction so it only has one mode (for now).

o   These messages are sent at 1hz or 50hz depending upon the vehicle’s mount mode.  If the vehicle’s mount mode is “retract”, “neutral” or “mavlink-targeting” it’s sent at 1hz.  If it’s “rc-targeting” (i.e. pilot’s rc input is being sent) or “gps-point” (we’re pointing at a lat,lon,alt location) then we send at 50hz.  We can definitely throttle the 50hz down or only send when the angles change by a certain amount if necessary.

o   Tilt of -90 = point straight down, +90 = striaight up

o   Roll of -45 = lean left at 45 deg, +45= lean right at 45 deg (I think)

o   Yaw of -45 = point north-west, +45 = point north-east.  Normally we expect yaw to be ignored on a 2-axis gimbal but I guess it should work on a 3-axis

 

-Randy

 

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Luis Vale Gonçalves

Sent: 14-Feb-15 1:23 PM
To: drones-...@googlegroups.com
Cc: tri...@tridgell.net

--

[Randy Mackay]

Sorry, missed one step in the “way to test” section.  Add in red.

 

-Randy

 

From: Randy Mackay [mailto:rmac...@yahoo.com]
Sent: 14-Feb-15 10:04 PM
To: 'drones-...@googlegroups.com'
Cc: 'tri...@tridgell.net'; 'Glenn Gregory'
Subject: RE: [Bulk] [drones-discuss] Re: AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

 

     I’ve taken a first stab at a SToRM32 mount library.  It’s very unlikely to work straight off but it’s a start especially in case anyone else wants to hack away on it (I will be away in Taiwan this week so I won’t be too responsive).

 

     The new library is in my repo’s storm32-wip1 branch.  It’s the last two commits shown here:

            https://github.com/rmackay9/rmackay9-ardupilot/commits/storm32-wip1

 

     A pre-compiled binary for a pixhawk can be found here:

           https://dl.dropboxusercontent.com/u/3852647/SToRM32/ArduCopter-v2-stormVer1.px4

 

     The easiest way to test whether the gimbal is pointing properly is to:

·         Connect the SToRM32 gimbal to Telem2

·         Load up above pixhawk firmware to board using MP’s install firmware, custom firmware link

·         Load up the randy-storm32-param.param file to the pixhawk using MP’s “Full Param List” or “Full Param Tree” screen and press “Write Params” button

·         Set vehicle’s MNT_DEFLT_MODE to “1” (i.e neutral)

·         Reboot board

·         On MP’s “Full Param Tree” screen set MNT_NEUTRAL_X (for roll) and MNT_NEUTRAL_Y (for pitch) parameters to desired lean angle.  Mount should move to these

·         If the above method works try setting the MNT_DEFLT_MODE to “3” (RC_Targeting = pilot controlled tilt) and move ch6 tuning knob on transmitter to see if mount moves properly

 

     Some more detailed notes on the library:

·         hard-coded to send the MAVlink messages on Telem2 (or whatever SERIALX_PROTOCOL = “2”).  We will make this more flexible later.

·         hard-coded to send to SysId=71, CompID=67

·         sends a command-long containing the MAV_CMD_DO_MOUNT_CONTROL (see http://mavlink.org/messages/common)

o   param 1 ~ 3 are pitch, roll and yaw in degrees.  These are “earth frame”.. i.e. absolute tilt or heading angles that have not been adjusted based on the vehicle’s tilt angle.  If this is no good we can change this.

o   Param 7 (the mode) is always sent as “2” = MAV_MOUNT_MODE_MAVLINK_TARGETING.  My guess is we will eventually need to add more possible values to the MAV_MOUNT_MODE enum found on this page: http://mavlink.org/messages/common.  Maybe “Relaxed” and “Rate” will be needed.

o   I know it’s confusing that both the mount and vehicle have a “mount mode” and they can be different but this is because only the vehicle can handle most modes like “mav-mount-mode-gps” while the gimbal is only responsible for pointing in a particular direction so it only has one mode (for now).

o   These messages are sent at 1hz or 50hz depending upon the vehicle’s mount mode.  If the vehicle’s mount mode is “retract”, “neutral” or “mavlink-targeting” it’s sent at 1hz.  If it’s “rc-targeting” (i.e. pilot’s rc input is being sent) or “gps-point” (we’re pointing at a lat,lon,alt location) then we send at 50hz.  We can definitely throttle the 50hz down or only send when the angles change by a certain amount if necessary.

o   Tilt of -90 = point straight down, +90 = striaight up

o   Roll of -45 = lean left at 45 deg, +45= lean right at 45 deg (I think)

o   Yaw of -45 = point north-west, +45 = point north-east.  Normally we expect yaw to be ignored on a 2-axis gimbal but I guess it should work on a 3-axis

 

-Randy

 

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Luis Vale Gonçalves
Sent: 14-Feb-15 1:23 PM
To: drones-...@googlegroups.com
Cc: tri...@tridgell.net
Subject: [Bulk] [drones-discuss] Re: AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

Hi all.

--

[OlliW]

Randy, WAU, this is awesome
I'm jealous that I can't do any testing yet myself (though I'm in ski vacation now anyhow LOL)

Glenn, yes, this command is supported (this was the main thing)
the mode flag is ignored, I can't yet see how it would be relevant for the STorM
the angles are different to those Randy described, as I mentioned before, there will be some translation to be done
the STorM uses a right-handed system with it's x axis to the front and the z axis to to top (to the sky), pitch is e.g. positive for tilting down.

[Randy Mackay]

I've updated my storm32 branch to look like master and produced new binaries for quad and hexa.  Any testing would be greatly appreciated:

quad: https://dl.dropboxusercontent.com/u/3852647/SToRM32/ArduCopter-v2-stormVer1-quad.px4

hexa: https://dl.dropboxusercontent.com/u/3852647/SToRM32/ArduCopter-v2-stormVer1-hexa.px4

-Randy

[Glenn Gregory]

Hi Randy,

I've loaded up the firmware and connected to the STorM32. Unfortunately there is no response from the gimbal when I change the value of MNT_NEUTRAL_X and MNT_NEUTRAL_Y. 

@OlliW Is there any debug messages in the STorM32 firmware for when it receives mavlink messages? I.e I am also connected to controller on USB, should I be seeing any messages when it receives a packet?

The Mavlink RC Tool works if I enter an angle and press 'Set Angle'.

I'll have a look into the ArduCopter firmware.

--

M: +61 (0) 413 902 541

E:  glenn.g...@gmail.com

[Glenn Gregory]

Success!! 

I don't know what I did wrong originally but everything is working now. In both Neutral and RC targeting mode (MNT_DEFLT_MODE = 1 & 3).

A few things to note:

• degrees value must be x10
• +pitch will point camera down (as mentioned)
• +roll will roll the camera to the right

I.e with the following parameters:

MNT_NEUTRAL_X = 100

MNT_NEUTRAL_Y = 450

The camera will roll to the right 10 degrees and point down at 45 degrees.

[OlliW]

this is awesome, THANKS Glenn for testing!

as it seems, Randy's little miracle has not only become true but been superseded LOL

as regards the directions, I'm not sure at the moment what frame APM is using, the frame STorM32 is using was mentioned in the above, from that all differences in the directions should follow
from top of my head it seems to me that all angles are negative to APM's, but I'm not sure I should trust my head here

as regards the x10 ... hmmm ... I will of course double check then I'm back, but I'm a bit puzzled, the mavlink docu tells that these angles are in degree and that's what I at least aimed for ... you could do a test ... when you do the angles with the Mavlink RC tool, you also need to modify them by a factor of 10?
anyway, it's really a trivial thing to get that correct

BTW: the mavlink RC Tool does NOT use the "real" mavlink commands, it uses the "old" mavlink-type commands, which I had implemented before this last revision. To help at least a tiny bit in avoiding confusion (difficult, I know), I've called this set of commands now "Mavlink RC" ... hence the tools name has also changed in the last beta version to "Mavink RC Tool" :) Just to avoid confusion about what is doing what.  

Now that the first get-into-it step has essentially been successfully accomplished, it's time to think about the next steps :) It would be establishing a firm link between FC and gimbal, i.e. that the FC sends out its attitude estimate to the gimbal controller. This is not really difficult, but probably needs to be carefully discussed, so that the concept serves both the needs (and limitations) of the FC and GC. :) Now things start to get really exciting ... 

[Luis Vale Gonçalves]

Hi

Could not test, as I have a huge problem on my PixHawk. My PixHawk has decided to randomly ignore my RCMAP settings, and also ignore my E300 propulsion kit. About to do a complete disassemble and reassemble...

sorry guys, for the delay.

Luis

[Glenn Gregory]

Just had another play. I was wrong about the angles being x10. It is in fact 1:1, I was being tricked by the limited movement of the Gimbal. 

The Sorry for the confusion.

--

You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/gIkqFECW_B8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

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

[OlliW]

great!

the min max values can be adjusted through the gui, a worthable read could be http://www.olliw.eu/storm32bgc-wiki/Configure_the_RC_Input#GUI_Settings

the do-mount command is currently restricted to these min max limits, i.e. it's not possible to rotate around yaw indefinitely, but I hope to have solved that in the next firmware beta
it is btw also subject to the speed and acceleration adjustments, so that the behavior can be configured quite flexibly.

[Luis Vale Gonçalves]

Hi Olliw

Unless the ArduCopter lib can read the max/min and speed/acceleration values. I believe that the limits imposed on the Gimbal Gui must be respected.

I believe that the Arducopter Lib should issue a command to the STorM32 to read the relevant commands and then work within those boundaries.

Just my 2c, while I fight with my damn PixHawk. Randy if you're reading this, the RC part of 3.2.1 is a mess.....

Luis

[Robert Lefebvre]

What is the issue you're having?

--

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.

[Luis Vale Gonçalves]

Extremely easy to reproduce.

Erase the PixHawk. Use a DJI propulsion kit like the E300 that does not need ESC calibration. Flash latest build (Copter). Try to setup a TAER radio. Even after using the RCMAP to adjust the channels. The PixHawk ignores the RCMAP settings even if they're correct. Weird.

I just gave up and redid the radio profile. Good that the Taranis can swap channels at will. Weird that worked great with 3.1.5. 

Please bring the Radio calibration from QGround Control and PX4 to ArduCopter. The current situation is ridiculous.

[Robert Lefebvre]

So the problem exists when using one particular set of ESC's with unchangeable, un-calibrate-able, closed-source firmware, and a closed source-radio, with un-configureable channel mappings?

[Josh Welsh]

Luis,

 

To Rob’s point I think comments like “The current situation is ridiculous” will likely not get you the collaborative responses you’re hoping for.

[Luis Vale Gonçalves]

Point taken. Thanks. And sorry if I offended someone.

How would you classify the situation I described ??

Best

Luis

[Luis Vale Gonçalves]

Rob. I'm sorry but you're missing the point.

The ESC's have nothing to do with the issue. I just mentioned the complete set. And their lower setting is known (just ask DJI) and is 1120ms and top 1940ms. Also the radio being closed source or open source is irrelevant.

For my convenience and habit, I have my Taranis set as TAER Channel order. As you know Arducopter expects AETR. Unless you go to RCMAP and change this, one would expect the newer parameters of RCMAP to be respected (they were as of 3.1.5). They aren't.  On the other hand just try to do a radio calibration under PX4 and QGroundControl. You'll see the difference. I won't even mention the number of channels because we know that's another (but related) issue.

I've helped several Arducopter users that requested help both on the forums and via PM's that had problems with Spektrum radios that have a fixed channel order, contrary to the Taranis, but now I really don't know what to say to them.

Luis

[Robert Lefebvre]

Luis, sorry, my point was just that, while this is worth fixing, it is pretty low on my priority list.  It's a fairly substantial problem to sort out, with plenty of risk of making a mistake that would affect all users.  And the problem is mostly, if not completely, caused by one RC Tx vendor who has chosen to be both different only for the sake of being different, and also inflexible, and also have poor documentation.  This problem has existed for a while, we've seen comments from users trying to use Spektrum equipment, struggling with radio setup. I couldn't even get any info on these system without going out and buying one for myself to fiddle around with, because nobody could even tell me which channel is which, nobody seemed to know.  

I just deleted a bunch of other O/T stuff about Spektrum...

I just view the problem as being Spektrum's making, but it's fallen on us to sort it out.  And would require us to go buy hardware to determine what exactly needs to be done, as I understand it there are issues with ALL of the channel mappings to the hardware inputs.  Like I said, it's just not been a priority for me at least.

[Luis Vale Gonçalves]

Moved the RC channels discussion to other thread.

[Randy Mackay]

 

     Sorry for not replying sooner, I was off in Taiwan for a few days.

 

     Great news that the gimbal is moving!  Based on this milestone, I’ve pushed the SToRM32 library into master so that it doesn’t fall out of date as other changes go in.

 

     Re the angle directions, I think the roll response is ok (+ve = roll right) but pitch is reversed (+ve should be up, but it’s down).  We haven’t tested yaw but I suspect it’s ok.

 

     OlliW, are you happy to reverse the pitch response in the SToRM32 gimbal itself?

          To get the vehicle angles we can either proactively send them from the gimbal library so the gimbal software can use the REQUEST_DATA_STREAM message to tell the FC what data it wants and the rate. http://mavlink.org/messages/common#REQUEST_DATA_STREAM.

           target_system = “1” by default but should configurable or captured from the heartbeats received from the flight controller.

           target_component = “1” by default but should be configurable or captured from heartbeat

           req_stream_id =  “10” (i.e. MAV_DATA_STREAM_EXTRA1 from MAV_DATA_STREAM enum in http://mavlink.org/messages/common)

           req_message_rate = “10” (for 10hz, “50” for 50hz, etc)

           start_stop = “1” (to start sending)

 

     So what should we do next?  Some ideas below, feel free to change or add more:

·         Add a relaxed mode in which the gimbal doesn’t try to do any stabilization so it doesn’t shake when you push the button to turn on the camera

o   we could relax the gimbal when the Pixhawk’s safety button is flashing (which means the ESCs are disabled).  This would be its state on startup so the user could turn on the Go-Pro/camera, then push the safety button, the gimbal will start stabilizing and then he/she can take-off.

o   To do this we would add a 5^th MAV_MOUNT_MODE called MAV_MOUNT_MODE_RELAXED.  We could tell the Gimbal to go into this mode either with a COMMAND_LONG containing the SET_MODE command or set param #7 of the COMMAND_LONG’s DO_MOUNT_CONTROL message.  I vote for using do-mount-control.

·         Send accelerometer corrections so the gimbal angles remain accurate during fast maneuvers

·         Write a wiki page showing how to connect the SToRM32 to the Pixhawk.

·         Do a blog post advertising that SToRM32 support is coming in AC3.3 including a video showing how it’s connected and proof that it’s speaking MAVlink (i.e. show that it’s possible to connect to the mission planner directly to see the parameters)

 

-Randy

[Randy Mackay]

Another idea add to the “do next” list in red.

 

-Randy

 

From: Randy Mackay [mailto:rmac...@yahoo.com]
Sent: 20-Feb-15 12:15 PM
To: 'drones-...@googlegroups.com'
Subject: RE: [drones-discuss] Re: AP_Mount frontend/backend split in advance of adding support for MAVLink/AlexMos gimbals

 

 

     Sorry for not replying sooner, I was off in Taiwan for a few days.

 

     Great news that the gimbal is moving!  Based on this milestone, I’ve pushed the SToRM32 library into master so that it doesn’t fall out of date as other changes go in.

 

     Re the angle directions, I think the roll response is ok (+ve = roll right) but pitch is reversed (+ve should be up, but it’s down).  We haven’t tested yaw but I suspect it’s ok.

 

     OlliW, are you happy to reverse the pitch response in the SToRM32 gimbal itself?

          To get the vehicle angles we can either proactively send them from the gimbal library so the gimbal software can use the REQUEST_DATA_STREAM message to tell the FC what data it wants and the rate. http://mavlink.org/messages/common#REQUEST_DATA_STREAM.

           target_system = “1” by default but should configurable or captured from the heartbeats received from the flight controller.

           target_component = “1” by default but should be configurable or captured from heartbeat

           req_stream_id =  “10” (i.e. MAV_DATA_STREAM_EXTRA1 from MAV_DATA_STREAM enum in http://mavlink.org/messages/common)

           req_message_rate = “10” (for 10hz, “50” for 50hz, etc)

           start_stop = “1” (to start sending)

 

     So what should we do next?  Some ideas below, feel free to change or add more:

·         Add a relaxed mode in which the gimbal doesn’t try to do any stabilization so it doesn’t shake when you push the button to turn on the camera

o   we could relax the gimbal when the Pixhawk’s safety button is flashing (which means the ESCs are disabled).  This would be its state on startup so the user could turn on the Go-Pro/camera, then push the safety button, the gimbal will start stabilizing and then he/she can take-off.

o   To do this we would add a 5^th MAV_MOUNT_MODE called MAV_MOUNT_MODE_RELAXED.  We could tell the Gimbal to go into this mode either with a COMMAND_LONG containing the SET_MODE command or set param #7 of the COMMAND_LONG’s DO_MOUNT_CONTROL message.  I vote for using do-mount-control.

·         Send accelerometer corrections so the gimbal angles remain accurate during fast maneuvers

·         Ease set-up by pulling (or pushing) configuration between FC and SToRM32.  This could include “Pan Mode Default Settings”, angle maximums (?), anything else?

·         Write a wiki page showing how to connect the SToRM32 to the Pixhawk.

·         Do a blog post advertising that SToRM32 support is coming in AC3.3 including a video showing how it’s connected and proof that it’s speaking MAVlink (i.e. show that it’s possible to connect to the mission planner directly to see the parameters)

 

-Randy

 

 

On 18 February 2015 at 22:29, Luis Vale Gonçalves <luis...@gmail.com> wrote:

[Luis Vale Gonçalves]

Randy

What about having the Gimbal connected to Serial 4 or 5? 

My setup has 433 Radio on Telem1 and Bluetooth and OSD on Telem2.

luis

[Randy Mackay]

Luis,

 

     Ok, sure we can add that to the list.  Allowing it to be connected to Serial 4/5 is easy but also allowing 1 & 2 to be also used as MAVlink channels makes it a little more difficult (i.e. three simulataneous MAVLink enabled channels is some extra work).

 

-Randy

[Luis Vale Gonçalves]

Randy

I understand that. The issue I see on using Telem 1 or Telem 2 is because we need two way serial comms for the telemetry radios, that eliminates the chance of having both Bluetooth and the 433 radio on the same port, and since we need 2 way communications to the gimbal we either eliminate one of the radios or plug the gimbal on a free port. As far as I can see we still have Serial 4 and 5 free. The greater obstacle tp this could be the DF13 connectors and creating an appropriate plug to do this, but I've already found a reasonably priced crimp tool for DF13 :).

Luis

[Josh Welsh]

Back in APM2 days, if we wanted two devices (telem radios and minimOSD) to work w/o modifying the board, we would make a special cable that would send the serial ports vcc, ground, and TX cables to the vcc, ground, and RX pins on the minimOSD, effectively “splitting” the signal..  would this kind of thing work with the gimbal, or would that create problems since the gimbal is a 2-way communicator where the minimOSD is read-only?

[Gary McCray]

Hi Luis,

Could you please post the information on where to get a reasonably priced DF13 crimper, a lot of us would like to get one of those.?

Best Regards,

Gary

[OlliW]

Hey Randy

thx a lot for sharing your ideas.

Since Glenn's success post I'm thinking too about what the next steps could be, however, my brain is buzzing with all the things to consider and the empty holes in my knowledge. I think points 3,4,5 are not most urgent. I'm not sure if anything of real practical use was yet achieved, and I would expect some things to change in the next development steps :).

As regards the sign thing, if it would be just that, to change the sign of some angles ...
first, rotations do not commute
it also seems to me that the Euler angles usually used in FC's have the gimbal lock on pitch, while for a 3 axis gimbal it is on roll ... my impression is that this "little" detail is usually not noticed, and - I peg for pardon if I'm mistaken - I'm suspecting this to be so also for APM. This might mean that you have in fact to revisit all the code for calculating the gimbal's orientation, especially if it's Euler angle based (note: this is not STorM specific but due to the usual construction of 3 axis gimbals). The bottom line, it might not be sufficient to just change signs, but need to essentially recalculate the Euler angles in another representation. For efficiency reasons we actually want to avoid that. So, APM should calculate the correct gimbal Euler angles from e.g. quaternions (or supply the gimbal with the quaternion, but the former would be more appropriate).     
 
As regards the accelerometer corrections, this and more I can calculate from APM's estimated attitude quaternion, that's why I want to get that send periodically. Later on, one might wish to send also e.g. velocity for improved follow-me behavior, but we should keep that to the future. So, for the moment I would be happy with the attitude quaternion.

The to-do's IMHO separate in two topics, establishing the method to send the attitude quaterion to the gimbal, and all the functional things such as a relaxed mode, or whether the min/max should be respected or not, etc.

For the latter, it would be very helpful - to me - if one could first define the applications, and what's needed for them - I really lack knowledge here, but wouldn't be comfortable with programing things without knowing why.

One application I see would be to simply remote control the gimbal orientation, such as e.g. digaus is starting to do it (see e.g. here: http://www.rcgroups.com/forums/showpost.php?p=30806634&postcount=3652). My plan would be that the transmitted angles are NOT subject to the min/max settings. This would allow e.g. indefinite yaw turns, as digaus ask for. Also, any ground control, or app, or ap_mount could read out the min/max settings and ensure itself to obey them, if wanted. It seems to e that this would give most flexibility. Otherwise, it seems we are close to that application (except of the points mentioned before).

Another application I see is this gimbal follow-me thing. I don't know the correct wording, but I mean that thing that the gimbal always points to a target. I'm not sure how close APM is in this regard, and what would be needed from my side to get that working (as good or bad as it is working with other gimbals).

I mean, at the end we want to have something as good or even better than the DJI Inspire :)

Some thoughts from my side,
Olli

PS: as regards the method to send the attitude quaterion to the gimbal I'll come up with thoughts later

[Luis Vale Gonçalves]

Hi Gary

As usual Amazon is our friend :) I have one already ordered, but check this

http://www.engineer.jp/en/products/pa09e.html

http://www.amazon.com/Engineer-PA-09-Micro-Connector-Crimpers/dp/B002AVVO7K

brgds

Luis

[Luis Vale Gonçalves]

That's exactly my issue.

We can't use 2 devices on the same port that require RX and TX. I do have both Bluetooth and OSD in parallel but the OSD has de TX line disconnected. But can't get BT the 3DR 433 radio paralleled.

Adding the gimbal directly as a simple parallel connection is not viable, because it requires both TX and RX and also de baud rate that requires is different from either radio (BT and the 3DR433). Essentially the gimbal must reside alone on a serial port :).

Luis

[OlliW]

I think the gimbal should definitely get it's own serial, for various reasons, the real-time-ness of the data stream is one. 
I also think that at the end of the day one wouldn't want the possibilities be reduced by using a gimbal.

:)

[Gary McCray]

Hi Luis,

That actually looks great, but I notice that it doesn't actually mention DF13 crimp terminations anywhere.

And I checked every ad and review I could finds for this crimper.

Logic says that the 2 crimp process ought to work just fine on those itsy bitsy DF13 crimp connectors, but I would appreciate it if you would report your experience after you receive this.

I am sure a head mounted magnifier will be a help, but I would really like to know for sure if this performs a solid crimp.

The stupid Hirose DF 13 crimper varies from about $800.00 to $1150.00.

If this works at all satisfactorily I will immediately buy one.

Best Regards,

Gary

[Gary McCray]

OK found a reference at FPV lab that actually says this is the only generic crimper available for 1 mm crimps including DF13.

http://fpvlab.com/forums/printthread.php?t=8921&pp=40&page=3

I'll order one too Luis thanks for the reference.

Gary

[Luis Vale Gonçalves]

I ordered it because I've also read somewhere (eBay probably) that it could crimp those pesky DF13 plugs, and in fact on the picture on the manufacturer site it shows a DF13 (the tan plug).

Now I have to find a place to buy bulk DF13 plugs and pins (and also Micro Molex 1.25).......

brgds

Luis

[Luis Vale Gonçalves]

BTW

The manufacturer site has an application chart where the DF13 are included. They even mention a DF11 :)

http://www.engineer.jp/en/products/pa09_20applicatn_chart.html

Luis

[Олександр Чендеков]

Olli,

your work is great. I wonder why SimpleBGC haven't realised gimbal MAVlink control. About applications my one is about positioning of object found on video. To do this I need to have synchronous UAV attitude information, gamera attitude information, zoom factor, and object location on image. Also rangefinder can greatly improve accuracy if it can be directed accurately to object. Now this task needs aditional equpment to deal with yaw drift. Next step could be object positioning capable OSD, object tracking or even real time augmented vector map overlay. 

пʼятниця, 20 лютого 2015 р. 21:47:46 UTC+2 користувач OlliW написав:

[Gary McCray]

Hi Luis,

The chart you referenced above references the DF3 not the DF13.

The DF3 is a 2mm pitch connector as is the DF11 whereas the DF13 is a 1mm pitch connector which will require the 1.0 crimping die on the PA09 crimper.

the numbers after the DF do not directly relate to size and are simply model numbers.

Also the biggest wire you can use in DF13 is 28 gauge with 30 gauge more common.

Nonetheless, at least one other person is successfully using this crimper on a DF13 termination so it should be OK, if a bit tricky because of the exceptionally tiny size.

I am ordering one too.

Digikey stocks male and female pins and connector sockets.

Best Regards,

Gary

[Luis Vale Gonçalves]

Oh. Another note on the crimp tool. I just saw it is referenced at the original PixHawk site https://pixhawk.org/peripherals/cables

LoL

Sometimes obvious things are under our eyes :)

[Luis Vale Gonçalves]

Hi

After Randy's comment about having submitted the SToRM32 support to master I downloaded the Hexa build from 21/2 - ArduCopter-v2.px4.

I've noticed some changes on the parameters list, like the possibility of configuration for serial 3 and 4, which I assume that are related (at least serial 4) to this subject.

Also the changes of MNT parameters are quite relevant.

Unfortunately I was not able to test, as I couldn't find the options required to have it working.

The private build from Randy's fork worked fine, although hardcoded to serial 2. 

So I assume that I should wait a few more days to test answer build?

BTW: Great job Randy....As usual :)

Luis

On Monday, January 12, 2015 at 1:55:31 PM UTC, Randy Mackay wrote:

Tridge,

 

     If you have a moment could you review my febe-gimbal3 branch which has an attempt at splitting the AP_Mount library into a frontend/backend?

            https://github.com/rmackay9/rmackay9-ardupilot/tree/febe-gimbal3/libraries/AP_Mount

 

     The main purpose is to add support for MAVlink enabled mounts so you’ll see there’s a new AP_Mount_MAVLink class.  It’s still not fully functional though because I haven’t come up with a way to set the sysid and component id for the gimbal.  I plan to somehow pull that from the GCS_MAVLink::MALink_routing class.

 

      Some other changes include:

·         Moving support for a 2^nd gimbal into the library itself instead of having 2 separate mount objects created in the autopilot

·         Renamed the MODE parameter to DFLT_MODE (i.e. default mode) and added a separate _mode variable.  I did this because the only purpose of having the MODE parameter was so we could set the mode to a default mode at various times including startup and after a ROI command has completed.

·         Removed some configure_cmd and control_cmd which did nothing

·         Other bits of cleanup like replacing pointers with references

 

-Randy

[OlliW]

Hey All,

I've spend a bit time on figuring out the frames and Euler angles used in the APM, and consequences of differences to the STorM32.

I didn't found any direct description of the APM frame and Euler angle set, but from the pieces in the code I looked at I got convinced that APM uses exactly the same things as described by Bill Premerlani et al in their papers. So, I'll take that as a fact, please correct me if that's wrong. As regards the frames that means:

APM: x = front, y = right side, z = down to earth

This is also perfectly consistent with the angle behaviors described by Randy in the above.

The STorM32 uses the frame

STorM32: x = front, y = left side, z = up to sky

So, the angles for pitch and yaw are different in sign to APM, but roll have equal sign. This is perfectly consistent with Glenn's findings.

Conclusions: Pitch and Yaw angles need to be reversed in sign, Roll not.

Iff the Euler angle set would be the same. As speculated, APM indeed uses a set with the gimbal lock on pitch (signaled by the asin on pitch). Thus, the calculated yaw angle values match, but as soon as either roll or pitch is not zero, the values for roll and pitch differ between APM and STorM32 (besides that trivial sign thing just established). In many practical applications roll would probably be zero (or small); then this doesn't cause an issue. However, an additional issue occurs because pitch is calculated from an asin in APM but atan2 in STorM32, that means that on APM the pitch angle has a jump where the STorM32 is continuous. This affects when pitching 90° down, which is very common in practice. Due to that, pitch should be limited to something like +-85° (one also could implement some roll-over mechanism, but naive implementations may not work great when roll is not perfectly zero).

Conclusions: Either Pitch and Roll should be near zero, which may be achievable in may situations. Also Pitch should be restricted to +-85°, which I would consider a serious limitation practically wise.

[Lorenz Meier]

Hi,

The analysis sounds good, however, your proposal seems not very robust. Quaternion math is not very resource intense and would be the much better alternative. Requiring particular angle ranges is just not realistic and a weak design. We can just add new commands using that representation, so it would be easy for you to phase in.

MAVLink comes with tested functions for the conversion (be sure to update the c library to the version from today).

I'd be happy to help getting people started there. Mavlink as a whole is completely moving to the Hamiltonian quaternion representation as the only attitude representation.

-Lorenz

--

[OlliW]

Hey Lorenz

thanks for your thoughts, I'm not sure though they fit directly into the discussion.

At some point one has to convert to Euler angles, latest at the point where one wants to send signals to the gimbal motors. No way out here (at least as much as I can see).

I made no proposal at all in my last post, I was only summarizing some points, drawing conclusions, and emphasizing the constraints of the current situation ;). My proposal you find some posts in the above, which would be that "APM should calculate the correct gimbal Euler angles from e.g. quaternions (or supply the gimbal with the quaternion, but the former would be more appropriate)".

As regards efficiency I made the point that one doesn't want to use APM's Euler angles, convert them to e.g. quaternion, and then convert them to STorM32's Euler angles.

This maybe might not be to your liking, but I'm not convinced that the Mavlink framework is most suitable to accomplish all tasks ahead, it's IMHO not just a thing of the command set but of design (no criticism, just the realization that it's designed for other purposes).

:)

cheers, Olli

[Lorenz Meier]

I made a mathematical point. Don’t convert to Euler ever before mapping to the gimbal axes (and APM uses a quaternion in its internal attitude representation, so there is no Euler mapping before). I don’t see how any of that is related to MAVLink, I just highlighted that it has support functions which implement the conversion and are unit-tested.

From a software architecture point of view the gimbal should do the last conversion, because all messages on the bus should strictly use NED. There is really no reason you can’t do a few multiplications on the gimbal itself.

Cheers,

Lorenz

[OlliW]

maybe you want to reread my last three posts :)
cheers, Olli

[Randy Mackay]

OlliW,

 

     Re the attitude, yes, we’ve always used Bill Premerlani’s DCM so it makes sense that all the frames are consistent with Bill’s papers.  Recently we’ve introduced an EKF but we’ve kept the DCM’s conventions at least on the surface.

 

      We can do quaternions if that would be easier/better for you but it sounds like it’s not.  If we were to switch to quaternions we could use a COMMAND_LONG with a MAV_CMD_DO_MOUNT_CONTROL_QUAT inside it  (see http://mavlink.org/messages/common) and if it were helpful we could also send the vehicle attitude down as a quaternion using the ATTITUDE_QUATERNION message: http://mavlink.org/messages/common#ATTITUDE_QUATERNION.

 

     We talked about the SToRM32 gimbal on the dev call today with Luis for a respectable length of time and some technical notes are below.  These are mostly ardupilot improvements but:

·         We’d like to stick with using MAVLink messaging if possible but we’re going to make some improvements including:

a.       Automatically detecting which telemetry port the gimbal is attached to by listening for its heartbeat

b.      Query the gimbal for its min/max angles and write them to the ardupilot mount object’s min/max angles so it doesn’t ask for angles that the gimbal can’t provide and also reduce the ardupilot side’s setup burden for the user.

c.       Add an additional MAVLink channel to ardupilot/pixhawk so people can use the MAVLink enable SToRM32 gimbal without having to sacrifice a MAVLink port which may already be used for a MinimOSD and Telemetry.

 

-Randy

P.S. my SToRM32 gimbal arrived over the weekend so I now have hardware to experiment with.

--

[OlliW]

Hey Randy,

muchos gracias for these infos

btw: I'm currently working on implementing the MAV_DO_MOUNT_CONTROL in a way that the angles can be chosen to either be subject to the min/max limits given in the GUI as before, or to work independently on them allowing e.g. infinite yaw turns (as digaus likes it). You hence can choose then the option you like better.

One point I probably should make, to avoid confusion, is that the min/max limits are NOT absolute limits in the sense that they would limit the camera movement to these angles. They only define the angle range by which the camera can be moved via the various control inputs! As example, when the yaw axis is in hold mode and the copter is turned by 30°, then the camera will be 30° off the forward orientation, even if the min/max limits were set to e.g. +-20°. The +-20° limits just mean that then you give a stick input that the camera can be moved around only from 30-20 = 10° to 30+20 = 50°, in the above situation.

Anyway, the main point of this post is to ask about how the camera follow or ROI or leash thing (how do you guys call that feature?) is currently working in APM. I can't claim to understand the code, and maybe not even to have grasped the general concept. My impression so far is that, even with a 3 axis gimbal, the approach is simply that the copter is yawed into the direction of the object, and the pitch angle adjusted such, that the camera points at the object. Correct or not?
If this would be so, it would mean that the gimbal should be put into pan/follow mode on yaw, and any deadband should be set to zero. This is good in a sense since in this mode the STorM32 will work perfectly, i.e. won't be affected by any yaw drift. It would damped out yaw shakes, but would not completely remove them since that's what pan/follow mode means. In this mode one also could "decouple" the gimbal yaw from the copter yaw, that is remove the requirement that the copter needs to be turned into the direction of the object, that is the pilot could fly per FPV and yet the camera could target an object in any direction.

The ultimative goal however should - IMHO - be to have the gimbal in hold mode, which is at least what strives me, but the above might be fine for a first start. I'm just a bit worried that when approaching the ultimative goal some of the work spend now may become obsolete. If that would be a concern for you guys, then one maybe should consider if not to directly shoot at the ultimative goal.

Good to hear that you have a test system now, I would just wish that I would have gotten my AUAV-X2 already ... it was said mid/end February ...

cheers, Olli


PS: as regards (c), I think you may want to do this anyhow, not only for the STorM32 ... once available someone will find a use of it and attach some other mavlink mount to it. I would actually think that you would want to open as many channels as there are serials ...

[OlliW]

a question which I forgot to ask:

"Add an additional MAVLink channel to ardupilot/pixhawk so people can use the MAVLink enable SToRM32 gimbal without having to sacrifice a MAVLink port which may already be used for a MinimOSD and Telemetry."

how is this actually been done for the AM gimbal? Here you did use an unoccupied serial, not affecting the Mavlink capabilities? If so, wouldn't it just be easier to do the same for the STorM32 instead of venturing into that? At the end of the day one seems to have to introduce a special STorM AP_MOUNT anyhow, the native Mavlink AP_MOUNT doesn't do the trick?

[Nils Högberg]

This is fantastic work guys! I've wanted to buy the STorM32 for a long time but never got around to actually do it. Finally ordered a 1.31 board about two weeks ago. Can't wait to get it and try this with my Oculus Rift project that has been on ice for far too long now.

OlliW, have thought anything of adding CAN bus support to the next board revision? Wouldn't UAVCAN or mavlink via UAVCAN be superior to a serial interface?

[Luis Vale Gonçalves]

First tests for basic movement control via MP

https://www.youtube.com/watch?v=23x-5AQ2FSM

[Luis Vale Gonçalves]

Forgot to add the settings that MP receives from the STorM32

[Paul Riseborough]

A note of caution if using the APM maths library. Conversions to and from Euler angles currently assume a 321 rotation sequence which should not be used if you are dealing explicitly with gimbal joint angles, where the sequence is 312 (yaw,roll,pitch).

Moving to use of quaternions for communicating orientation over all interfaces avoids confusion associated to the various ways that Euler angles can be specified (rotation order and units) and means that the interface will work regardless of motion range.