Is run_to_abs_pos() working?

[ndward]

I'm using the 13 December Stretch image on an ev3. I am trying to make the US sensor scan across 180 degrees, with the motor making 45 steps of 4° each, like a radar. I first tried the script below which uses run_to_rel_pos() but the end result was that the movement was not precise, despite the use of 'hold' rather than 'brake' which should help the precision. With the large motor, the angle was about 190° and with the medium motor it was about 150°. Since the idea is to then move the sensor quickly back to its original precision and repeat the scan, the errors would accumulate.

#!/usr/bin/env python3
from ev3dev.ev3 import *
from time import sleep

mB = LargeMotor('outB')
mB.stop_action = 'hold'
lcd = Screen()

positions = ''
for i in range(1,46):
    mB.run_to_rel_pos(position_sp=4, speed_sp=200)
    mB.wait_while('running')
    positions = positions+' '+str(mB.position)
    if i%7 == 6:
        positions = positions+'\n'
    sleep(0.4)

#lcd.clear()   # not needed?
lcd.draw.text((0, 10), positions)
lcd.update()
sleep(10)

So then I tried using run_to_abs_pos() instead, and that worked much worse. My impression is that after every movement, the absolute position resets to zero, which means run_to_abs_pos() in fact works like run_to_rel_pos(), at least for me. Can anyone confirm? In these scripts, the position of the motor is recorded after each 4° motion and then all the positions are displayed after the motion ends.

#!/usr/bin/env python3
from ev3dev.ev3 import *
from time import sleep

mB = LargeMotor('outB')
mB.stop_action = 'hold'
lcd = Screen()

positions = ''
startpos = mB.position   # will it always start at zero?
for i in range(1,46):
    mB.run_to_abs_pos(position=startpos+i*4, speed_sp=200)
    mB.wait_while('running')
    positions = positions+' '+str(mB.position)
    if i%7 == 6:
        positions = positions+'\n'
    sleep(0.4)

#lcd.clear()   # not needed?
lcd.draw.text((0, 10), positions)
lcd.update()
sleep(10)

[WasabiFan]

So then I tried using run_to_abs_pos() instead, and that worked much worse.

How so? What was worse about it?

[attojeon]

How about this? I've rest the motor's position before call the run_to_abs_pos(). and It works good. from ev3dev.ev3 import * from time import sleep m = LargeMotor('outB') m.position = 0; # reset to 0 before call run_to_abs_pos(); m.run_to_abs_pos(position_sp=360, speed_sp=900, stop_action="hold") sleep(3) m.run_to_abs_pos(position_sp=0, speed_sp=900, stop_action="hold") sleep(3) m.run_to_abs_pos(position_sp=-180, speed_sp=900, stop_action="hold") sleep(3) m.run_to_abs_pos(position_sp=0, speed_sp=900, stop_action="hold") sleep(3) 2018-01-08 9:43 GMT+09:00 Kaelin Laundry <notifications@github.com>:

…

So then I tried using run_to_abs_pos() instead, and that worked much worse. How so? What was worse about it? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#439 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHYlQWRNfP6UM6fRi_UU2lJMA2_GKuZtks5tIWSZgaJpZM4RV2gi> .

[ndward]

So then I tried using run_to_abs_pos() instead, and that worked much worse.

With the script above that uses run_to_rel_pos() the motor moves roughly as desired i.e. in 4 degree steps 45 times, but that 180° sweep accumulates a large error, sometimes more than 15%.
With the script above that uses run_to_abs_pos() the motor is instructed to move to absolute position 4° then absolute position 8° etc i.e. move in constant 4° steps but in fact it moves first 4° then 8° etc i.e. the steps get bigger and bigger, which is why I say it is behaving like run_to_rel_pos() rather than run_to_abs_pos().

The script by @attojeon works but is not what I am looking for - I want the motor to pause after every 4° of turn so that the US sensor can take a reading. This script will ultimately be used to do something like a radar scan. Resetting the position of the motor with mB.position = 0 before the motor scans does not fix my script.

[ndward]

Eureka! The solution was to use position_sp rather than position with run_to_abs_pos(), but to keep using position elsewhere (just as @attojeon did). With some other adjustments, including stepping back to the start, the script is now:

#!/usr/bin/env python3
from ev3dev.ev3 import *
from time import sleep

mB = LargeMotor('outB')
mB.stop_action = 'hold'
lcd = Screen()
positions = ' 0'
mB.position = 0 # needed

for i in range(1,46):
    mB.run_to_abs_pos(position_sp=i*4, speed_sp=200)
    mB.wait_while('running')
    positions = positions+' '+str(mB.position)
    if i%7 == 6:
        positions = positions+'\n'
    sleep(0.4)
sleep(2)

for i in range(44,-1,-1):
    mB.run_to_abs_pos(position_sp=i*4, speed_sp=200)
    mB.wait_while('running')
    sleep(0.4)

lcd.draw.text((0, 15), positions)
lcd.update()
sleep(10)

A printout of positions for the first sweep shows: 0 6 9 13 17 25 29 .... 180 so there are small errors in position but they do not accumulate. If I had not wanted to print the positions I could have used, for improved clarity, for i in range(4,184,4): and for i in range(176,-4,-4):
I also tried with the medium motor and it worked fine.

I do think beginners (like me!) could get confused between position and position_sp. Maybe the docs could be clearer. Currently position has this documentation: Returns the current position of the motor in pulses of the rotary encoder. When the motor rotates clockwise, the position will increase. Likewise, rotating counter-clockwise causes the position to decrease. Writing will set the position to that value.
One could interpret the last sentence as meaning that the position of the motor will be set to the value of position, but that seems not to be the case.

Also, I'm not sure that it's meaningful to speak of the large motor 'rotating clockwise', since you can use either side of the motor, and when one side rotates clockwise the other side rotates counter-clockwise.

Also, I think there is an error in the documentation for position_sp which refers to counts_per_rot which should be count_per_rot.

[rhempel]

Please open a new issue to ensure the document gets updated as you suggested 😀

[ddemidov]

Fixed the position_sp documentation in 7578c1f

[WasabiFan]

@ddemidov what do you think about throwing an error when an unknown property is used? Would there be an issue with checking for the property name on self?

[ddemidov]

Don't we already do this since #278?

[WasabiFan]

This is a slightly different problem than I was imagining; it's not that he was using a nonexistent property, it's that he was using a property that exists but isn't of much use in that context. Solving that is a bit more difficult.

[ddemidov]

I guess we could introduce a set of warnings, basically a dict similar to this:

warnings = {
  'run-to-abs-pos' : {
    'position' : 'Warning: setting "position" during "run-to-abs-pos"'
  }

Then we could use the dict (probably with a helper function) inside the command functions.

But, it would still be possible to do

m.position = 0
m.run_to_abs_pos()

and not get any warnings, so I am not sure how helpful it would be.

[ndward]

Maybe the distinction between position and position_sp is not so difficult. Would it be true to say that position represents the actual position of the motor and, in the context of run_to_abs_pos(), postion_sp represents the target position of the motor, which is not the same thing? What remains unclear to me is what is the zero for position - it does not seem to be a fixed position on the physical motor itself, nor does it seem to be the position of the motor when the script starts. But resetting position to zero as in the script above removes this uncertainty.

[ddemidov]

Would it be true to say that position represents the actual position of the motor and, in the context of run_to_abs_pos(), postion_sp represents the target position of the motor?

That is correct, anything with _sp (Set Point) is a target.

What remains unclear to me is what is the zero for position

When you set position to zero, you are simply resetting the value of internal counter. Any subsequent measurements will be taken relative to this position.

[ndward]

My question was really, what is the 'zero' position if you DO NOT set position to zero.