2d Mapping Timing Errors

[DomoArigato]

I'm having some difficulties with timing error.  I was hoping someone with more experience might be able to shed some light on the issue.  I read the IR tutorial, and it looks to me like I have the exact shift in my 2d mapping that the article describes.  I can eliminate it only by making the servo go ridiculously slow like nearly a second or two for a complete scan.  The servo is going in 61 degree sweeps, and it is supposed to move 60 degrees in .1 seconds.  It looks like it can move that quickly with no problem.  Does anyone know what else could be causing this problem?  Or some suggestions for debugging it?  My code works like this:

When a the timer interrupt is generated, start an ADV conversion.  at the ADC interrupt, store the value and set servo moving to the next location.  I do this for every degree int he 61 degree sweep.

[Admin]

Two suggestions . . .

reduce sweep angle
(I do this by adding additional IR sensors to take readings at the same time)

OR

In your code, shift the map by the amount of timing error you get. For example, if a clockwise scan is off by one reading because of timing, in your array shift everything by one byte. Then just trim the array at the far ends.

[DomoArigato]

Do you know roughly what kind of delay you had on your servo doing 2d mapping?  Whats a normal delay look like?  Would around 5ms be enough of a delay to read the ADC and let the IR Rangefinder refresh?

[Admin]

Hmmm I dont remember the time . . . but I do remember my shift being about 15 degrees off.

Just do your scanner without delay compensation and output the data to your computer. Then you can decide if compensating is worth the trouble . . .

[DomoArigato]

So I found the solution to the shifting problem I was having.  The problem was that under no load, the servo would overshoot the desired angle by 10 degrees.  So I was able to get the timing down to 2ms delay for the servo and 5ms delay for the IR Rangefinder and ADC to do their work.  Basically when the servo was moving from left to right it would scan from 10 degrees to 70 degrees, and from right to left it would scan from 50 degrees to -10 degrees.  So I went through my array like normal, storing values in locations 0 to 60, but when I moved from left to right I actually positioned the servo at the degree I was storing the value into -10, and I did +10 when the servo was moving from right to left.  The faster the servo was moving, the futher it would overshoot the desired angle.
Attached is a picture of the output the red line represents the data points moving left to right without compensation.  The green represents the scan moving from right to left without compensation.  The two lines in the middle are the lines with compensation.  The rangefinder was scanning a wall at an angle.

[Admin]

The problem was that under no load, the servo would overshoot the desired angle by 10 degrees.

Ive never seen that before . . . which servo were you using?

Also, can I use your graph for my sharp IR sensor tutorial? (with credit, of course)

[DomoArigato]

I was using the hitec HS-81, I tried two different servos of the same type.  Your more than welcome to use the image.  Here is a link to the page I read that talks about the servo.  I'm not positive if the load really had anything to do with it, but it certainly overshoots by a greater degree when the delay is smaller.  http://list.dprg.org/archive/2000-February/012733.html

Note: I just realized I was limiting the servo angle in the method that controlled it to 0 to 60 degrees.  So basically, I was just trimming the data by 10 degrees on both sides.  So... without trimming the idea still works, but it makes the servo a little spazzy.  The problem remains the same, the servo was overshooting the mark so I was really reading from -10 to 70 degrees.  With one sweep going -10 to 50 and one sweep going from 70 to 20.  However, the best solution is to trim off the extra input that does not overlap, not to tell the servo to go to different angles.  They both work, but the latter isn't as reliable.

[DomoArigato]

So I've been reading more and more on servos, and I guess this may be obvious to most people, but I'm posting this for people who may be new like me.  Servos all have varying accuracy (repeatability/centering).  So depending on your application (I want to do SLAM) it may be worth it to spend a little more on a servo that is more accurate.  I've decided just for fun, I'm going to buy a nicer servo and see if it changes to shifting compensation I have to do.  My robot just got closelined by a rail last night, and the servo I've been using is toast.  So maybe the servos ability to put up to abuse will be important to consider as well.

[JesseWelling]

I think for you metal geared servos may be in order 

[Admin]

Hmmm thats a really big overshoot! Ive never seen more than 3 degrees, and its usually undershoot caused by a large load.

The closelining is kinda funny . . . you may perhaps want to add a sonar as an emergency bumper? I used two infrared LED emitter/detectors as 'emergency' sensors for my hypersquirrel robot . . .

http://www.youtube.com/watch?v=iQkY68h63X8

Let me know what you find out about the higher accuracy servos, Im curious . . .

[DomoArigato]

So I finally got the shifts and the servos all figured out... well mostly.  Here is what I've learned about servos: Both servos seem to be more than accurate enough for what I'm doing, even though the digital servo has a better resolution.  This guy did a review of a digital servo and did some interesting accuracy tests.  http://www.rcgroups.com/forums/showthread.php?t=360782  I no longer think shifts are caused by innaccurate servos, now it looks like the servo may be off by at most 1-2 degrees.  Servos could need calibration, but probably not on a 60 degree sweep. http://www.davehylands.com/Robotics/Servos/

Most of my previous ideas seem to be totally bogus when it comes to repairing the timing errors/shifting errors.  Here is what I've learned about the shifting in the 2d mapping.  I don't think the servos speed is the limiting factor when working with Sharp IR Rangefinders.  Sharp IR Range finders take 5ms or more to refresh depending on the model. See page 2.  http://www.acroname.com/robotics/parts/gp2y0a02_e.pdf  Sharp IR Range finders may be more accurate when mapping horizontally if mounted vertically? See page 3.  http://www.acroname.com/robotics/parts/GP2D120_SS.pdf  When I threw the servo off randomly by 20 degrees, it seemed like it caught up back to where it was supposed to be pretty quickly (right back on target with the rest of the data, but still shifted).  For me the shift was generated on the start of the first sweep, and was a one time thing, but if not corrected every sweep would offset by the amount of error in the first scan.  Not leaving enough of a delay didn't seem to be a problem for the servo, but rather for the IR Range finder.  Less delay did create a greater shift, but again it is only a one time shift at the start of the first scan.  When the delay was too short, the ADC data started to show plateaus instead of nice curves, and the data didn't have the same depth as slower scans.  To solve the problem I just started the scans, and when reading the data instead of reading from 0-60 then 61-121  I would just start at location 10 and goto location 70, then 71 to 131.  This just ignored the crazy shift that happend at start up, the frequency of the cycles from the scan remained constant at 61 degrees (0 to 60 inclusive), I just had to find the right place to start to make all the scans match up.  I can get decent scans with a delay of roughly 8-10ms.  Below 8 and I got plateaus.  I've included some pictures.  One shows a data cycle with a good delay, but still a blip at the start (hard to see).  One shows data where there wasn't enough delay for the rangefinder and ADC the small blip at the very start on this one is bigger and easier to see.  One shows the vision increasing and decreasing without correction, and one shows what happens when you ignore that shift at the start of the scans.  Hopefully this helps somone else trying to do 2d mapping.

[Admin]

Ok this makes much more sense now.

Sharp IR Range finders take 5ms or more to refresh depending on the model.

I remember seeing 35ms Sharp IR rate + 1ms for ADC on the uC . . . But yea thats my theory for the problem too.

I can get decent scans with a delay of roughly 8-10ms.  Below 8 and I got plateaus.

I was always too lazy to graph shift vs servo speed. Since you have it all set up already, any chance you can do this? Just speed up the servo, plot, speed up again, plot, etc. Knowing the exact shift allows you to fudge in software, anyway . . . So when you say 8-10ms, you mean the time difference between taking a read, and then telling the servo to move again?

My current project will require making nice 2D maps with a servo scanner, so Im thinking of running the servo, making sure its stopped, take a reading, then move it again. But continuous readings just looks nicer . . .