Current Bugs/Issues with integration of Piksi and Pixhawk

[rai gohalwar]

Hi,

I am a student engineer working with the Department of Agriculture of Canada. I was hired to work on developing a drone to take aerial pictures and IR readings using the autonomous capabilities of a quad/drone.

I have been working with getting the Piksi integrated with the Pixhawk because of the precision I need for some experiments. 

There are quite a few things that have gone right and a lot more that have gone wrong. I just want to point some things that I have noticed. Maybe this information could be helpful for the developers to make improvements.

Firstly, I have noticed that the latest version of Arducopter doesn't have the option to integrate the piksi. However, the arduplane does. The beta version of arducopter does have the option, but the beta version is not reliable yet. It had bugs related to way point missions (Tested- copter just flies away around third waypoint and circles without command). 

I have noticed that the piksi looses a lot of satellite strength when other things are connected around it. Here is the satellite strength without anything plugged in compared to the pixhawk plugged in.

The strength drops down by 10 points. I am not sure about the units of the y-axis measurements. Similar behavior is seen when the 5.8ghz video transmitter is turned on. 

I am aware that the rf noise from the pixhawk and other electronics on board affect the strength. That is why I have the metal plate under the piksi. 

I have tried to move the board to different positions . I tried a bit forward. It is a bit better, but still not enough to get a solid gps coordinate. 

As of now, there is a little jitter effect that is being caused by the piksi. (At least, that is what it seems like). Here is a log of the gps signal jittering. 

 That flight was a straight line flight, and for some reason the gps coordinates jumped from the original flight path to a similar error. 

I have also come to notice that the piksi loses some strength when it is moved from its position. That is a problem since the copter is moving and vibrating. Here is a picture of strength when I moved it a little and also ran the copter. 

One possible problem may be that the bottom is not in direct contact with the bottom metal plate. It is supported by metal stand offs. 

I would love to know if someone else has had these issues. 

-Rai Gohalwar

 

[rai gohalwar]

I should add that next, I am going to try using an external antenna mounted in the center point with a 12 inch boom as recommenced on another thread of the swift-nav discussion group. :)

-Rai Gohalwar

[Colin Beighley]

Hi Rai.

Thanks for the thorough explanation of your setup! It's true that the Piksi driver for absolute position is in the stable release of Arduplane and the dev branch of Arducopter. RTK drivers will be coming soon and should be merged into stable releases of both platforms soon.

We have also noticed that Pixhawk and other onboard electronics emit quite a bit of noise. We recommend using a large ground plane and placing Piksi as far away from any other onboard electronics as possible. The v1.0 firmware should increase robustness in poor signal quality environments quite a bit.

Could you explain in more detail what you mean by "the piksi loses some strength when it is moved from its position." Is this when you move it by hand, or when the drone is flown, or both?

Thanks,
Colin

On Fri, Jun 20, 2014 at 11:27 AM, rai gohalwar <raigo...@gmail.com> wrote:

I should add that next, I am going to try using an external antenna mounted in the center point with a 12 inch boom as recommenced on another thread of the swift-nav discussion group. :)

-Rai Gohalwar

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

[LamorindaMarketing]

I'm also getting a signal strength drop when I move my rover. My Pixhawk/Piksi setup is pictured below with the Piksi antenna at the bottom.

Thanks

RoboBill

[rai gohalwar]

Hi brother, 

Could you please explain your set-up of the piksi with the pixhawk. I want to compare the configurations with different results. (Which port is the pixhawk connected to with the piksi. ). 

-Rai Gohalwar

[rai gohalwar]

Hi Colin,

What I meant was that when I move the rover by hand a bit, the strength drops as seen in one of the pictures above.  I can't tell if that happens while flying too because there is not a way yet for me to get the satellite information and strength through a wireless system. 

If there is a way, please let me know.

I am working on building a  bigger plate and also moving both the gps higher. I hope this will help. If not, I also have some microwave absorbent foam  which I may try as well. 

- Rai Gohalwar

 

[LamorindaMarketing]

My Piksi/Pixhawk is for a rover. The Piksi is connected to the GPS port with the Ublox connected to the Serial 4. I'm able to get a fixed RTK ... assuming I'm reading the console correctly. But the Mission planner shows my rover 50+ feet away from where it should be... i.e. I really don't know what I'm doing... except having a lot of fun trying this and that. 

I'm also hoping that someone over at the DIYDrone User Group will form a navigation group so all us Piksi lovers (along with NavSpark and others) can exchange ideas.

RoboBill

[Colin Beighley]

Rai - interesting about the SNR drop. I'm not sure why this would be. The bigger plate should definitely help, and the microwave absorbent foam could help as well depending on how you place it. The v1.0 firmware should improve marginal signal tracking greatly.

Bill - the Arducopter drivers for Piksi are still incomplete - Niels has been working on them and has the RTK driver working on his quad quite well though, so it should only be a short amount of time before it gets merged into master.

Colin

--

[rai gohalwar]

Hi Colin, 

I am glad that Swiftnav is making progress getting the RTK working on the quad. It would be very nice if you could tell me when the RTK firmware that Niels is working on would be accessible?

-Rai Gohalwar

[Niels Joubert]

The Piksi driver for Pixhawk passed community approval today and is now just waiting for the lead dev to merge it in. 

https://github.com/diydrones/ardupilot/pull/1137

Once this is in master you can flash your vehicle with the latest nightly build code and run with RTK. A integration guide is also in the works on the Swift-Nav wiki!

[Goh Guo Dong]

I have uploaded the latest arducopter code (the one which has the piksi driver) into pixhawk. I got the chance to test it today. I had a good reception of satellite signals and I managed to get 7 common GPS signals. The connections were done according to the Piksi on ArduPilot integration tutorial as shown below.

I didn't connect the rover's Piksi, which is connected to Pixhawk, to the computer via USB as I wasn't sure whether powering the piksi via USB and UART at the same time would damage or burn the Piksi ( I would like to know if it is safe to do so). Since the piksi at the base station was connected to the computer, I was able to monitor the satellite signals and the status of the Piksi. Both the Piksi-es managed to acquire 8 satellites( and had 7 in common) in less than 5 minutes, but it didn't enter RTK mode even after 20 minutes ( the IAR number just stopped at 888) and I had to reset the IAR filter for the base station. After resetting, the base station managed to enter RTK mode in 5 minutes. but what I am not sure is that : will the piksi connected to the Pixhawk enter RTK mode as well when the base station enters RTK mode? Is there any indication in the Mission Planner or on the Piksi itself that the Piksi is in RTK mode? Based on my observation, the GPS's location was fluctuating on the map at the range of 5 meters. i am sure that RTK doesn't provide this kind of accurary. I would like to know how RTK works in pixhawk, do I have to arm it to activate the RTK?

[LamorindaMarketing]

Good morning from the S.F. East Bay

I've hooked my Piksi to the primary GPS input on my Pixhawk. After a while I do get an indication on the HUD that I've got a healthy GPS. But my rover's position still jumps around. With so many parameters, I have no clue what parameters to set to what. I did settle things down quite a bit when I turned off the Kalman Filter so I figure I'm going to wait for Niels to finish his implementation tutorial. 

Still lots of fun!

RoboBill

[rai gohalwar]

Hi world, 

Something else I have notice with the piksi.

Firstly, I must say that one of my piksi is much quicker at picking satellites than the other one. Don't know why.

I have noticed sudden drops in strength on all the satellites while the piksi is connected to the laptop. My only prediction is that there is probably some interference coming from the laptop beside the piksi.

Here is the picture.

-Rai Gohalwar

[Niels Joubert]

Hi guys!

Ah wow you guys found the integration tutorial already haha :)

The Piksi Driver is done - passed community inspection and is finally ready for flying. The ArduCopter's Kalman filter is the next challenge - it's tuned for normal GPSes, and currently doesn't use GPS height at all. I'm flying the old DCM localization and will post parameters for it once we have a good tune. I'm also talking to Paul Riseborough, who wrote the Kalman filter, about getting it tuned for Piksi. 

I'm currently working on improving the efficiency of the SBP protocol's observation messages so that we can sustain 5Hz RTK throughput over the 3DR radios (and MAVLink). This is also necessary for achieving good flight with Piksi.

Fergus is demoing the latest build of the new FPGA NAP, and it looks sweet. Much faster and more sensitive acquisition. 

I'll further the integration guide tomorrow so you guys can get these up and running :)

Thanks for all the patience! I can't wait to get logs from everyone with Piksi performance data for us! You'll notice that several new dataflash messages show up with Piksi, and there's a new MAVLink message for RTK-specific info as well!

-Niels

[Niels Joubert]

Hi Goh!

You can plug USB into the Rover's piksi to monitor health as well.

The latest driver will hopefully make that unnecessary though since it reports the relevant information down through MAVLink messages. 

The base and rover actually runs the RTK algorithm independently, so the rover might not be in RTK mode even though the base station is. You probably ran into this!

Can you post a picture of your rover setup? I'm curious to see your antenna setup.

On Wednesday, July 2, 2014 6:18:32 AM UTC-7, Goh Guo Dong wrote:

[Goh Guo Dong]

Hi Niel,

If you are wondering how I can get good signal strengths, that's because I haven't connected the other devices to pixhawk. what I have connected so far is just as shown in the picture that i attached, the only difference is that I attached an external antenna to the base and the rover's piksi remained using the built in antenna ( it still got 8 satellite though). For your information, I connect the pixhawk to the computer using USB instead of using the telemetry. I guess that's explains the good signal strengths.

[Goh Guo Dong]

Hi NIel,

I will try to connect the other devices to pixhawk asap and let you know how it performs.

Regards

Goh Guo Dong

[rai gohalwar]

Hi,

I would like to know what the graph in the piksi console represents. It seems like the x-axis is time. I am guessing y-axis is a ratio between strength and noise. 

-Rai Gohalwar

[Goh Guo Dong]

I am facing problem when the Piksi gets RTK fix. I notice that whenever the GPS gets an RTK fix, the GPS status on the Hud in the Mission Planner will jump between 3D fix and No GPS (No GPS most of the time) and rarely gets into 3D rtk. The images below show that message I got in the MP.

I couldn't capture the screen shot of the 3D rtk as it just appears in a split of a second. May I know why it is so? For your infomation, I am not using the latest version of MP, Could it be the reason for the No GPS issue?

[Goh Guo Dong]

Hi Niels,

The picture below is the setup of  my quad.

Interesting enough though, I didn't experience any interference even though the antennas of the telemetries were very close to the piksi's antenna. The picture below shows the signal strengths of the satellites that piksi managed to acquire in less than 5 minutes.

[LamorindaMarketing]

Good morning Goh,

I too have gotten no GPS RTK Fix in the HUD of the MP ... even when using the latest MP stable and beta. And if I've read your MP pic correctly you also have your current stationary position jumping all over the place. But I'm still on v0.8 cuz 1) upgrading to .9 or 1.0 beta is currently too complicated and 2) with ground planes on both rover and base my peak signal strength is close to 20.

RoboBill

[Niels Joubert]

If you are not yet running the very latest unstable build of ArduCopter you wouldn't be able to get an RTK fix. You can get it here: http://firmware.diydrones.com/Copter/latest/

Is that what you're running?

[Goh Guo Dong]

Hi Rai

I am sure I have downloaded it from Git Hub as it does enter 3d RTK but rarely ( it appears in a split of a second even it does). Do you mean you have successfully gotten RTK fix on MP? Anyway, I will try downloading it using the link you have provided. Could you teach me how to download it using the link?

Regards

Goh Guo Dong

[rai gohalwar]

Hi,

I have not been able to try the RTK yet because of the really bad weather where I am . Inside, I don't get any satellites because I am in a basement. Outside there is a rain storm.

I'll try and update.

-Rai Gohalwar

[LamorindaMarketing]

Niels

i'm running the latest rover firmware and i'm so confused with the different versions. so should i be able to get rtk with with he rover? is there any performance difference between the mission planner and the apm planner

thanks

robobill

[rai gohalwar]

Hi Niels,

I just upgraded to the latest version of arducopter from your link. Which firmware do you need on the piksi's to get the RTK going? And could you also quickly summarize the gps parameter setup?

- Rai Gohalwar

[Niels Joubert]

Hi Robobill,

The Plane and Rover doesnt have the RTK initialization hooked up at the moment - the Copter code initializes its home location when arming happens, but the rover and plane code is less clear how that works. We need to get someone with experience in the Rover and Plane code to call a single function, like here: https://github.com/diydrones/ardupilot/blob/master/ArduCopter/ArduCopter.pde#L1295

I'll ask around on the mailing list and get it integrated here as well - thanks for the patience! I'm trying tom get this out in between my PhD research as quickly as possible so bear with me :)

[Niels Joubert]

Hi Rai!

Have you been able to get an RTK fix (fix type 5) showing up using Piksi on ArduCopter?

I suggest you stick Piksi into simulation mode and see if mission planner returns an RTK fix. It won't go into RTK if it is armed - you have to get an RTK fix first before arming!

The driver is agnostic to which exact version Piksi is running, as long as its kicking out SBP messages for position, velocity and baselines we're good to go!

Try that out and see if you can fake an RTK fix using the simulator.

[LamorindaMarketing]

Good evening Niels,

Thanks so much for the clarification. So while you juggle Piksi and school work, I still have a lot of learning to do with the mission planner(s) to keep me busy.

Best,

RoboBill

[rai gohalwar]

Hi Wold,

So, I have done a few tests pointed towards getting rid of the noise created by all the other electronics on a rover, such as the flight controller and fpv gear. 

All my tests have been with the pixhawk flight controller and a 200mW 5.8Ghz video transmitter.

Test 1: Micro Wave absorbent paper shield. 

Noise from pixhawk (no shielding)

 After (adding a paper thin skin of rf shielding paper)

As you can see, there is almost no noise that goes to the pixhawk. The paper thin sheet of paper onthe carbon plate between the gps and the pixhawk does the job fantastically. 

Test 2 (affects of fpv gear)

before

After ( adding an external gps patch antenna moved up with a carbon rod base)

As you may see, only a few sats are affected. 

Results: I have been able to get rid of almost all the noise with just a few grams of accessories. 

Question: I wanted to know if people have been able to get an rtk fix on the new firmware. I have been able to get as close as a flot position with about a distance of 50 units. If yes, I would love some help.

-Rai Gohalwar

[Goh Guo Dong]

Hi Rai and Robobill,

I would like to know if you have successfully gotten an 3D RTK on mission planner or apm planner? I am still having difficulty getting 3D rtk using the arducopter code.

Regards,

Goh Guo Dong

[LamorindaMarketing]

Hi Goh

I have not been able to get a RTK fix on either because I'm running a rover and Niels hasn't had time to complete the firmware for us roverdudes.  We are lowest on the ardupilot priority list.

But based on Rai's very cool noise test, I am going to do some of my own shielding to see if I can reduce rover emi.

Good luck to all

RoboBill

[Niels Joubert]

Awesome setup Rai! Really great!! 

I have also not been able to get an RTK fix on the new firmware, which sucks because its so much faster than the old one haha! These guys are cranking on it :)

Rai, Have you tried to get your copter to report RTK fix using the simulation mode on Piksi?

Protip that I'm hesitant to share! If you want to have the copter use the float lock (aka dgps but not full rtk) you can change this parameter: http://copter.ardupilot.com/wiki/arducopter-parameters/#Minimum_Lock_Type_Accepted_for_DGPS_GPS_DGPS_MIN_LOCK

Set it to anything below 50 and it'll lock onto DGPS. Your home position will jump all over the place as the filter converges, which is why i don't recommend running in this, but once it's converged you should be able to try and hover it using this. Stand by to take over manually if things go south!

[Goh Guo Dong]

Hi Rai,

a very detailed explanation. However, I am skeptical about the position of the antenna. I was thinking since this RTK set provides an accuracy of 2cm, the antenna,

 being thecentre of the GPS, should be placed as close as possible to the center of the vehicle. With the antenna's position being placed about 10cm off the rotation

 center in the vertical direction, wouldn't it produce errors when the quad is doing rolling and pitching motions? let's say the quad is doing a 10 degree roll, a

 positional error of 1.7cm will be produced. well, it may seem negligible compared to the normal GPSes, but then, using  Piksi is all about accuracy it can 

achieve, isn't it? So I was thinking that you could try lowering the level of the antenna to half of the current level and mounting it on a metal plate and see if you could

 obtain the same signal strengths. By doing so you could reduce the unwanted errors. that's my two cents' worth.

Regards,

Goh Guo Dong

On Thursday, July 10, 2014 3:12:23 AM UTC+8, rai gohalwar wrote:

[Henry Hallam]

I don't know anything about Pixhawk or Ardupilot but in a similar rtk-on-uav application we subtracted the known arm from the vehicle cg to the GPS antenna (using the vehicle attitude estimate).

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

[Goh Guo Dong]

Hi Henry,

I get what you mean. Thanks for the explanation.

[rai gohalwar]

Hi World, 

Ok, Here is my answer to everyone asking.... 

So, I have been able to get mission planner to recognize an RTK gps lock only with the piksi in Simulation Mode (Where it fakes an RTK fix) - thanks for the idea Niels. That being said, I have spend about 15 hours outside trying to get an RTK fix with the two piksi boards just by them self with clear sky - no luck :( . Once they can physically go into RTK mode, the mission planner will have no problem recognizing the signal. (Please correct me if I am wrong)

Niels- I don't want to be rude or anything, but I would not recommend using the float lock. From the data I have collected, the piksi has a tendency of jerking from position to position depending on the # of sats and which sats are being used currently. However, I will leave it on you (you are way more knowledgeable in this field than me) :) 

Goh Gou Dong- You are absolutely right brother. I am planning to bring the gps patch antenna a couple of inches lower and use some more of that RF shielding tape to rid the noise. I am also thinking of changing my FPV video frequency. Reason being, I did a test to see which frequencies create the most noise to the piksi. 5.8ghz range was one of the higher ones. I will keep you updated.

- Rai Gohalwar

[Niels Joubert]

Hi Rai,

I also do not recommend using the float lock.

[rai gohalwar]

Hi Niels, 

Sorry, I didn't read the end of your last post, you said basically what I recommended lol hahaha...

I look stupid now..... hahaha

- Rai Gohalwar

[Goh Guo Dong]

Hi Niels,

After several tests, the followings are what I observed.

In the first test, I ran the simulation mode. I found out that the Piksi was always in float mode and it didn't enter fixed RTK. I tried to change several parameters in the setting tab of the console but it still didn't work. Hence, I decided to change the parameter of the DGPS_MIN_LOCK to 49 and I successfully got 3D RTK on mission planner.

In the second test, Piksi was run in real environment and the parameter of the DGPS_MIN_LOCK was reset to 100. When the Piksi was in RTK float mode, as expected, Mission planner displayed 3D fix as it still was not in RTK mode. While the piksi was still in RTK float mode, I changed the parameter of the DGPS_MIN_LOCK to 49. However, the mission planner was not displaying 3D RTK this time as it did when using the simulation mode. Instead, it showed "No GPS" and sometime "3D fix".

I guess this explains why i don't get 3D RTK on mission planner when piksi enters RTK mode.  Since I managed to get 3D RTK in simulation mode with lower value of DGPS_MIN_LOCK, It makes me wonder if the information being output in the simulation mode and in  real environment is different. May I know if there is any way to make the Piksi enter fixed RTK in simulation mode? Can somebody explain this phenomenon?

Regards,

Goh Guo Dong

[Niels Joubert]

Hi Goh!

You can indeed make Simulation output RTK fixes. Make sure your SIMLUATION_MODE setting is set to 15. This is pretty vague at the moment, i know! that value comes from the simuation mode bitmask in simulator.h, if it is 15 it will flags to output RTK fixes.

[Niels Joubert]

Hi RoboBill!

Jonathan Challinger told me that you were asking him about Piksi. We had a conversation about your requirements to have a fixed base station position, and I wrote the code to support that.

This patch adds 4 parameters to the ArduPilot codebase: DGPS_GIVEN_BASE and DGPS_BASE_LAT/LON/ALT. If you set the LAT/LON/ALT to your base Piksi's true accurate position, and set GIVEN_BASE to 1, you will get centimeter-accurate positioning relative to that given position. This should be what you need to have your rover always navigate relative to the true fixed position of your base station.

It's currently waiting to go through community approval here: https://github.com/diydrones/ardupilot/pull/1228

As a side plus, if you program this base station position, my driver never has to calculate this home position. This will enable the RTK GPS for a rover or plane. 

Jonathan Challinger is adding the funcionality to enable the GPS in general for Rovers and Planes. It's a two-line addition to the current codebase - calling a function to check whether we can calculate our fixed base station position, and doing it when ready. We want to ensure that this only happens while everything is stationary, hence we're being careful with how to integrate this.

Cheers!

-Niels

[LamorindaMarketing]

This is good news. I'll give it a try as soon as the firmware becomes available and report back.

Thanks

RoboBill

[Goh Guo Dong]

Hi Niels,

The piksi doesn't enter fixed RTK in simulation mode even when I change the mode mask value to 15.For your information, I have tried all values from 1 to 15. Is there anything else I should take note of in order to let it enter RTK in simulation mode?

In addition to that, I have a question remains unanswered. that is when piksi enters fixed RTK mode in real environment, the pixhawk will go from 3D fix to No GPS and 3D RTK might appear in a split second occasionally. May I know why it is so? Is there anything I need to set in the arducopter code? Is there anyone experiencing the same problem ?

Regards,

Goh Guo Dong

[Niels Joubert]

IT sounds like you're running an old version of the ArduCopter driver. The latest build should not have any of these issues.

[Goh Guo Dong]

Hi Niels,

I downloaded the latest ardupilot from GitHub today. The version of firmware is ArduCopter V3.2-rc3 as shown in the screenshot.

 I tried it again today but the same problem persisted.

The video link shows the message i got on HUD when piksi enters fixed RTK. Please take a look at the 1 minute video especially after 45 seconds.

http://youtu.be/oc2KFNonG7Y

-Goh Guo Dong

[LamorindaMarketing]

Hi Niels

I tried the alpha that Jonathan gave me and it wouldn't let me save any parameters.... assuming I put in the correct numbers.

For example our Coit Tower would be 

DGPS_BASE_ALT = the altitude in cm's

DGPS_GIVEN_BASE = 1

DGPS_BASE_LAT = 378023865.80116924

DGPS_BASE_LON = -1224059021.4729309

I am wondering why you want the number in this form where I see you dividing by 10^7 in the program. 

Thanks

RoboBill

[Niels Joubert]

Hi Bill!

Is it Bill actually?

A degree*1e7 gives us centimeter-accurate positioning using a 32 bit number - the largest the 8-bit micros support, and the parameter system 

Only enter the whole part of the lat and lon! The fractional parts cannot be represented - thats why we multiply by 10^7. 

Just to make sure we're on the same page - the BASE_LAT/LON/ALT is the exact position of the base station Piksi's position.

[Niels Joubert]

I see, that's very strange - I don't get that behavior on my side.

I'd like to get my hands on a log! Can you attempt to arm the copter (no need to fly!) and perhaps just move it around in your hand a bit. The copter will write a dataflash log with all the internal driver details to the Pixhawk's SD card. Can you pull that off and email me?

You can also take a look at the dataflash log - there'll be a bunch of "SBxx" logs which is Swift-specific. Let's see what's going on!

-Niels

[LamorindaMarketing]

Niels

OK I entered just the integer values for the lat/lon/alt 

for example Lat = 378023865 Long = -1224059021  alt = 29260

(I got my actual location from whatsmygps.com)

but I still get an error message saying it was unable to write the parameter values to the Pixhawk

Thanks

(Robo) Bill

[Goh Guo Dong]

Hi Niels,

The attached zipped file contains the logs details. I notice in one case, although the HUD displays no GPS and 3d fix, the GPS is just fixed still at one point without jumping around on the map even when the map is enlarge to the maximum level. Weird, i will try to do more tests to verify.

Regards,

Goh Guo Dong

[Goh Guo Dong]

Hi Niels,

I have tried to browse through the logs myself and I notice that the "SBxx" logs are intermittent. The SBxx logs just appear one or two lines once a while. It doesn't look like "a bunch" of logs to me like what you have said. Is it supposed to be like that? I wonder if it is the intermittency of the driver that causes the pixhawk not being able to get a rtk fix.

Regards,

Goh Guo Dong

[Niels Joubert]

Take a look at the timestamps of the logged messages. There is nothing to log in between GPS updates, thus they will be logged every time a packet is received from the GPS. If you're running RTK at 5hz then this will be coming in at 5hz. This is much lower than the high-rate IMU date.

The 3 logs you sent me have some incredibly strange data in it. Are you running both the UBLOX and Piksi GPS I assume? Which one is GPS1 and which is GPS2?

It looks like the HDOP value is above what ArduCopter will accept as good. You can change that by changing GPS_HDOP_GOOD parameter. 

In all your logs the TimeMS value doesn't appear to be incrementing as expected. This works fine in my logs, so it's surprising to see this. I'm assuming you're running a version from firmware.diydrones.com correct?

[Goh Guo Dong]

Hi Niels,

The piksi was connected to the GPS port, ublox is connected to serial 4/5. Both the parameters for the GPS1 and GPS2 in parameters list are set to 1 which is AUTO. 

I will try to change the value of the HDOP.

I was running the newest version of firmware from the link you gave in the email. I got the same result from 2 of my pixhawks.

Regards,

Goh Guo Dong

[Goh Guo Dong]

Hi Niels,

I just looked through the logs, it seems like Piksi is GPS1 and ublox is GPS2 as piksis is not good at acquiring satellites for this v0.8.

-Goh Guo Dong

[Goh Guo Dong]

Hi Niels,

I have tried unplugging the piksi and connecting only the ublox module. I notice the timeMS still jumps to a larger value. I really have no idea why it behaves like that. Could the sudden jump in value be the reason for not being able to get rtk fix?

[rai gohalwar]

Hi World, 

Have been off for a while!!! I am a bit upset for the time its taking to get this thing running. I would really appreciate if the swift-nav team could project a date of some sort. I mean the purpose behind this product was to be used on an aerial vehicle in the first place. The research team I am in has not been able to get good data this summer partially because of the unreliability of the piksi at the moment. 

That being said, I am willing to contribute in any manner as required. If there is anything that needs to be done, I am willing to take a look at it and spend as much time as needed to get this thing working. 

My research team is at a hault because of this. We were promised april 15th for this product to be functional.  We am extremely disappointed at this moment. This is not a $30 GPS  and I would love to see some results. I don't want to see the research team's money to go down the drain. So again, if there is anything we can do, just throw it at us and we will try our best to make it happen.

-Rai Gohalwar

AGRI

[LamorindaMarketing]

Good afternoon Rai

I too am pacing back and forth but then I think of the alternative.... which for me is going back to my arduino UNO controller... no thanks. My rover really needs this Piksi to work... but at the same time I realize Swift is a start-up and by definition "no guarantees". I figure all I can do is to provide as much feed back as possible albeit from a beginners POV... Heck it took me more than an hour to figure out how to DL a hex file and  8+ hours to figure out how to install the latest firmware.

Best Regards

RoboBill

[Niels Joubert]

Hi Rai!

I have a lot of sympathy with your situation - I'm in a similar boat on this side. On the plus side, I had my first autonomous flight under RTK control yesterday! 

The latest build of the Piksi - built yesterday - incorporates most of the changes we've been pushing. First thing you can help with is to get more community feedback on whether this version is good enough by now: http://download.swift-nav.com/piksi_v2.3.1/stm_fw/

Flash the v0.9 build to your NAP and STM and give it a shot! This has a more efficient radio protocol I've implemented, and a much improved acquisition system. The parts still in flight is propagating observations for more latency tolerancy, and increased tracking sensitivity.

What is your main failure point at the moment? If you're willing to contribute that will help! I'd be happy to have more help getting all the parts running well.

Is the 3dr radios a big failure point for you? I've had a lot of luck replacing the 3dr ones with WiFly radios. As a stopgap for the moment you can consider going the same direction.

One thing you can work on that would be helpful is to integrate the observation messages into the mavlink protocol itself, so that the same radio used for telemetry purposes can also send observation messages upstream. Are you currently configured for doing ArduPilot development work - can you build custom APM code for the Pixhawk?

Keep pushing, we'll get there! I, also, would like to graduate sometime soon haha!

-Niels

On Wednesday, July 30, 2014 11:00:12 AM UTC-7, rai gohalwar wrote:

[Niels Joubert]

Oh great, have you had success flashing the latest firmware to Piksi then Bill?

[LamorindaMarketing]

Yes I think I have... but I get this "message" from the console

acq: PRN 20 found @ -6243 Hz, 21 SNR

Disabling channel 4

Traceback (most recent call last):

  File "c:\Documents and Settings\Fergus Noble\piksi_firmware\scripts\pyinstaller\build\console\out00-PYZ.pyz\serial_link", line 97, in run

  File "c:\Documents and Settings\Fergus Noble\piksi_firmware\scripts\pyinstaller\build\console\out00-PYZ.pyz\system_monitor_view", line 104, in uart_state_callback

error: unpack requires a string argument of length 12

Did I do something wrong or what?

Thanks

RoboBill

[Niels Joubert]

Hi Bill!

No, your piksis should be working - but the console version is now outdated! Ah, sorry, this is a tricky problem we always get into with beta builds and attempting to keep everything in sync version-wise!

Let me have these guys get a new version of the console up real quick. Our mistake!

[Niels Joubert]

No, the time shouldn't be an issue, but this is strange behavior. We should ask the APM developers in drones-discuss about this.

[Goh Guo Dong]

Hi Niels,

Wow!! It's great to hear that your RTK control worked. But I have no luck here to get it work. My timeMS for the GPS is still jumping high. I was thinking if I should get a new pixhawk to try my luck.I would like to ask if the timeMS is the culprit of the no RTK fix?

Regards,

Goh Guo Dong

[Niels Joubert]

Ah yes, we've been rapidly iterating on the firmware and I think I now have a build that's better.

Try out the very latest from http://download.swift-nav.com/piksi_v2.3.1/

v0.9-123

Can you confirm that your Piksi is running at 115200 on the UART that is connected to Pixhawk, and that the mode mask as 65280

I saw similat behavior to what you reported for the first time yesterday, and it looked as if messages across the UART was being dropped. This caused Pixhawk to lose the RTK fix even if Piksi was maintaining it. I'm looking into this at the moment, and having some more data from you would be helpful! Can you check that your cable is good? do you have a way to look at the raw mavlink stream on your side and look at the GPS_RAW messages - see if the GPS completely disappears when it goes int RTK (all the GPS_RAW messages go to 0?)

[Goh Guo Dong]

Hi Niels,

I will try the latest firmware. 

How do I check whether the Piksi is running at 115200? can it be found on the console?

Regards,

Goh Guo DONg

[Goh Guo Dong]

Hi Niels,

I just confirmed that the piksi was indeed running at 115200 as mode mask as 65280. However,it is interesting to note that both the ublox and piksi experience the same timeMS jump.

As for the raw mavlik stream, i think i will need sometime to figure out how to look for the GPS_RAW. I will update you after i check it.

-Goh Guo Dong

[Goh Guo Dong]

Hi Niels,

I have checked the cable and it is in good condition. I have also looked at the GPS_RAW messages, All the GPS_RAW messages indeed go to 0 some of the time. In addition to that, the data coming from Piksi seem to be not so consistent compared to the ublox GPS which is GPS2.You may want to see the attached file for more details. Please search for mavlink_gps_raw_int_t as piksi is GPS1.

Regards,

Goh Guo Dong

[LamorindaMarketing]

Good morning Niels,

Beautiful day here and I've got 7+ sats acquired real quick, but I am not able to get a fixed RTK on the Piksi and I only get a 3D Fix on my Pixhawk with the second GPS (the 3DR ublox) configured as none. I do not get any data on the observations screen

RoboBill 

[rai gohalwar]

Hi RoboBill,

I have noticed that the observation screen is not in action. Could be just a simple error in the code. However, if you look at the baseline tab, (if everything is working fine) you should see a floating lock. I have also managed to get a rtk fix as well. However, it doesn't last more than 1-2 minutes. 

- Rai Gohalwar

[rai gohalwar]

Hi Niels, Thanks for the reply!

1. I have done some tests today with the updated firmware. It seems to be a little better at getting a RTK fix, however it looses it after a minute or two. Moreover, when I move one of the units, it also looses the rtk fix. (I'll post a picture of the setup tomorrow, I just wrapped things up here)

2. I have also noticed that during the floating mode, one of the piksi suddenly stops sending/receiving data via the 3dr radio. I confirmed that as the red led wasn't blinking on one of them. It would automatically turn back on in about 2 minutes. I noticed you have mentioned 3dr radios in your post. I would love to know if you were having similar problems. 

if yes, i wounder if the problem is in the code, because I use the same radio for telemetry on the pixhawk. 

3. yes, I can configure and build code for the pixhawk using make. I have dome some mods to the code for some custom sensors.  I will look into getting the observations data through pixhawk!!! 

Great!!! I am really excited to see this thing rolling!!! 

- Rai Gohalwar

[LamorindaMarketing]

Hi Rai,

Yes I did two plus marks on that screen.... sometimes they would settle down and I thought maybe I'd get an RTK Fix... but nope... other times one red mark would take off by 1000's of meters.

Niels... A confession... I do not have horizon to horizon but with 6+ sats I figure I should be OK... yes/no?

RoboBill

[Goh Guo Dong]

Hi Niels,

I have tried uploading the new firmware. However, i experienced problem uploading the new firmware on one of the piksi. it says flash operation returned error. The other piksi has no problem with the uploading. May i know why it is so?

-Goh Guo Dong

[Niels Joubert]

Hi Goh!

Did you have both Piksis powered on? I have found that you should flash Piksis with no radio connected - they can interact over the radio link if both are powered on and the one is flashing!

[Goh Guo Dong]

Hi Niels

I have successfully uploaded the file after disconnecting the radio. Apart from that, I have also tried the new firmware, it looks great, it managed to get a RTK fix in 5 minutes. However, the pixhawk is still unable to get RTK fix and is still getting no GPS whenever piksi enters RTK mode. Would you like to have more log files to see what's going on?

-Goh Guo Dong

[Goh Guo Dong]

Oh yes, one thing to add on. I notice that when the piksi enters RTK mode, the position shown on the map in the mission planner is still the normal GPS solution instead of the RTK mode and the HUD displays no GPS instead of 3D RTK.

-Goh Guo Dong

[rai gohalwar]

Hi World, 

Just wanted to post some things I have been noticing about the piksi and the new firmware that could be used to improve it.

1. I have noticed that the RTK fix doesn't stay for long. Once in the RTK mode, it will stay there until a satellite is added or dropped. This results in the sudden increase of the integer ambiguity resolution. Which results in the piksi loosing its RTK fix and going back to the float to recalculate the RTK. (Something like a prevention of satellite addition in RTK mode could be added to the code)

2. I have noticed that radios start failing out of no certain pattern. I know that the flashing red led means that the piksi is transmitting/ receiving. I don't know exactly what the led light indicates. The reason I say is because I have noticed that the radio before quitting flashes with really long pauses compared to the one that doesn't fail. Maybe, it stops because of access of information trying to be sent . I have also noticed that the rover one usually quits first. 

3. Finally, something positive. :)   I have seen that moving the piksi once in RTK mode doesn't anymore effect the performance or the lock. Previously, I would loose an RTK fix when I moved the rover. This is GREAT!!!!!

- Rai Gohalwar

[LamorindaMarketing]

Hi Rai

Thanks for your observations. I am curious about rover interference with the Piksi. Did you notice any signal loss or other affect when you drove your rover?

Thanks

RoboBill

[Goh Guo Dong]

Hi Niels,

I tried it again today. I realized that the pixhawk has no problem getting the data from piksi when the piksi is still not in RTK mode. the GPS data are dropped only when piksi goes into RTK mode.

-Goh Guo Dong

[rai gohalwar]

Hi RoboBill,

Sorry for the confusion. By rover I meant the piksi(rover). It is actually mounted on a quadcopter!! I should have been more clear!!! Anyways, there is a drop in the signal to noise ratio mostly due to the movement of the piksi. Robustness is something is needed to be worked on and I sure the swift-nav team is on it. !!!!

Cheers

-Rai Gohalwar 

[LamorindaMarketing]

Hi Niels

I've been keeping track of your submissions to the 3DRobotics/Pixhawk firmware people. After 8+ days of being "Proposed", your latest update seems to have disappeared from the Git page. So whats happening? Is there something we can do to help push the RTK "base station" thru?

Thanks

RoboBill

[Goh Guo Dong]

Hi Robobill,

The pull request is closed already as you can see from this link https://github.com/diydrones/ardupilot/pull/1263. It should be available in the newest firmware by now.

-Goh Guo Dong

[Goh Guo Dong]

Hi Robobill,

It is closed but not approved, so it's not included in the newest firmware, my mistake.

-Goh Guo Dong

[Niels Joubert]

Hi guys,

sadly the APM codebase does not support integer parameters - only floating point. This means that any position programmed into the base station only has an approximate accuracy of around 2 meters. Since this means your RTK fix now has a 2 meter error added to it, this is not a viable option. Andrew Tridgell, the lead dev on APM, closed the request for this reason.

This is unfortunately outside of anything I have jurisdiction over. I've reached out to Jonathan Challenger on the 3D Robotics side. I believe you've been talking to him as well, so can you follow up with him?

There's also an ongoing discussion on the Swift side about supporting pseudo-absolute positioning by programming the base station location directly into Piksi. Let me raise this with the next team meeting and we can perhaps fold this functionality into the Piksi side of things.

In the longer term, this is a problem that will go away. In the future, Piksi and its successors will have the ability to receive corrections from course acqusition stations all over the world, and it will know the base station location down to a few millimeters of accuracy. Once this is available, this problem of having to specify or compute a base station won't be necessary anymore.

[Niels Joubert]

Hi Rai!

Can we have a discussion about potentially bringing you deeper into the development environment over email? Please get in touch  at njou...@gmail.com

Cheers!

[goh dongliang]

Hi Niels,

Is there anything that I can help to speed up the process of getting the Piksi to work with Pixhawk?  I really need this to work as soon as possible in order to proceed with my project, so please feel free to ask me if you want to collect some data from me. I wish I could help you with the code but I am not an advanced coder. I have looked into the code for several days and I roughly understand  the structure of the code. I will try my best to help should you need my help. Anyway, is the problem regarding the dropping of messages across UART solved?

-Goh Guo Dong

[Andrew Tridgell]

Hi Niels,

There is some hope on this. The work to support integer parameters has progressed over the last couple of days. It isn't there yet, but is closer.
You could also add a MAVLink message, perhaps called SET_RTK_HOME which takes two int32_t values and passes them to the GPS driver. It could even then set the parameters, bypassing the float interface, thus working around the issue.
Cheers, Tridge

[Niels Joubert]

Hi everyone!

After discussing this with Swift, we're planning to integrate the capability to report pseudoabsolute positioning with a known base station right into Piksi itself. This will be added as a feature in the upcoming release.

Robobill, for the moment, have you been successful in getting baselines on that setup? I would suggest that for the time being you just rely on the driver to calculate the base station position for your testing.

Cheers!

-Niels

[LamorindaMarketing]

Hi Niels,

Thanks for the update and I'm happy to hear you all are putting in the baseline code. So far I have not been able to acquire RTK mode unless I do a init known baseline...but the Mission Planner still shows my rover jumping all over the place.... and with the latest Piksi beta firmware with the old Python console showing no communication between the piksi... sorry I'm really lost.

I'm hanging in there,

RoboBill

[Niels Joubert]

Hi Bill!

We've been clearing up a lot of these issues - I've been able to recreate the behavior you're seeing, and the latest Swift firmware has a couple of fixes that addresses this. I still have a bug in the driver I haven't been able to track down that makes this worse, but we'll get it! The project has evolved beyond Swift by now, and we're trying to pull 3D Robotics in.

Thanks for hanging in!

=Niels

-Niels

--
You received this message because you are subscribed to a topic in the Google Groups "swiftnav-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swiftnav-discuss/z34YTh-4Mvw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swiftnav-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[LamorindaMarketing]

Hi Niels,

I am very impressed that you recreated my mess... and if you need help bringing 3DRobotics in, I'd be happy to drive into Berkeley and push ;-)

RoboBill

[Niels Joubert]

Hello! Where are you based out of Bill?

-Niels

[LamorindaMarketing]

Hi Niels,

I finally took the time to update the firmware. It only took me 3 hours to relearn all this git/firmware stuff instead of 8. But after I successfully updated everything,  Using the SN console I can see the two Piksis cruising all around.... but still no RTK

Bill

[Blair Burtan]

So, I tried hooking up a PIksi with the v0.10 firmware to a Pixhawk and threw it into simulator mode.  After letting it cook for a bit on APM Planner, eventually the thing started circling the Gates Computer Science Building at Stamford.  Must be some kind of Easter egg. :-)

[LamorindaMarketing]

OK perhaps some progress

First I didn't know there was a new console. Sorry but all this version .10 or 1.0 is just way too confusing to me. Even though 0.8 console would not uninstall (I ran the uninstaller and nothing changed so I just erased the damn directory) I installed .10 console successfully

I did acquire sats pretty fast but couldn't lock into RTK. So I tried first tried inputting my location in the base station setting... no improvements. Then I put my rover next to the base and hit init with known baseline. That seemed to work and I was able to get some repeatability. 

My rover on the mission planner still jumped all over the place and the HUD was 3D GPS not RTK   even when I had RTK on the console and everything was steady.

Then I got this !!!!

.... something like "there is a disorder in the amb_test sats or "   blah blah blah   and it locked up   OH POUT!

RoboBill

[Goh Guo Dong]

Hi,

It has been a while!! I wonder if there is any exciting update for pixhawk users? i am still hanging in there!!!

[LamorindaMarketing]

Its all quiet as far as I can tell

Super heavy pout!

RoboBill