Issues integrating Piksi with Pixhawk with Arducopter

[carlos jordan]

Greetings,

I am currently working with an X8+ using a Pixhawk with ArduCopter on version 3.3.3. We are trying to integrate the Piksi 2.3.1 for an accurate flight. Following the instructions provided for this matter on http://docs.swiftnav.com/wiki/Integrating_Piksi_with_the_Pixhawk_platform, its our understanding that it should work. But it doesn't ;) . We do get the GPS2 Status = 1 which means we do get the correspondent communication. But when it's needed to report a DGPS or RTK fix of 4 or 5, we never get those, even when on the Piksi console we get the message of it being fixed. Attached to this post are some photos of the current configuration of the piksi module on vehicle and on the stationary base.

parameters base station (1/2)

parameters base station (2/2)

parameters Piksi Vehicle (2/2)

parameters Piksi X8+ (2/2)

Any help on this issues will be much appreciated.

[dzo...@swift-nav.com]

Carlos,

Thank you so much for the detailed report and your images!

The coordinates you enter under the "surveyed position" grouping need very close the actual locations in order for the setup to work.  If you are unable to survey the coordinates, I suggest placing your base station on a landmark and choosing these coordinates from the map you might use to post-process your flights. 

Best,

Dennis

[Scott Slaughter]

Is an inaccurate survey position for the base the only cause for this? I've seen similar behavior where the Pixhawk doesn't register a RTK fix or even Float status, but in the console it shows a RTK Fixed position with an IAR of 1. Then, if I put the Piksi in simulation mode, it is correctly registered by the Pixhawk both through the LED and w/ GPS status in Mission Planner. Is there an obvious reason why the piksi would say it has an RTK fixed position, but that not be registered by the Pixhawk? Btw, in this case we've been using a single set of radios w/ injection through mavproxy. The red led blinks often and in the console for the vehicle piksi we can see both base and rover observations along with the RTK fixed status. For the base position we are just using one of the SPP solutions; we've had success in doing this w/ two sets of radios, so I'm curious if there's possibly any other issues. 

Thanks

-Scott 

[jkre...@swift-nav.com]

Scott,

Thanks for the update. Could you please detail what software you are using to inject the RTK messages? One of the following SBP messages will need to make it over the wire in order for the driver to work correctly:

SBP_MSG_BASE_POS_ECEF

SBP_MSG_BASE_POS_LLH

If you are using the udp_bridge.py script, please make ensure you're using the latest version - which can be found here: https://github.com/swift-nav/piksi_tools/blob/master/piksi_tools/ardupilot/udp_bridge.py

Thanks,

-Josh

[Scott S]

Josh,

To actually send the messages I've just been using the Piksi console application per here. I haven't yet used the udp_bridge script as I don't have the sbp package installed yet (unless it comes w/ the console). For the telemetry portion, I've tried it with Mission Planner 1.3.32 and more recently MavProxy. In mission planner I was having issues getting observations to the vehicle piksi at all and noticed that the LED would blink a few times when I first started injecting, but then stop. I couldn't figure out the cause for this, so I tried the DGPS module within MavProxy which consistently delivered the observations(https://github.com/Dronecode/MAVProxy/blob/master/MAVProxy/modules/mavproxy_DGPS.py). However, I then encountered the problem described above. I've also noticed w/ MavProxy that a set of messages is regularly thrown out because it exceeds the maximum message size in the module (110 bytes). It isn't every message, but it consistently happens while it is running, maybe 5 messages in a row every 15 seconds or something. In the udp_bridge file it looks like the BASE_POS messages are always sent w/ the observation messages. Is this true or is it a slower rate and is this the same way it's done in the console?

I plan to try it with the newest release of Mission Planner (1.3.37) soon along w/ the separate radio setup just to re-confirm I can get that to work and will get back w/ results. Thanks again for your help.

-Scott

[Scott S]

Just as an update:

- Using MP 1.3.37, injection worked quite a bit better than 32, but has same issue as Mavproxy w/ it getting a fix on console, but not reporting to Pixhawk. Possibly missing the BASE_POS message. 

- I was apparently looking at an old spec sheet for sbp and was looking for the wrong message type in the log so I'll have to check on that again. 

- Using the dual radio setup I can successfully get a Fixed RTK solution to register w/ Pixhawk, though a single, dedicated radio for Piksi comms w/out telemetry seems to be more reliable. 

-Scott

[carlos jordan]

So, it seems that I, like Scott, started to get info from the Piksi Station Base to the Pixhawk only in simulation mode; otherwise it takes too much time to get to a fixed position. Nevertheless I will try to modify the radios to transmit over UDP to see if it would work for me. Any good recommendations on trying this approach?. Thanks