ev3dev
Ev3dev odometry
- ev3dev version: 4.14.117-ev3dev-2.3.5-ev3
- ev3dev-lang-python version:
- ||/ Name Version Architecture Description ii micropython-ev3dev2 2.1.0 all Python language bindings for ev3dev for MicroPython ii python3-ev3dev 1.2.0 all Python language bindings for ev3dev ii python3-ev3dev2 2.1.0 all Python language bindings for ev3dev
Hi,
I am using gyro and odometry with MoveDifferential.
tank_drive = MoveDifferential(OUTPUT_B,OUTPUT_C,Tire,WheelDistance)
tank_drive.odometry_start(0,xTank,yTank,sleep_time=0.005)
Command turn_left, turn_righ, on_for_distance, turn_degrees works correctly, when put angle -90 it turns left, angle 90 turns right.
But however if I issue command turn_to_angle and angle_target_degrees = 90 , use_gyto=True, it turns left, but gyro shows -90 also if I put -90 it turns right(gyro output 90), so opposite of what is expected.
Then on_to_coordinates is also opposite for left and right. It seems that coordinate system is with reverse y
.........................|+x
.................1......|..........2
+y------------------------- -y
.......................|
.......................| -x
as I put on_to_coordinates(speed, 200,200) it goes to pos 1, but should go to pos 2.
robot construction is similar to this :
maybe there is wrong direction of motors?
Sorry for the delay.
To confirm, you're saying that e.g. turning right (positive degrees) works fine without the gyro enabled, but is inverted with the gyro enabled? That seems strange if on_to_coordinates is also inverted, since it doesn't use the gyro.
Is your left motor plugged into port B and right into port C?
yes ports are as you described. I made workaround with code to invert axes where it is needed. And finished the project :) Idea was to make robot scan room, send obstacles and it's own coordinates to PC where was drown map and find IR transmitter. After transmitter is found it should go back to it's starting position.
Here is how map looks
and working system https://user-images.githubusercontent.com/77002679/104713259-4ef83900-572c-11eb-8077-e8f8531fe328.mp4
Very cool, and glad you found a workaround! I'm not sure what caused the inversion, but it doesn't sound like there's a strong need to investigate.