Okay thanks for the explanation! So for the cm accuracy, we still need the base stationary work.
Since I did get an error message while I was doing the base configuration yesterday on our base station after the 1.30 firmware upgrade, is there a way for auto configuration the base station with ardupilot too?
Ps. My rover did drive good today, if this base station connections does work, we can start with tuning!
You can actually connect the fixed base to a USB port and send RTCM3 via MAVLink with Mission Planner. If that sounds preferable, I can provide more detail.
I do not think that Mission Planner will save its auto configuration of the GPS to non-volatile memory, though, and you wouldnāt want that anyway, since it will probably impact the UART2 settings for the radio.
I also donāt know if the firmware mismatch in ArduSimpleās config files is a problem. I suspect itās not. I can try to test that sometime, but it may not be today.
Okay I have seen more people doing that with the mission planner. But we want to get the accuracy also without the need of using a pc all the time.
The rover looks very very accurate on the map which our setup, I donāt see it moving from left to right when Iām standing still, so maybe it already is using the base station correctly, but I donāt like the fact that Im not sure and I donāt know how to see if it is working properly.
Tomorrow I will speedways the boards for sure. If you have an idea how we can prove the base station is working correct, I would appreciate it
If you separate the boards and connect both to the autopilot, you can monitor the fix type of both. If GPS1 (type 17) shows RTK-anything, your base station is doing what it should.
To be sure the base station setup works, I have disconnected the Lite board temporary.
At GPS_TYPE2 we have our big board connected to type 18. In U-center I have uploaded the standard Rover configuration file to this board.
Even after 10 minutes, Iām not getting to RTK status. The best we get is 3D FIXā¦
This is our ardusimples led status:
First is rover
My idea was to connect the lite board seperated to GPS_TYPE(1) = 17. This one is connected to the GPS in the back of our rover, the big board is connected to the antenna in the front of our rover.
The test drive of today (base station not turned on)
About the tuning of steering (I now the throttle can be improved too, but we have an extra controller that makes a differential drive for both rear wheel motors, I have some extra functions in this code. For example drive slower when steering more, this will screw the throttle tuning up).
The mechanical steering of this rover takes like for ever, I have changed the setup of the actuator, but still slower than standard rovers.
Currently it steers nice and stable, but in my opinion I can see two parts of the steering tuning that can make it drive much better, but I can use some help with this:
but after a turn it just takes too long for it to get back to the yellow line. I think the rover doesnāt steer enough at that moment. (PID: I?)
after the rover has reached the yellow line again, we do have a litte overshoot causes it to drive on the other side of the yellow line for a short time. (PID: P?)
Iām almost certain the baud rate is not set correctly for the XBee during auto configuration. Even with GPS_DRV_OPTION bit 3 set, I think the uBlox UART2 is still configured at 460800 baud. You may have to reconfigure the radios to communicate at the higher baud rate.
Hi@Koenstruction ļ¼thank you for your practice.I also encountered the same problem as you, after I integrated the new code into 4.2.0 beta1, there was an error during compilation. Could you please help me find out what the problem is? Thank you.
I can share my code with you via Github, The code is made in collaboration with an engineer of SwiftNavigation.
You can download it and compare the full directory with your code to find the differences.
Today I have tried alle GPS_DRV_OPTIONS: 0, 1, 3 and 5 without success.
I do have the XBEE <> USB adapter. To what baud rate do I need to change the radios, 115200?
Do you know how I can change it?
Okay, at the moment I have tried to do exactly what ardusimple says: firmware of both rover and base boards back to 1.13 in stead of 1.30, and load base configuration and 10Hz rover configuration.
If you are not sure if the process finished, connect to the base and confirm that the fix type = TIME.
Once this is finished, the unit will start sending corrections so that the rover can start calculating its relative position within centimeters.
You will also notice that the LED āGPS>XBEEā will increase its activity.
I do get the TIME status on our Base module after powering on for like Ā± 12 minutes.
I have switched cables and the rover is connected to my pc nowā¦ letās see if this one gets an fix status in the next 15 minutesā¦ EDIT: 20 minutes have passed, still u-center: Fix Mode: 3D
XBEE>GPS LED on rover board is flashing twice a second. When I disconnect the radio of the base board, I can see the XBEE>GPS LED on the rover board keeps of completely. After connecting the radio back to the base board, the LED on rover board is flashing twice a second again immediatelyā¦
Below is a screenshot of the rover board UBX-RXM-RTCM messages, unfortenately no messages to be seen, I think we have found why we donāt get the RTK status. But I have no idea how to solve this.
I was in doubt, because the ardupilot does not need to receive the radio signals at all? Isnāt it the ardusimple rover board that should eventually pass an RTK FIX to the ardupilot board? If this is the case, then there seemed to be something wrong with my ardusimple boardsā¦ Iām trying to figure this out now.
I have found the solution!
The ardusimple configuration file was the problemā¦ I have changed both rover big and lite boards to the 10Hz Rover (in stead of moving base heading configuration files) configuration file and after 10 minutes I got both GPSā to rtk Fixes !
If youāve loaded the rover config on both boards, are you still getting yaw? That seems odd.
Also, there are known issues with the 1.13 firmware and ArduPilot, and 10Hz has been confirmed to cause less precise yaw output, as the rate is too fast for all data to be processed by the autopilot.
Iām not sure I have time today to explore it all, but I do want to do some more work on these boards and their configuration. I may be able to generate a 1.30 compatible set of files, but it will take some time to work through it in u-Center.
If you still have the boards physically separated and you want to try using the native auto configuration (GPS_AUTO_CONFIG=1 with GPS_DRV_OPTIONS=0), it looks like this software from the XBee manufacturer will allow you to set 460800 as the baud rate on the radios.
This line in AP_GPS.cpp seems to confirm that 460800 is used for the GPS UARTs when GPS_DRV_OPTIONS=0 (which is what you want with the boards separated). I think @ktrussell confirmed this in the field, as well.
You are right, the gps yaw didnāt work, I can see it on my screenshot. I did bring everything home this weekend and only focused on getting RTK, so I have missed the fact that yaw didnāt work anymore. So Do you think we can make a configuration file for the ardusimple firmware 1.30 version with 5Hz and both gps yaw and RTK radio communication? (2 configurations for rover and and moving baseline).
Itās absolutely possible. But Iām not going to get to it today. Will require a little bit of a dive into u-Center. Iām comfortable with the interface, but it takes time to validate the results.
Ok, then we can try this, which might avoid a big trip into all the u-Center craziness:
Connect both GPSs (little board to the first SERIAL port in order, big board to the second) and power the autopilot on. Set the following in addition to the moving baseline instructions in the wiki:
GPS_RATE_MS=200
GPS_RATE_MS2=200
GPS_DRV_OPTIONS=0
GPS_SAVE_CFG=1
GPS_AUTO_CONFIG=1
Wait for the saving config messages to appear (or reboot and wait for those messages, just to be sure), then set:
GPS_AUTO_CONFIG=0
GPS_SAVE_CFG=0
Now power off the autopilot and disconnect the moving base (little board) from the autopilot.
Connect that board to u-Center (230400 baud)
Open configuration view.
Navigate to UBX ā CFG ā PRT and change UART2 to 115200.
Click the Send button.
Navigate to UBX ā CFG ā CFG and select 0-BBR and 1-FLASH.
Click the Send button.
Power off, reconnect to the autopilot, and see how that works.
Leave the radio disconnected just to be sure you get clean configs. Doesnāt matter which config is already loaded, we are overwriting them on purpose by doing things this way. Itās effectively how @ktrussell used to configure his moving baseline for a while before he discovered that his radio supported the faster baud rate.
If this fails, I will see if I can dig in tomorrow and provide some config files for you.