Support for vicon_position_estimate on APM

[Tony Baltovski]

Hi,

I was wondering if it would be possible to add support for VICON_POSITION_ESTIMATE for APM?  I know that the PX4 has it.  Is there a reason why it would not be possible?

Thank you for your time.

Regards,

Tony

[Randy Mackay]

 

      I guess that would need to be combined in with the EKF?  We’d have to talk with Paul Riseborough about that.

 

-Randy

--
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.

[Ben Nizette]

This is a question that comes up every now and then, I keep meaning to
try and do something about it :)

Options:
1) Create fake GPS driver that reports position in earth frame from
external sources. Easy but can't take advantage of high accuracy/speed
of VICON specifically. Might need to change GPS delay factors
depending on link latency, processing latency etc
2) Extend EKF to fuse this data. Maths-y and given the accuracy of
VICON, perhaps not even particularly useful (fusion may not add
anything much unless the link goes down for a period)
3) Let EKF/DCM estimate attitude and use VICON input raw for position
information. Should be simple enough to graft this on to the EKF
"output"; very easy in the older DCM/INAV environment where this split
was already present.

All three are possible I reckon.

Ben.

On 28 August 2014 11:11, 'Randy Mackay' via drones-discuss

[Tony Baltovski]

Assuming that the mocap can provide a very accurate pose, I'd be willing to use it without a EKF for pose estimation but like Ben said, if the link goes down.  It would need to go down right away.  I was able to take the pose from the mocap and using an arbitrary starting location create a fakes GPS location but I am not sure how to get it to the APM unit, ideally over MAVLINK.  I have a desktop running ROS that I currently use to control the quad-rotor.  

[C Wong]

Ben, I tried the virtual/fake GPS driver approach in 2.9.1 and yes ran into timing/update issues working with safety, home position assignment, and pre-arm checks... too tightly coupled code. Not sure what's changed in 3.1.x on up. I put that task on hold (we have a vicon setup and wanted to use it as a cycle testing rig) to work on other s/w issues in our setup. Another way I've been pondering is throwing position updates right into AP_InertialNav and doing some data prep and wayside estimation, but we're going through a total rewrite of our onboard s/w to accommodate new [non-APM] hardware.

Option 3 will work, aka use vicon only for position, not pose/attitude. A lot of the universities use it for both and get killed on the latencies (we did! see next paragraph)--copter goes unstable but the pro is that it's WAY easier to model and program for collision avoidance, etc...

Our Disney Research/ETH system did option #2. Worked, but was a pain to tune unless we ran 200Hz update or more for the attitude control--but that's another discussion.

[Ben Nizette]

Hi

On 29 August 2014 00:38, C Wong <cwce...@gmail.com> wrote:
> Ben, I tried the virtual/fake GPS driver approach in 2.9.1 and yes ran into
> timing/update issues working with safety, home position assignment, and
> pre-arm checks... too tightly coupled code. Not sure what's changed in 3.1.x
> on up.

We did something similar with a UWB system back in 2.8, faked GPS -
the noise/latency model of the UWB system is actually pretty close to
GPS. Once you feed it an earth-frame origin the rest was fairly
straight-forward. I don't imagine VICON would be quite as easy,
indeed.

I put that task on hold (we have a vicon setup and wanted to use it
> as a cycle testing rig) to work on other s/w issues in our setup. Another
> way I've been pondering is throwing position updates right into
> AP_InertialNav and doing some data prep and wayside estimation, but we're
> going through a total rewrite of our onboard s/w to accommodate new
> [non-APM] hardware.

AP_IntertialNav has been largely (completely?) obsoleted by the new
EKF work. You're right though, it did provide a nice point at which
this kind of data could have been injected.

>
> Option 3 will work, aka use vicon only for position, not pose/attitude. A
> lot of the universities use it for both and get killed on the latencies (we
> did! see next paragraph)--copter goes unstable but the pro is that it's WAY
> easier to model and program for collision avoidance, etc...

Right, we tried using VICON for pose at my uni a little while back
(non-APM hardware); the update rate is fine but the (variable!)
wireless latency was not OK. I would recommend using Mocap for
position only unless you're really sure of your link solution.

[Ben Nizette]

On 28 August 2014 23:29, Tony Baltovski <tony.ba...@gmail.com> wrote:
> Assuming that the mocap can provide a very accurate pose, I'd be willing to
> use it without a EKF for pose estimation but like Ben said, if the link goes
> down. It would need to go down right away.

As above, I'd recommend using Mocap for position estimation, not
attitude. Even a stable link is likely to have sufficiently high and
variable latencies that you run in to attitude estimation problems.

I was able to take the pose
> from the mocap and using an arbitrary starting location create a fakes GPS
> location but I am not sure how to get it to the APM unit, ideally over
> MAVLINK. I have a desktop running ROS that I currently use to control the
> quad-rotor.

No problem using MAVLINK and a ROS/MAVLINK bridge. I agree that's the
right way to go.

Ben.

>
>

[Tony Baltovski]

As above, I'd recommend using Mocap for position estimation, not
attitude. Even a stable link is likely to have sufficiently high and
variable latencies that you run in to attitude estimation problems.

I only care about the yaw. 

 

No problem using MAVLINK and a ROS/MAVLINK bridge. I agree that's the
right way to go.

How did you actually implement this?  I have some control using the RC override over wireless but it isn't great.  I wanted to use the  VICON_POSITION_ESTIMATE but it is only for pixhawk currently.

Thanks for your help Ben.

[Ben Nizette]

On 30 August 2014 02:08, Tony Baltovski <tony.ba...@gmail.com> wrote:

>>
>> No problem using MAVLINK and a ROS/MAVLINK bridge. I agree that's the
>> right way to go.
>
>
> How did you actually implement this? I have some control using the RC
> override over wireless but it isn't great. I wanted to use the
> VICON_POSITION_ESTIMATE but it is only for pixhawk currently.

OK so I've implemented a fake-GPS-from-UWB thing in the past that used
a separate radio.

If I were doing it again I'd MUX the data in to the MAVLink stream as
you suggest.

Sure, probably the VICON_POSITION_ESTIMATE packet is the right format,
you'll write code to handle the receipt of that packet and feed it in
to a new fake-GPS driver, an extended EKF or whichever of the
aforementioned options you prefer.

If your implementation question is regarding the ROS Bridge
specifically, see
http://qgroundcontrol.org/dev/mavlink_ros_robot_operation_system_integration_tutorial

Ben.

>
> Thanks for your help Ben.
>

[C Wong]

Yep, as Ben said--create a new MAVLink packet spec duplicating the vicon packet (e.g. generate_mavlink_msg_code.sh). Not that difficult and duplicate the firmware that processes the incoming vicon estimate and you're up & running. If you're on Pixhawk, you'll have the memory/speed and not need to worry about double-precision errors. If you want to run this on APM, well, it's better to send the info over via integer math (diff mavlink packet spec).

Ben--I'm restricted to APM since I have a different safety system and additional h/w, as well as my ride engineering guys prohibit me to jump on the latest hardware and software until it's proven/cycled test/hardened. So I'm stuck with DCM/InertialNav for now. Imagine building the Indiana Jones ride vehicle and you get the point (which is basically what I'm doing, ugh). That means no ROS stuff, research code, etc..., though we're watching Savioke to see how their trials go--assuming they are still using ROS.

[Tony Baltovski]

Thank you both.  I am trying to use mavros as the bridge.   I have both a pixhawk and apm.  I will test sending the data from the mocap to the fcu.

Thank you again,

Tony

[Mike Klinker]

Has there been any progress/updates with this? I am about to integrate a pixhawk into our VICON space. Any words of wisdom?

Thanks,

Mike