That kind of encoder doesn't control a motor directly, its single purpose is to give you feedback on the position of the motor shaft. Regardless of the kind of motor you'll need to monitor the position of the motor using the encoder and then control it appropriately until it's in the required position.
The algorithm might be something like a PID controller or just something simple that moves the motor in the correct direction until the position is reached, possibly slowing it down as it approaches the desired position.
A likely problem attempting to use it directly with a Raspberry Pi is that the encoder outputs as shown in the datasheet will probably occur too quickly to deal with in a userland program and would likely need to use interrupts (ie kernel code) to operate reliably. I'd normally use a seperate microcontroller for such a task to read the encoder and control the motor in real-time and interface that back to the Pi using a SPI or serial interface.
While it would make an interesting project I can't think of any especially easy way to use the combination with a Raspberry Pi and it would probably be a challenging project if you haven't done much with motor control systems.
Edit:
I found the cause of the spikes.
The BMI055 chip is internally flawed, I am sure of it now.
If you read out the FIFO in Bypass mode (that means only one frame is kept) then you have to expect data errors.
If you read it faster than the sampling rate you receive 10% 0x8000 (smallest possible number) in the mix. Not zero, not the last value .. a MAXIMUM value!
If you read the data a bit slower than the sampling rate, you receive valid data with 1-8 spikes per second.
This happens if you use the FIFO register in 6 or 8 byte burst mode.
Now I got curious, I read the 0x02 register in 6 byte burst and this gives the same data (x,y,z) and I changed absolutely nothing else.
The spikes are reliable gone.
previous text:
It seems that the gyroscope itself is flawed and it is not just that one.
I first expected an error in I2C communication, turned down the speed and exchanged the voltage shifting circuit without any change in results.
Now as I identified the problem to come from random high spikes I could also find many other people with similar issues or reports.
Surprising fact is that there are rarely any answers.
My first test was a moving exponential average filter, but as I expected that ruins many subsequent readings and only dampens the spikes.
The best solution I can think about is to use two gyroscopes, that is what I will do longterm.
They will likely both have spikes and by comparing both frames with each other it should be possible to get a very good result and no spikes.
The simple solution is to filter spikes based on a hardcoded max-change value.
I first considered capturing data at twice the current rate and then always lagging behind one frame.
That way I would know the 'future' and the past, if the 'current' data is way off from future and past it is a spike (or someone hit a hammer on the sensor).
But for gyros with high degree/s resolution and pratical use outside of 2000deg/sec the filtering can be easier.
I played around and was shaking the gyro heavily, the raw values rarely exceeded +10k and no matter what I did they did not have any such sudden changes, even during a drop on the table.
I use this now:
if (abs(old-current)>0x3000) use_value();
So if the result is off by more than 12,000 raw values in comparison to the previous value than the previous value will stay in the variable. Otherwise the variable is updated with the new value.
Now I have a quite low drift which even works for many minutes.
Sidenotes about the used gyro:
a) The BMI055 gyroscope is specified to return ZERO if you sample it too fast, in reality it returns random values.
b) The BMI055 gyroscope crashes the I2C bus if you send a soft_reset to it (the onchip ACC doesn't do that)
c) Sudden spikes are not described in the datasheets of the gyros and still many people notice them. That's quite strange.
I would appreciate a better answer, maybe I am wrong.
However, the spike filtration made my program work quite reliable compared to the unusable results earlier.
Currently the sensor is always at the center if I move it. I want to get the position of the sensor as the box is in a fixed position the thing moving is the sensor itself.
Best Answer
Ultimately, it's about maths, not Electrical Engineering.
So far as the LIDAR is concerned, it is at the centre of the universe, and it defines a zero degree axis. All the coordinates it returns are relative to that centre and that axis.
It probably returns polar coordinates (r, θ), where r is range and θ is angle relative to the axis. It should be a simple bit of trig if you would prefer them converted to (x, y).
Your task is to perform a rotation and translation on those coordinates to align them with what you have chosen to be the centre of the universe - the box. The tricky bit is working out what that translation and rotation is.
If you are in a box, you should find that the points neatly fall into straight lines. You will need to work out some way to determine which points are in which lines. Perhaps use a Hough transform. Or just pick a group of sequential points from the LIDAR and determine whether they are close enough to forming a straight line.
Once you know where the lines are, relative to the LIDAR, you can work out the rotation to turn the lines to where you want them, then the translation to move everything relative to the centre of the box.
Be aware that if the box is a simple rectangle or square, then there is always some ambiguity. If some sneaky person turns the LIDAR off for a moment, rotates the whole thing 180° and turns it on again, you will have no way to know.