Time Required to Read Memsic Accelerometer

JohnBF

I'm building my second balancing robot (I posted the first under Completed Projects on January 1, 07).

For this one I'm using as sensors·the Parallax MX2125 accelerometer and the ADXRS300 angular rate sensor, along with a BS2px. I'd like to read both sensors and do all calculations·within each cycle of·motor pulses so I'm looking carefully at the exact time each taken up by each routine.

I set up a Parallax USB Oscilloscope to measure the time between motor pulses as I progressively isolate each routine. Reading the ADXRS300 (via an 0831 ADC chip to convert the voltage output of the sensor to a digital byte)·takes 2.5 msec. No problem.

The time required to read the MX2125 is surprising - it takes much longer to read the x axis than the·y axis, and the order in which they are read also makes a big difference. The routine is very simple:

Memsic:
· PULSIN MemX, 1, memsicX
· PULSIN MemY, 1, memsicY
RETURN

The time it takes to complete variations of this routine are:

Reading both x and y, as above...· 17.8 msec
Reading both, but y first...··········· 28.0 msec
Reading just x...··························17.8 msec (same as both, starting with x)
Reading just y...·························· 8.1 msec

Does this make sense? Might these results be an artifact of how I set up the test? If these results are accurate then I will see if I can orient the device so I can get a good reading just from the Y axis. But I wonder if anyone has any insights about what's going on.

/John

JohnBF

I tested further and learned more. The time it takes to complete a reading is related to how the MX2125 is oriented and what it's doing. This possibility didn't occur to me before so it was just lying there any old way. When an axis is best positioned to report acceleration on that axis the cycle time is about 8 msec. When it is worst positioned it goes up to around 28 msec. But accelerations extend the time a couple of mseconds. So if the device is horozontal and still the cycle time is about 8 msec. If it is rotated briskly around the x or y axis the cycle time jumps around between 8 and 10 or 11 mseconds.

/John

Beau Schwabe

JohnBF,

When I wrote a Propeller object for the MemSic2125, I scoped both channels from the MX2125 first to see what kind of signal I was dealing with. Both X and Y pulses start out at the same time, but depending on the orientation/acceleration, one pulse will usually finish before the other. Only when the orientation and/or acceleration between channels are Equal will X and Y be the same. At room temperature and 0g/0acc, the value
for X and Y should both be close to 5mS.

Depending on the orientation and/or acceleration, the Pulse width for each channel can vary from 1.25mS to 8.75mS indicating a value from -3g to 3g with a repetition rate every 10mS.

8.750mS -     3g
7.500mS -     2g
6.250mS -     1g
5.000mS -     0g
3.750mS -    -1g
2.500mS -    -2g
1.250mS -    -3g

Since the BS2 can not read both axis simultaneously, a value of 17.8 is not out of the question..... (8.75mS + 8.75mS = 17.5mS) ...Although I would think it unlikely to sustain 3g. <--This should be a worst case scenario. 28mS is extremely high unless you have other delays in your program causing you to "miss" the pulse, requiring PULSIN to wait for the next interval in which case it would take an additional 10mS. This brings the 17.5mS worst case scenario to 27.5mS.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 1/24/2007 4:17:26 AM GMT

JohnBF

Thanks, that's very helpful. And thanks for the Memsic object - the Propeller is definitely going to power my next balancing robot.

/John

Rmilija

JohnBF,

I think you wrote a very cool routine to balance your first Bot, using the PING sensor. I've built a similar Boe-Bot as yours, but using the MX2125. I'd like to try to use your routine but with the MX2125 and I am not sure what changes would have to made. All I know is that the reading values for y axis are min 1875 and max 3125. Could you help me please. Thanks a lot.

//Ray

JohnBF

Hi Ray,

I have not gotten my MX2125/gyro robot to balance yet so I don't have an answer. By the way, the Smart Sensors text (which you can download from Parallax) has an excellent discussion on processing the raw readings from the MX2125.

For a balancing robot, the main problem with the MX2125 is that its tilt readings are confounded by horozontal acceleration as the motors try to stay under the center of gravity. A forward acceleration reads the same as a backward tilt and vice versa. The symptom of this is that you should be able to get the robot's wheels to move correctly if you hold the robot in the air and tilt it forward and back. But the moment you set it on the floor the motors begin a rapid oscillation that does not balance the robot.

What's happening on the floor is that if the robot starts to tilt forward the motors drive forward which makes the MX2125 think its tilting backward so the motors drive backward which makes the MX2125 think it's tilting forward, etc., many times per second.

I know its possible to filter out this noise (because others have done it!) but I have not succeeded yet. A common strategy is to use a Kalman filter (a routine the estimates the true state by cancelling out opposing errors over time) and I also have an idea for another filter strategy.

I came to the conclusion that both the Kalman filter and my own idea were just too processor and math intensive for any version of basic stamp. I'm sure an SX could do it, but instead I've jumped right to the latest thing -- I've taken a break from the balancing robot to learn spin and some prop ASM and then I plan to rebuild the robot around the propeller.

I'd love to hear if anyone else is working along similar lines, particularly any attemps to implement a Kalman filter using a Propeller.

Sorry I can't help more.

/John

Rmilija

John,

Thanks a lot for your answer. It does help me a lot. I tried (today) to modify your program to use MX2125 variables and I am getting exactly the result you are describing. The bottom line - robot does not balance. Instead it wobbles too much back and forth. I am ordering the PING and the SX chip (I was using the BS2 chip before), so I can have the Boe-Bot balance like yours. Please e-mail me on radem2@comcast.net, as I would like to exchange more ideas with you. Thank you so much. I am sure you will succeed with the Propeller, it is just matter of how long it will take you. I also have a VEX kit, which has quite powerful Microchip controller, so I am sure that is a way forward to build more sophisticated robots, but I need to get the basics work first.

brgds //ray

inaki

There is a complete example of robot balancing using the Propeller in an article published in Robot Magazine, that can be downloaded from the Parallax Propeller page.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

JohnBF

Actually, I took a quick look at the article and downloads but I was not impressed. Much of the weight is below the axles so it doesn't look like it needs much logic help to balance. But I will take a closer look at the code to see if there's anything to learn from it. Thanks!

/John

Warrlok

JohnBF said...
Actually, I took a quick look at the article and downloads but I was not impressed. Much of the weight is below the axles so it doesn't look like it needs much logic help to balance. But I will take a closer look at the code to see if there's anything to learn from it. Thanks!

/John

   ' ir ramping

'Ramping is a common term FOR making the servos speed up AND slow down gradually, no sudden starts, stops OR direction changes.  FOR hill detection AND climbing, it's crucial to have a reliable ramping routine for Boe-Bot navigation.  Without it, the Boe-Bot's abrupt motions cause acceleration measurements to get mixed in with the tilt measurements.  This in turn gives the Boe-Bot a false reading of the hill's steepness.

 'THIS PROGRAM WAS PIECED TOGETHER FROM EPROMNAVIGATION AND IR DISTANCE DETECT

 'IF the Boe-Bot starts out going backward instead of forward

'Your servo cables may need TO be swapped.  The cable connected TO the Boe-Bot's left servo should be connected to the P13 servo port on the Board of Education.  The cable connected to the right servo should be connected to the P12 port.

'v        Fine tune the distances so that they make your Boe-Bot travel in a rectangle.  The turn at the first corner should be left, 90°.  The second should be right, 270°, AND the third should be another left at 90°.

' -----[noparse][[/noparse] Title ]-----------------------------------------------------------------------
   ' IR DISTANCEDETECT AND AVOID

'{$STAMP BS2}

'{$PBASIC 2.5}

' -----[noparse][[/noparse] EEPROM Data ]--------------------------------------------------------

' Two DATA directives store the following navigation instructions:

' Forward, left 90-degrees, forward, right 270-degrees forward,

' left 90-degrees, forward, stop.

' -----[noparse][[/noparse] Variables ]----------------------------------------------------------

counter        VAR     Byte                  ' FOR...NEXT loop counter

index          VAR     Byte                  ' Points to EEPROM instructions

instruction    VAR     Byte                  ' Stores navigation instruction

pulseCount     VAR     Byte                  ' Stores navigation distance

pulseLeft      VAR     Word                  ' Stores pulse to left servo

pulseLeftOld   VAR     Word                  ' Previous pulse to left servo

pulseRight     VAR     Word                  ' Stores pulse to right servo

pulseRightOld  VAR     Word                  ' Previous pulse to right servo
freqselect          VAR    Nib
irfrequency         VAR    Word
irdetectleft        VAR    Bit
irdetectcenter      VAR    Bit
irdetectright       VAR    Bit
distanceleft        VAR    Nib
distancecenter      VAR    Nib
distanceright       VAR    Nib

' -----[noparse][[/noparse] Initialization ]-----------------------------------------------------

FREQOUT 4, 2000, 3000                        ' Beep to signify program start

pulseLeft     = 750                          ' Set all pulse values to center

pulseRight    = 750

pulseLeftOld  = 750

pulseRightOld = 750

' -----[noparse][[/noparse] Main Routine ]-------------------------------------------------------

DO                                           ' Begin main routine

  GOSUB get_distances

  pulseleft  = pulsecount + 5 - distanceright *2 - distancecenter *2
  pulseright = pulsecount - 5 + distanceleft *2  + distancecenter *2

   pulseLeft  = pulseLeft  MIN 650 MAX 850 ' Keep 650 <= durations <= 850

   pulseRight = pulseRight MIN 650 MAX 850

  ' This FOR...NEXT loop includes a navigation routine with ramping.

  FOR counter = 1 TO pulseCount              ' Repeat for number of pulses

    ' Navigation routine sets pulse width based on navigation character.

    ' Increment/decrement routine only changes pulse durations by 2 at a time.

    IF pulseLeft > (pulseLeftOld  + 4) THEN pulseleft  = pulseLeftOld  + 4

    IF pulseLeft  < (pulseLeftOld  - 4) THEN pulseLeft  = pulseLeftOld  - 4

    IF pulseRight > (pulseRightOld + 4) THEN pulseRight = pulseRightOld + 4

    IF pulseRight < (pulseRightOld - 4) THEN pulseRight = pulseRightOld - 4

    pulseLeftOld  = pulseLeft                ' Remember old values

    pulseRightOld = pulseRight

    PULSOUT 13, pulseLeft                    ' Send control pulses to servos

    PULSOUT 12, pulseRight

    PAUSE 20

  NEXT                                       ' Check FOR counter... condition

LOOP                                         ' Repeat main routine
get_distances:

     distanceleft   = 0
     distancecenter = 0
     distanceright  = 0

  FOR freqselect = 0 TO 4

       LOOKUP freqselect, [noparse][[/noparse]37500,38250,39500,40500,41500], irfrequency

       FREQOUT 8,1, irfrequency
       irdetectleft = IN9
       distanceleft = distanceleft + irdetectleft

       FREQOUT 6,1, irfrequency
       irdetectcenter = IN7
       distancecenter  = distancecenter + irdetectcenter

       FREQOUT 2,1, irfrequency
       irdetectright = IN0
       distanceright = distanceright + irdetectright
     NEXT
     RETURN

welll i was going to suggest putting·most of the weight below the axel,s with a counterweight half as heavy but twice as far from ur axel (or 1/4 4* as far) this should cancel out acceleration causing tilt u would then still have to cancelout the "noise" this almost a must have in case of emergency stops/trips.and·i think some parts of this code could smooth out ur acceleration /tilt/ issues it uses ramping and alot adding/subtracting and has alot of ajustible varibles its well worth a look,,,GOOD LUCK

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Problems are the "roads" of life,
solutions are only "onramps" to the next problem



············································· "Brad Smith"
·