I am attempting to get a 4-in-1 sensor to work as I need it to and not have much success - I need a hand.
I am trying to get the 4- in-1 sensor to drive 2 servos to keep something level/plumb.
I have the servos set to go up or down depending on the sensor readings. The problems I'm having are;
1. It will kind of work for a short time but will only drive one servo at a time even if both should move,
2. The Y axis stops working after a few minutes,
3. Then everything stops working,
4. For some reason the 'Sleep' command above the 'loop' is run each time and anything else put there -except the first line.
I am running the sensor on a EZBv4/2. My code is a modified version of one from a JD project.
Here's my code;Code:
ControlCommand("MPU9150", Init)
sleep(1000)
:loop
#Added these because $AccelX and $AccelY were not recognized later in the script for some reason.
$XAccel = $AccelX
$YAccel = $AccelY
if ("x" =0)
print(1)
sleep(2000)
goto(loop)
endif
ControlCommand("MPU9150", RunOnce)
print("x: " + $XAccel)
print("y: " + $YAccel)
if ($XAccel > 1000)
ServoUp(D1,10)
Servospeed(D1,2)
ELSEif ($XAccel < -1000)
ServoDown(D3,10)
Servospeed(D3,2)
Endif
if ($YAccel > 1000)
ServoUp(D3,10)
Servospeed(D3,2)
ELSEif ($YAccel < -1000)
ServoDown(D3,10)
Servospeed(D3,2)
Sleep(500)
endif
sleep(1500)
goto(loop)
Has anyone played with these sensors much and got them working? I know I have a lot to learn about them so your assistance will be appreciated.
Thanks
Asked
— Edited
What you have in mind ?
Are you trying to detect motion or track the orientation ?
Your code reads the IMU every 1.5 seconds. A lot of things can happen in 1500 milliseconds.
@Dave, I'll clean that up, thanks.
@ptp, I am trying to detect motion. The robot starts out level, If the robot is leaned to the left or the right or to the front or back, that will be detected. Then the servos will move the axis effected back to level. I realize that 1500 milliseconds is a long time- I'm just trying to get it to work, then I'll shorten the time.
Code:
But I need 2 servos to run in the code. If I run this code;
Code:
It does not move either of the 2 servos and the code runs lines of code outside of the 'loop'. This is what that looks like;
Code:
I still looking for some help before I give up on these sensors.
Thanks
Try the code below and let us know the output:
Code:
@ptp, Here's a snipet of what I get;
Code:
I worked for a short time then quit working
Did you noticed the servo positions:
Code:
EZ-B Digital Port servo valid positions are 1-180.
Q: The $1,000,000 question what should ARC do with -390 or a 256 value ?
A: Nothing, Ignore => Stop working
You are using ServoUp, ServoDown functions to increment/decrement the position, when you get outside of 1-180 range, ARC ignores the value.
I believe you want track the absolute orientation not the relative orientation.
some examples:
Control the servos manipulating the IMU similar to a mocap or kinect ?
Detect motion (manual pushing or pulling the servos) ?
Fall or equilibrium control ?
Also does not fit in the JD slot, so I order a 4-in-1 sensor to do a demo, it will take a few days to arrive, I'll come back later.
I don't believe you can get good results without a micro-processor processing the IMU data, before being sent to EZB.
most accelerometers are very sensitive, gyrometers drift, compass have noise, you can't rely on a single sensor, you need to query them multiple times per second, combine the sensors and apply a fusion algorithm to obtain "stable" values, this kind operations i.e. 100 times per second or more, can't be done on the PC (EZ-Builder).
So the solution needs an extra addon.
I look forward to seeing what you come up with.
I don't think is related to more than one servo, i believe you can still use the sensor as it is...
The problem is the absolute vs relative values, maybe with some code tweaking you can keep track of the position.
Code:
There may be a need to have external pots monitoring joint positions to provide proof positive feedback of "where the robot is now" So then you are checking the pot values along with the MPU values and deciding what action to take from there.
I agree with the comments about values out of range. "getServo() returns the last postion ARC told the servo to go to.... doesn't mean the servo got there..."
I see that in your calls to ServoUp and ServoDown you are asking the servo to move 15* at each step. In just six iterations you will have moved 90*. Perhaps the reaction should just be a couple of degrees, which is quite a lot for keeping balance.
Thanks for plowin' the field!
S~
bear in mind i don't have DJ's communication skills.
Yes all the axis if you want.
Check the project:
JD_9150Serial.EZB
the problem is not monitoring 1,2,3 axis, the problem is the execution speed several factors:
1) Connection WIFI (EZB4 v1) vs WIFI (EZB4 v2) vs USB (EZB4 v2)
2) EZ-Script code execution
3) Other scripts
I don't believe you can handle a Balanced robot or avoid a fall (Humanoid) or other fast reactions with ARC/EZ-Script only.
I'm guessing some details (i can be wrong), remember Inverted Pendulum
EZ-BIT product:
https://www.ez-robot.com/Shop/AccessoriesDetails.aspx?productNumber=1360
the EZ-Bit consists of a micro-controller and MPU-9150 (4-in-1 Sensor) and has 2 servo ports to control the continuous servo wheels.
Calculating the angle (tilt/pitch), running the actions (back,forward) everything is executed in EZ-BIT micro-controller, a solution like that you don't have speed issues.
The 4-in-1 sensor is connected to the Arduino I2C Bus, and arduino serial port is connected to the EZB serial port 0.
Than i have two versions to handle the serial communication:
1) Pool_IMU Script
Code:
2) Push_IMU Script
Code:
The second script is more efficient a single call to EZB to read the serial port vs two calls.
There is space for more improvement
Handling variable data (Text) and parsing text with EZ-Script is not efficient compared to use I2C bus:
Code:
To support the above solution you need a different micro-controller, one with 2 x I2c bus. Arduino mini is out of the picture, we need an arm cortex micro-controller.
The 4-in-1 sensor is connected to the ARM cortex i2c bus 0 (master), and the second i2c bus 1 (slave) is connected to EZB.
Another interesting detail, with a small adaption the 4-in-1 sensor supports a secondary I2C address, so is possible to use the same micro-controller to handle 2 x 4-in-1 sensors.
The cost is not relevant:
cortex micro-controller is $20 vs Arduino mini $10 and you have more processing power plus the possibility to connect via I2C to EZB.
if you want more details or help with a micro-controller to handle the 4-in-1 sensor drop me an email.