bad robot topo shots

Paul-
What DC package are/were you running here and there?

We have a Topcon total station (not a robot) and a Ranger Data collectror running TDS survey pro that did that once. Same thing, a bunch of points all stacked on top of the insturment points but at different elevations. It only happened that one time.

Hmmmm... maybe half (angle half) of the robot was on smoke break, and the other half (EDM) didn't smoke :whistle:

pmoran, post: 369859, member: 8922 wrote: Paul-
What DC package are/were you running here and there?

Running TDS Survey Pro here. I believe it was Survey Pro there as well. Both Topcon robots. Could be something there. Maybe a communication issue? But why only sometimes?

David Livingstone, post: 369860, member: 431 wrote: We have a Topcon total station (not a robot) and a Ranger Data collectror running TDS survey pro that did that once. Same thing, a bunch of points all stacked on top of the insturment points but at different elevations. It only happened that one time.

Thanks for the info. Tells me that it must not be a robot issue (that was one of the previous theories). Something to do with locking onto bright car windows and the like. Sounded fishy then too, but we bought it.

They were in angle offset mode and they didn't take the angle right, first. My guess.

Paul, post: 369866, member: 624 wrote: Running TDS Survey Pro here. I believe it was Survey Pro there as well. Both Topcon robots. Could be something there. Maybe a communication issue? But why only sometimes?

Yeah beats me- I don't have a lot of experience with TDS- just not much of it running our instruments in the Northeast. It seems strange though- like a scratch on an LP just kind of stuck there. The shots look strange though- not like real measurements- repeating all balls in H and V would be kind of irregular even with a half second gun- the encoder would still record some fluctuation, but you see none in the H or V and huge changes in the distance. Then the only thing that changes in coords is the Z and it is a lot.

Probably locked onto a "windshield" prism. I'm not certain of the appropriate prism constant for that one either..... But sounds like the field crew needs to look down at the DC screen once in a while!

Timberwolf, post: 369868, member: 10599 wrote: They were in angle offset mode and they didn't take the angle right, first. My guess.

Doesn't seem to be that (at least from the raw data). Here is a little more of the file to show before and after the points in question:

SS,OP8,FP1155,AR199.561400,ZE92.202000,SD47.866575,--TOE2
--Target Generic Prism: "-30", HR:11.400 (11.400 + 0.000 Offset), Prism Const.:-30.0mm
LS,HI4.880,HR11.400
SS,OP8,FP1156,AR200.195700,ZE86.440900,SD70.661575,--TOE2
--Target Generic Prism: "-30", HR:5.300 (5.300 + 0.000 Offset), Prism Const.:-30.0mm
LS,HI4.880,HR5.300
SS,OP8,FP1157,AR253.003600,ZE101.571500,SD72.246575,--NDTOP3 B
SS,OP8,FP1158,AR245.021200,ZE101.104800,SD62.871575,--NDTOP3
SS,OP8,FP1159,AR242.132200,ZE101.280600,SD50.276575,--NDTOP3
SS,OP8,FP1160,AR0.000000,ZE0.000000,SD40.056575,--NDTOP3
SS,OP8,FP1161,AR0.000000,ZE0.000000,SD30.111575,--NDTOP3
SS,OP8,FP1162,AR0.000000,ZE0.000000,SD31.641575,--NDTOP3
SS,OP8,FP1163,AR0.000000,ZE0.000000,SD36.981575,--NDTOP3
SS,OP8,FP1164,AR0.000000,ZE0.000000,SD42.881575,--NDTOP3
SS,OP8,FP1165,AR0.000000,ZE0.000000,SD49.226575,--NDTOP3
SS,OP8,FP1166,AR0.000000,ZE0.000000,SD57.536575,--NDTOP3
SS,OP8,FP1167,AR239.025900,ZE100.262700,SD66.376575,--NDTOP3
SS,OP8,FP1168,AR245.590700,ZE101.185500,SD76.091575,--NDTOP3
SS,OP8,FP1169,AR247.001800,ZE101.485500,SD73.926575,--NDTOE3 B
SS,OP8,FP1170,AR240.015600,ZE102.030000,SD63.461575,--NDTOE3 B
SS,OP8,FP1171,AR232.450000,ZE102.215900,SD53.291575,--NDTOE3
--Target Generic Prism: "-30", HR:7.000 (7.000 + 0.000 Offset), Prism Const.:-30.0mm
LS,HI4.880,HR7.000

Paul, post: 369856, member: 624 wrote: In the past, I've seen where a field crew will come back with data stacked up on whatever control point they were setup on. I always assumed/was told that it was a problem with the particular instrument/software we were using at the time. Haven't seen it at this new organization. Now, all of a sudden, I just saw it on a project that my crew did the day before yesterday (with a newer Topcon robot - bought new in 2014). It wasn't all of the shots, but about a dozen points (randomly throughout the job) were all stacked up onto the occupy point. Here is what the raw data looks like for the bad shots:

SS,OP8,FP1160,AR0.000000,ZE0.000000,SD40.056575,--NDTOP3
SS,OP8,FP1161,AR0.000000,ZE0.000000,SD30.111575,--NDTOP3
SS,OP8,FP1162,AR0.000000,ZE0.000000,SD31.641575,--NDTOP3
SS,OP8,FP1163,AR0.000000,ZE0.000000,SD36.981575,--NDTOP3
SS,OP8,FP1164,AR0.000000,ZE0.000000,SD42.881575,--NDTOP3
SS,OP8,FP1165,AR0.000000,ZE0.000000,SD49.226575,--NDTOP3
SS,OP8,FP1166,AR0.000000,ZE0.000000,SD57.536575,--NDTOP3

Here are the coordinates:

1160,9824.636,12214.263,1070.148,NDTOP3
1161,9824.636,12214.263,1060.203,NDTOP3
1162,9824.636,12214.263,1061.733,NDTOP3
1163,9824.636,12214.263,1067.073,NDTOP3
1164,9824.636,12214.263,1072.973,NDTOP3
1165,9824.636,12214.263,1079.318,NDTOP3
1166,9824.636,12214.263,1087.628,NDTOP3

It seems to measure the slope distance just fine, but not the angle right or zenith angle, which in essence makes the points calculate as straight up into the air.

Anyone see this before and have a good explanation of how/why and how to stop it? We just always tried to be vigilant in the past, but there wasn't any real way to know other than keeping an eye on the zenith angle on the data collector for each and every shot, and we never figured out how to eliminate it (as far as I remember).

Thanks,

Paul

I think this happened a good while back to me and it was locked onto a window. I would say this is the case here.

Totalsurv, post: 369874, member: 8202 wrote: I think this happened a good while back to me and it was locked onto a window. I would say this is the case here.

That is what we always thought too. However, David just gave information that he had it happen on a non-robotic total station. I'm curious to figure it out, now.

The trouble is that this has so far been impossible to replicate in the office, so we don't know what the instrument was reading (if it showed the same zeroes as the data collector).

Happened to me one time. Survey pro. I also think the beam must have been locked onto something else and the reading it was getting was false causing it to record some 0 distance.

Paul, post: 369877, member: 624 wrote: That is what we always thought too. However, David just gave information that he had it happen on a non-robotic total station. I'm curious to figure it out, now.

When it happened non-robotically, was the data collector hooked up with a cable or wireless? I'm thinking there was interference with the packets of info being transmitted from the gun.

wild guess ... internal Instrument error, not able to read hor & vert circle ... the dc software does not catch/handle this situation and stores zero values for the circle readings and the measured slope distance. Somewhere a missing ON-ERROR routine?

I have used a Topcon Robotic Total Station for years now and have noticed the it will easily lock onto any Reflective surface (street sign, mirror, reflectors on trailers..ext) without the operator noticing it. Also there is a slight delay from when the Robot looses lock and when the Data collector notify you. It this time period the Robot will continue on the path the Rodman was walking and store the last distance it had taken.

Based on the realistic looking slope distances, it looks like the gun tracked the glass and sent that data just fine. Given both circles show zero, and it's unlikely both circle readings would be faulty, maybe it's in the tilt correction process , which would affect both circle readings???

Leica 1200 TPS did a similar thing about 10 years ago (the points were stacked on some odd reflective surface). I asked Shannon Hixxon if they could add a routine that would inverse between current and last shot and warn the user if the distance was less than some small distance (I think it was 0.01'). They did and it was in the next release! I've seen it catch the problem again after that. An easy solution to a more complex problem.

While this isn't the problem you saw, the solution would work in that case too. I think it would be prudent for all collection software developers to implement this feature. Easy to implement and could eliminate a bunch o' rework.

Did it happen at the end of a setup. That's what it looks like when our Sokkia goes out of level past compensation and you take a shot.