ArduRover on real competition R/C 1/10 car on real circuit: missions. FAR FROM WORKING

I changed to Rover version 3.4 beta:
PX4v2 004B0036 3436510A 32393637
PX4: b535f974 NuttX: 1472b16c
ArduRover V3.4.0-rc1 (615d7afc)
and tried a three laps mission:

It was generated copying and pasting: waypoints 1-33 and 34-66 are 67-99. 100 is a finishing point. References below are to points 67 to 99. This is the final version, after some position trimming on some waypoints. This permits to analyze lap to lap trajectory repeatability.

Overall performance was better. Here are two videos, with 2.2m/s speed:

(4K 50fps)

This are links to two of several logs obtained:

On first one, on one lap there are great deviations around points 82 to 86.
On second one the car hits a a circuit barrier between points 70 to 71 (rangefinders adjustment pending), which should appear on accelerometers.

Here are some captures from kmz files (POS messages):

The irregularities at the beginning are simply due to initial car positioning at the asphalt.

Although the overall result is good, this happened:
-As predicted above, and even being the speed so low (2.2m/s), turns widen. Passing barrier between points 70 to 71 was difficult, even trimming waypoints.
-Partial repeatability.
-Occasionally steering oscillates, specially approaching some waypoints.

I’ll try procedures suggested in:

Finally, I increased speed from 2.2m/s to 2.7m/s. It was impossible to complete the mission. Here is a video showing how the car stops at barrier between waypoints 70 to 71 after starting second lap:

(4K 50fps)

Here is a link to the log:
and this is the trajectory (POS):


Thanks for the log and video! It’s really great to see videos of these vehicles in action.

I think the wide turns are because the steering turn rate controller is not very well tuned. If we have a look at the Desired vs Actual Turn rate graph below there are clearly two problems:

  • the desired turn rate (shown in red) is not being attained (the actual shown in green is too low). This means the ATC_STR_RAT_FF is probably too low. It’s 0.2 (the default) but should probably be more like 0.5.
  • The next issue is the actual turn rate (in green) is very jagged. This is caused by having the ATC_STR_RAT_P value too high. It’s set to 1.0 but should probably stay down near the default of 0.2 or 0.3. It’s a bit of a golden rule that the ATC_STR_RAT_P should never be higher than the ATC_STR_RAT_FF.

Could you try these new parameter values and see how it does? Thanks!

Thanks for the suggestions.

I have tried this mission:

(6x4 waypoints, obtained copying and pasting)
with these parameters:

(BTW, are WP_OVERSHOOT and WP_RADIUS important?)

This was a first log:
that produced this trajectory:

The car was left on the asphalt, went to waypoint 1, continued mission, but turn at waypoint 8 widened and the car crashed. So for next test there I will shift right 1m the points at the left, although it seems that now turns are sharper.

Observing DesturnRate and TurnRate:

actual turn rate has improved but desired turn rate is not attained. So for next test I will increase ATC_STR_RAT_FF above 0.5.

This was another log:
Capturing from the kmz file:

The car did not follow at all the trajectory, went out of control and hit an obstacle, as had happened days ago (image with green vertical bars above). This happened twice.
DesturnRate has no sense:

See below: this could be caused by magnetic interference (big magnetic container nearby).

Above, on Mission Planner->Dataflash logs->button “Auto Analysis” appeared an error.
Now I tried Mission Planner on an administrative acount and got this:

but executing as administrator I got this:

So it seems that Mission Planner must be debugged checking permissions. In the meanwhile, execute Mission Planner as Administrator.

As appears above:
Test: Compass = FAIL - Large change in mag-field (157.21%)Max mag field length (611.18) > recommended (550.00)
and repeating the analysis on previous logs (big circuit):

Test: Compass = FAIL - Large change in mag-field (149.57%)Max mag field length (575.86) > recommended (550.00)

Test: Compass = FAIL - Large change in mag-field (178.86%)Max mag field length (699.61) > recommended (550.00)

Test: Compass = FAIL - Large change in mag-field (215.38%)Max mag field length (627.98) > recommended (550.00)

There is a big magnetic container under the trees at the right, so the car is going to pass beside it on each lap on this mission, and also on missions on the big circuit. There may be other big metallic objects nearby, which can be magnetized, such as the podium. Note that this is a real circuit, and cannot be changed.

For the rectangle mission here (almost two rectangle laps), here are MagX, MagY and MagZ:

-Is this important?
-Could this explain the crashes?
-Does the program do any filtering, such as detect a big magnetic disturbance and reject compass data (rely on GPS)?

I’ve created an issue for MP for the security issue (anybody can raise these issues by the way).

Regarding driving off, I agree that the compass/heading is likely the cause. It is probably a good idea to disable the internal compass (set COMPASS_USE2 = 0).

We can see from the logs that the vehicle knows it’s getting further and further from the track. I think we need to add a failsafe to change the vehicle into HOLD mode if we sense the vehicle is driving off.

MAG (red) is the external compass, placed at the front bumper, as far as possible from the motor.

MAG2 (green) is the internal compass (disabled).

1 Like

After some tuning, with these parameters:
CRUISE_SPEED 2.4 (still very low)
and having yet to try this:
Steering Turn Rate Control tuning video
I tried this mission:

(6x4 waypoints)
with sharp curves left and right.

This is the log:

This is fit between DesTurnRate and TurnRate:

I wonder if it is satisfactory enough.

This is the video

(4K 50fps)

and this is the result:

Seems satisfactory, but trying on the big circuit this was the result:

Although the car passed better the barrier between waypoints 70 and 71 mentioned above, the car deviated at other points and went off circuit or knocked slightly some barriers.

How can the fit to the GPS waypoints be improved?

BTW2, what is the importance of:

OK, so it looks like the vehicle is using Rover-3.4.0. Could you try Rover-3.4.1-rc1? This includes the lane based speed control and also fixes an issue with the steering output being limited. The lane based speed control really was built for this kind of situation so I hope it will help.

WP_OVERSHOOT is suppose to be used to reduce the speed of the car so that it stays on the line between waypoints. In 3.4.0 it is used to calculate how fast it can be going before reaching a waypoint so that it doesn’t overshoot too much. In 3.4.1 it is also used to slow the vehicle if it gets too far off the track. You can easily see how far the car is from the line between waypoints by graphing NTUN.XT.

WP_RADIUS controls when the navigation code thinks it has reached a waypoint. So if WP_RADIUS = 1, once the car is within 1m of the waypoint, it thinks it is complete and will start towards the next waypoint.

I programmed V3.4.1-rc1:
PX4v2 004B0036 3436510A 32393637
PX4: b535f974 NuttX: 1472b16c
ArduRover V3.4.1-rc1 (3ee064da)

(BTW, programming firmware in Mission Planner is a mess, even with “Force PX4 Bootloader”.
QGroundControl is immediate:
QGroundControl can upgrade the firmware on Pixhawk devices, SiK Radios and PX4 Flow Smart Cameras.
All QGroundControl connections to vehicles must be disconnected prior to firmware upgrade.
Please unplug your Pixhawk and/or Radio from USB.
Plug in your device via USB to start firmware upgrade.
Found device: PX4 FMU V2
Connected to bootloader:
Version: 4
Board ID: 9
Flash size: 2080768
Downloading firmware…
Download complete
Successfully decompressed parameter_xml
Successfully decompressed airframe_xml
Successfully decompressed image
Erasing previous program…
Erase complete
Programming new version…
Program complete
Verifying program…
Verify complete
Upgrade complete)

After some adjustments this was the last log:

Three eights:

Big circuit:

TurnRate vs DesTurnRate:


Trajectory follows waypoints better. At specific waypoints (80, 82, 84, 88) it departs, for whatever the reason.

I’ll try to increase speed and use DO_CHANGE_SPEED.


Just had a quick look at the logs and it’s looking pretty good!

It might be good to turn off object avoidance by setting RNGFND_TYPE = 0.

The 2nd GPS doesn’t appear to be working very well so I think disabling it would be good (set GPS_TYPE2 = 0). We can see it is not working well by clicking “show map” when viewing the dataflash log. the green line is very far off from the others.

To make the vehicle slow down more it might be interesting to try reducing TURN_MAX_G from 0.6 to a lower number like 0.4 or 0.3.

The performance in the Auto mission near the end of the logs looks pretty good. The desired turn rate and actual turn rate are quite close to each other.

It seems that the second GPS takes longer to have a low hdop. The erratic green line happened while I was trimming. However, when stabilized, first GPS has hdop around 0.7 and second GPS around 1.2. Both have M8N chip. It is true that examining both GPS logs, GPS 2 seems noisier.

However, I disabled GPS 2:
and this is what happened:

I have no idea about why this happened. I continued with two GPS’s.
Reason for this malfunction with a single GPS?

Here is a log of altitude as shown by both GPS’s:

The circuit is horizontal. GPS 1 shows altitude difference of 10m, and GPS 2 of 21m.

Status of both GPS’s:

According to:
Downloading and Analyzing Data Logs in Mission Planner (Rover)
Downloading and Analyzing Data Logs in Mission Planner (Copter)
Status 0 = no GPS, 1 = GPS but no fix, 2 = GPS with 2D fix, 3 = GPS with 3D fix
How is it that GPS 1 status reaches 4?

The long logs (including mentioned above trimming) are due to not knowing a convenient method to start and stop a log. According to above:
On Plane and Rover dataflash logs are created soon after start-up. On Copter they are created after you first arm the copter.
Unless I miss something, I think arming and disarming should start and stop a log also in rover. At present I keep turning on and off.
So, in rover, how can I start and stop a log?

The podium of this circuit is a big structure of concrete and steel beams. Approaching to it a conventional compass its needle orientation is modified when approaching it to a podium steel beam:

The compass must be close to the steel beam to deviate its needle. It is true that “Mag anomally” is heard in Mission Planner (and is heard in videos below) when the car approaches the podium, but also in intermediate circuit points.
How can I find this “Mag anomally” in the logs?

Certainly lowering TURN_MAX_G the car goes slower and can stop completely, as can be seen on videos below. I left it finally at 0.3 (lower values don’t seem to change much).

In following tests I tried to increase speed, changing CRUISE_SPEED and SERVO2_MAX (left finally at 1600, as a safety measure). The main problem is the lack of trajectory repeatability: laps are different, and with same parameters you may have good laps, car going offtrack, or a crash against a barrier.

Other problem is reaching waypoint 1 after starting (beside podium). In many cases the car deviates and hits the right or left barrier.
Reason for this?

For following tests I trimmed waypoints and tried this mission:

Waypoint 100 is to be used as a safe final parking place if close to a barrier. It has been placed far from waypoint 1/34/67 so as to start a second set of three laps pressing button Auto in Mission Planner after mission ends and goes to Hold mode.


3x2 laps. Difficult start, knocking right barrier approaching waypoint 1.
After t=670 (lap 5, waypoint 67):
-Heard: “Mag anomaly. Yaw aligned”.
-Steering oscillates (can be seen in the video at 4K).
-Car recovers and goes on.
These are STER DesTurnRate and TurnRate is detail:

Observe steering servo:

Reason for this oscillations?

For next three tests I tried CRUISE_SPEED=4.5, and six laps (repeating mission). First two failed and third succeeded.


At the end the car goes offtrack and backwards. This is NTUN.XT:


At the end the car goes offtrack and stops over an elevation. This is NTUN.XT:


Success, with even better fit to mission waypoints at 4.5m/s than at 3.2m/s above, but shows lack of trajectory repeatability.

In missions above trajectory fit to some waypoints is poor, particularily at 84. and at the videos it can be seen that the car goes offtrack after the long straight. Why poor fit in particular places?

Above it was mentioned unknown origin problems going from two gps’s to one. I wonder if magnetic problems would be improved with two external compasses. Common compasses are HMC5883 and HMC5983. A difference is that the second one has also SPI bus, so on the Pixhawk could be connected one to I2C as now, and a HMC5983 on the SPI bus. Module GY-282 supports choosing connection:
Will a HMC5983 on a GY-282 be recognized when connected to a Pixhawk through SPI?

A last thing about range finders, which I have began to consider. I have an analog one (1) on the left and an I2C (2) on the right. This is a log, which shows activity:

Complete Parameter List (Rover)
RNGFND_TURN_ANGL: …Positive means to turn right, negative means turn left.
This is for (1) so being at the left should have a positive value to turn right.
But RNGFND2_TURN_ANGL does not exist, so how is what to do in rover when rangefinder 2 approaches an obstacle indicated?

-Could I miss something when disabling second GPS?
-Why GPS status reaches 4 (undocumented)?
-How can I start and stop a log in rover without turning off?
-What about “Mag anomally” heard at times? How does it appear in logs?
-Reason for deviations at mission start, before waypoint 1?
-Reason for occasional steering oscillations?
-How can trajectory repeatability be improved?
-Why in certain points trajectory fit is poor?
-Will a HMC5983 be recognized on SPI? Will a second external compass do any good?
-Action when rangefinder 2 approaches an obstacle? (RNGFND2_TURN_ANGL does not exist)


Here’s some feedback from looking at the Rover_20180703_271.BIN log.

The speed control could be improved by setting the CRUISE_SPEED and CRUISE_THROTTLE a bit better. Could you try the method used in the video on this wiki page to capture these two values?

The steering contol looks pretty good.

It looks like the arming checks have been turned off. This is nearly always a bad idea. Could you try setting ARMING_CHECK = 1? You will probably see warnings when you try to arm, it’s best that we work through these warnings and resolve them instead of turning off the checks.

Now to answer some questions:

Could I miss something when disabling second GPS?

Normally more GPSs is better because we blend the results to get a value that is better than either single GPS. The track from the 2nd GPS is quite bad though, I’m unsure why - whatever is going wrong is within the GPS itself I think.

Why GPS status reaches 4 (undocumented)?

GPS Status of “4” means DGPS which is a very good lock. BTW, “5” is “RTK float” and “6” is “RTK fixed”. Each higher status is better. The documentation is a bit behind on the wiki but we will get to it eventually I think. The wiki is also all open so it’s actually possible for anyone to update it.

How can I start and stop a log in rover without turning off?

We don’t have a way to restart the logs I think but you can reboot the flight controller from the ground station. If using the Mission Planner it’s on the Flight Data screen’s Actions tab (bottom left). Set the top left drop-down to “Preflight Reboot Shutdown” and then push the “Do action” button.

What about “Mag anomally” heard at times? How does it appear in logs?

So this means that the compass reading does not match the other sensors (in particular gyro). It could be caused by the compass not being calibrated or it could be caused by external interference.

It is possible to view the magnetic field strength by opening the Log with the MP’s dataflash log viewer and then select “Sensors/Compass/Compass” from the drop-down in the middle below the graph area. the mag field strenght is normally shown in red and it’s formula is something like, sqrt(MAG.MagX^2+MAG.MagY^2+MAG.MagZ^2). This magnetic field strength should be stable if there’s no interference. There is always interference though but the more stable the better. If it changes by more than 30% then that’s a sign that there is too much interference.

How can trajectory repeatability be improved?

It’s hard to be sure but I think this might help:

  1. keep the object avoidance turned off. The “dodge” object avoidance is not helpful in this situation, i think it will just lead to less reliable laps.
  2. set ARMING_CHECK = 1
  3. use the compass inside the GPS/compass module which is mounted on a mast away from the vehicle and ground. Make sure there is nothing else metal near the GPS/compass unit (i.e no other equipment near the GPS/compass). Remove all other external compasses from the vehicle.
  4. re-do the compass calibration

Hope this helps…


Also could you try increasing EK2_YAW_M_NSE to 0.7 (or maybe even 0.8 or 0.9)? This parameter is mentioned at the bottom of this EKF wiki page but in short it reduces the EKF’s trust of the compass and instead makes it rely more on the gyros and GPS.

I’ll test all this shortly.

In the meanwhile observe this video:

CellSensor was at normal sensitivity. Compass should be at least 20cm away from motor; this happens if placed at the front bumper.

The ESC has no influence.

BTW, I assume that a compass at the SPI Pixhawk connector will not be recognized in actual version.

1 Like


That’s a great video demonstration of compass interference! It’s perhaps a bit hard to know what the level of interference is occuring in percentage terms but it does make it super clear that a motor causes interference even at quite long distances. Really great.

Here appear both the CellSensor and a conventional compass, and the rotor is manually moved.

I suppose that the program will filter the variable magnetic field caused by the rotor (may be 10 to 1000 Hz), but for calibration the compass should be far away from the rotor.

While rotating the car while calibrating the compass, the rotor moves with the compass. I wonder if calibrating succeeds if moving the rotor, such as with battery and transmitter and bypassing the controller (such as with a servo tester), since if arming compass calibration is not possible.

1 Like

nice video. I’m sure there’s almost no way we can filter out a lot of interference… we sample the compass at about 100hz so a motor moving faster than that will lead to all kinds of aliasing and basically I don’t think we can filter it out.

On these cars 5m/s should be moreless 25 Hz on wheels and 125 Hz on motor axle (now I try at CRUISE_SPEED 4.5). Competition speeds would be five times that on the straight.

I tried to change EK2_YAW_M_NSE, but did not reach a conclusion.

All following is with V3.4.1:
u-blox 2 HW: 00080000 SW: EXT CORE 3.01 (107900)
u-blox 1 HW: 00080000 SW: EXT CORE 3.01 (107900)
GPS: u-blox 2 saving config
GPS: u-blox 1 saving config
EKF2 IMU1 tilt alignment complete
EKF2 IMU0 tilt alignment complete
EKF2 IMU1 initial yaw alignment complete
EKF2 IMU0 initial yaw alignment complete
GPS 2: detected as u-blox at 115200 baud
GPS 1: detected as u-blox at 115200 baud
RCInput: decoding PX4IO_PPM
Ready to drive
Initialising APM
Beginning INS calibration. Do not move vehicle
<startup_ground> Ground start
Barometer calibration complete
Calibrating barometer
PX4v2 00320046 35365118 37353630
PX4: b535f974 NuttX: 1472b16c
ArduRover V3.4.1 (8e958687)

I noticed that common compasses HMC5883 and QMC5883 have different I2C addresses (0x1E and 0x0D), so I installed both as external compasses, as always on the front bumper, away from motor:

The two screws near the compasses are titanium ones (paramagnetic). I placed a sheet of mumetal behind the compasses, but I’m not sure if it does any good (it covers the front differential, which has steel parts).

They calibrated succesfully:
(internal Pixhawk compass disabled)

I also changed the motor with one with weaker magnets, but didn’t notice any difference.

Here are three logs:

These are the trayectories:

Although they seem neat, the reality is that the first meters are as before difficult: the car hits the barriers at left or right, or is blocked, as in previous videos such as:

Clearly the car goes left and hits the left barrier at start.

It could happen as if the program relies on the GPS for orientation, but the car being still initially cannot have GPS orientation (it should initially fully trust the compass).

Question: can the car start trusting fully the compass orientation?

As an experimental experiment on the second two logs I tried to only use Galileo satellites (Galileo is said to be more precise):

However the number of satellites detected didn’t change (in Rover_2018-07-27_19-08-11.bin GPS.NSats goes from 17 to 23 and GPS2.NSats goes from 12 to 14).

Question: how can I try Galileo only satellites?

There are still few, but more are being deployed, four last monday july 23:
Ariane 5 rocket, Galileo satellites on launch pad in French Guiana

1 Like


I had a quick look at the logs. The steering and speed control is pretty good so it’s not a tuning issue.

Re the vehicle hitting the sides at the beginning. So the issue is probably that the compass heading is off a bit but the EKF learns the correct heading once the vehicle starts moving. I think if the car was driven manually forwards and backwards on the straightaway before starting the mission it would be OK. A better solution is probably to modify the EKF to get it to try and learn the heading faster at the beginning.

The position from GPS2 is really very bad. It should just be disabled or simply removed because it is not doing any good.

The 2nd compass appears to be pointing in the wrong direction. I think it’s upside down.

There are some large spikes in the primary compass’s Z axis probably caused by driving over something metal in the track. It might be interesting to determine where these happen on the track and see if that is related to the vehicle going off course. Maybe the compass can be moved higher?

To help you properly I probably need to get a fast Rover of my own and try racing it on a race track here in Japan…

1 Like

Thanks for your patience and for discovering how interesting and informative are the logs.

…I think if the car was driven manually forwards and backwards on the straightaway before starting the mission it would be OK…

I had tried that learning possibility before, but in Manual, without any conclusion. I’ll try shortly in Acro and Steering. Anyhow, it is a workaround.

…The position from GPS2 is really very bad…

Well, the car does not go between the trees. I agree that there is something strange with this GPS, so I had changed it, but did not reach a conclusion. I’ll substitute it again and see what happens.

Anyhow, in the logs lat/long/alt don’t differ too much between the two GPS’s.

When I tried one only GPS things didn’t work at all, for whatever the reason.

…The 2nd compass appears to be pointing in the wrong direction. I think it’s upside down…

I have never been sure about the definition of the compass positioning. Above I started with one compass at Roll180, which seems what is documented elsewhere.

Here is the detail of the actual positioning (HMC5883, QMC5833, Roll180Yaw90) of both external compasses:

Chip orientation dot is indicated in red. The two near screws are titanium screws. Note that previous orientation above for a single compass was Roll180; rotating it 90º leaves cables more protected.

But note that chip orientation is the same and axes notation in the PCB’s is the same. Although the manufacturers are different, it would be annoying if their rules would be different.

An overall reasoning for compass orientation is deduced from the following figure, obtained from chip’s documentation (compare positioning dots and axes):

A) Internal Pixhawk compass (not used). It is upside down (shown red). It is clear that its orientation is None.
B) First external compass here (Roll180). It is clear that this positioning is obtained rotaing A) 180º, but Roll is not so clear.
C) and D) Actual external compasses, rotating B) 90º.

What is really strange is that both compasses, oriented and defined the same, show different behaviour. Although similar in name they are different in software. Can somewhere be a bug?

I made at home three logs (v3.4.2), rotating the car uniformly (by hand) over a rotating platform, so yaw is linear and mag is sinusoidal (moreless).

Car is rotated 10 times cw.

This the same as you observed. Why is it that the green line for mag_heading_df(MAG2,ATT) has a negative first derivative?

Car is rotated 12 times ccw.

(Spike on compass 1)

Car is rotated 15 times cw with motor on (not much difference).

There are some large spikes in the primary compass’s Z axis…

They repeat on above logs on first compass:

10t cw:

12t ccw:

15t cw (motor on):

I’ll change compass 1 (same chip).

To help you properly I probably need to get a fast Rover of my own and try racing it on a race track here in Japan…

Some on road tracks in Japan:
31°47’26"N 130°44’10"E
31°49’04"N 130°16’41"E
32°43’10"N 130°18’21"E
32°46’04"N 129°48’01"E
33°01’26"N 130°40’02"E
33°01’39"N 131°16’25"E
33°12’17"N 130°18’52"E
33°14’22"N 130°17’17"E
33°17’22"N 130°31’57.50"E
33°19’02"N 130°25’37"E
33°21’46"N 130°24’46"E
33°36’45.50"N 133°34’00.50"E
33°39’41"N 130°49’47"E
33°39’42.50"N 135°54’22"E
34°02’08.50"N 131°55’29.50"E
34°12’22"N 135°23’21"E
34°13’10"N 134°02’48"E
34°17’24"N 135°21’25"E
34°31’36"N 135°39’14"E
34°35’43"N 135°35’57"E
34°37’03.50"N 132°57’25"E
34°37’28"N 136°32’24"E
34°40’17"N 133°57’44"E
34°42’47"N 135°34’59"E
34°45’35"N 135°49’12"E
34°47’11"N 138°02’28"E
34°50’05"N 137°20’27"E
34°50’18"N 136°53’01"E
34°52’47"N 136°59’32.50"E
34°53’06"N 137°26’48"E
34°53’52"N 134°34’43"E
34°58’48"N 138°25’18"E
34°59’33"N 135°37’23"E
35°06’13"N 136°41’18"E
35°08’56"N 136°51’20.50"E
35°09’12"N 135°07’47"E
35°10’06"N 136°30’36"E
35°15’17"N 137°05’59"E
35°17’54"N 136°56’37.50"E
35°19’17"N 136°43’59"E
35°22’28"N 138°34’26"E
35°23’39"N 136°49’08"E
35°24’56"N 136°40’16"E
35°25’23"N 139°21’23"E
35°25’50"N 140°08’04"E
35°29’40"N 140°05’45"E
35°32’10"N 139°19’18"E
35°36’10"N 139°12’45"E
35°36’21"N 138°36’18"E
35°42’10"N 139°34’48"E
35°42’29"N 140°22’48"E
35°44’31"N 139°48’34"E
35°49’10"N 140°24’39"E
35°55’10"N 139°33’21"E
35°59’19"N 136°05’56"E
36°00’45"N 140°05’08"E
36°00’52"N 139°36’38"E
36°09’10"N 139°25’06.50"E
36°10’09"N 139°10’19"E
36°16’04"N 139°55’36"E
36°16’10"N 136°42’32"E
36°21’09"N 139°00’14.50"E
36°21’15.50"N 139°02’08"E
36°21’37"N 139°07’37"E
36°23’24.50"N 140°32’01"E
36°24’38"N 139°03’54.50"E
36°27’30"N 140°22’16"E
36°30’55"N 139°49’09"E
36°40’07"N 139°45’13"E
36°41’37"N 139°06’24"E
36°56’40"N 139°57’18"E
37°26’55"N 138°48’38"E
37°51’11"N 138°53’53"E
38°12’44"N 140°48’46"E
42°55’19"N 143°09’27"E
42°57’02.50"N 143°13’13"E