I have about the same setup as you,except my robot is a 2003 or 2004 1203.
?ÿ
One question is did you try to stake out your backsight point as a stakeout point after you took your backsight?
is it possible that you have a control file that is different from your job file?
I would not think that it is a robot issue, it is just a data terminal passing its readings to the data collector, somehow the collector maybe getting feet and metters crossed up.
?ÿ
Ed
I would surmise that your data collector to robotic TCP is thinking it uses a different mode, scale factor or other hardware specific alternate. Degrees vs other , metric vs feet. It appears you set up manually and checked a second point and know they are in your system, now go back and stake out that second point in robotic mode and write down exactly what it tells you to do, versus what you know it should tell you to do. Purposely resatke out to points exactly 1' left, right, near and far and also compare. Once you have done that for several other points it will lead you to a conclusion. Without actual precise readings we are at a total loss here.
ekillo has a point.?ÿ It is possible to setup in one file, stake out a second file and record those shots in a third file. I did that once unintendedly and it drove me crazy for a while. So once in robotic mode make sure your instrument and backsight are on the points in question from the file in question. That check you can actually do now in the office, get out your data collector, set it to manual mode and write down your stakeout directions and distance, then switch it to robotic mode and do it again.
Paul in PA
Is it possible that the setup / orientation was done in Face II? I know some software used to have problems under those circumstances. Otherwise I would be interested in seeing the SurvCE raw file if you could record those observations.
Make sure your scope was not inverted. I have same robot and use surv ce. Take a look at your raw data, are zenith angles way off? I have accidentally done this a few times and got bogus results.
Sounds like you were set-up on the point you told the data collector you were backsighting and backsighting the point you told the data collector you were set-up on? I've have that happen before. It usually looks just like you describe.
KevinFoshee's answer above is probably on the money. Me likey-likey.
Although, something you said grabbed my attention:
"They tracked down the problem to something called the ATR Camera which had become faulty somehow. Is this the component that causes the robot to follow the prism while it moves around?"
Yes it is.
"But, wouldn't that only affect the robot's ability to lock onto a target?"
Perhaps not.
"How would that hardware part also affect distances and angles?"
Good question. It shouldn't. Unless it being faulty has had a flow-on effect further down the road.
After stripping a destroyed instrument for fun recently (a non-plus model), I can tell you that the connections between the hardware components are as follows:
The mainboard sends all of the info through the head into the EDM board. The EDM board then runs the ATR board, which in turn runs the camera as well as the Powersearch board. Essentially, they are all physically connected in sequence. Electrically, I didn't bother checking to see if the ATR and Powersearch boards are only passively running through the EDM board or whether the EDM board does some of the thinking for the other two boards and the camera.
Having said that, all of the info for all of those "thinking" components runs through a ribbon cable containing only 8 separate wires. They are all sharing physical resources and sending differently coded signals in machine code back to the mainboard; which the mainboard then interprets. That interpretation could be your problem.
In other words, the ATR camera (or anything else upstairs) being faulty could absolutely cause that problem, because the faulty component could corrupt the message somehow (unlikely though. Things usually either work or they don't when code is involved.) The thing I would be focussing on is why this problem only presents itself when the RCS is turned on. That's odd. It sounds like a firmware issue. That would point the finger back at the mainboard. Nothing upstairs should care if the RCS is on or not.
If you look at the photo I attached (it's from an 1100, but you'll see what I mean) you'll see the 8 strand ribbon cable that I'm talking about. Essentially, I wonder what would happen if you disrupt the chain of info somehow.....like with a faulty camera.?ÿ That's why the ATR camera theory makes some sense- except that it is the ATR camera that locks onto the prism and tracks it- not the Powersearch module. PS only finds the prism roughly then hands over the duties to the ATR. And you said that you are getting a lock, so.......
Do the ATR and Powersearch behave themselves when the instrument is not in RCS mode? You mention it being ok in "manual mode". Does "manual mode" mean fully manual? Do you use the ATR and Powersearch in non-RCS mode or are you turning and sighting targets without the ATR at all?
Again, I am NOT a technician.
Mick
?ÿ
I had to get a CCP which cost me $450 to update the firmware on my 1203 to the latest version. My instrument used to take several seconds to turn off, after the update it turns off much faster, the other advantage to updating is it will allow you to use a RH16 handle that is bluetooth, so you could update the collector later if you decided to go that route.
Ed
Vertical check would be the same if you were set up on the supposed backside. At least the variance would be the same.
I make a habit of checking into a 3rd control point, that is one other than the backsight, before proceeding with staking. I wrote about this in a thread about resectioning just a couple weeks ago.?ÿ
As I said then, "the ways of the blunder are many, and varied". I've been doing this stuff for over 30 years now, and I still find new ways to screw up. Keep in mind that in order for you to match up to previously staked points, that previous staking had to have been right as well.?ÿ ?ÿ
https://surveyorconnect.com/community/surveying-geomatics/quick-resection-question/#post-519137
Vertical check would be the same
Only if the measure ups were the same...
Being a 1200 series have you tried using the on-board software to test? This could be an independent check to eliminate the data controller being the issue. I thought maybe the metric vs imperial settings in C3D being the cause, but if the control is in the same file then that eliminates that being the cause.
?ÿ
Also, as dumb as this sounds, I've had an issue in the past with Trimble Access loosing custom prism constant values when switching prisms, on one occasion I couldn't figure out why my readings were over 300mm out until I realised I forgot to enter a decimal point. That was definately a face in hand moment ?ÿ 😆 ?ÿ?ÿ
I think that is because the machine is old , I got the same problem with trimble and topcon
its laser not work good
?ÿ
