DE-ACCM3D accelerometer & Junebug - A/D question

[futz]

I got my **broken link removed** and have it wired up to the Junebug. Junebug is reading AN1, AN2 and AN3 and spitting out numbers to the UART tool. I have the 18F1320's AD in 8-bit mode, dropping the bottom 2 bits and am getting numbers in the range of approximately 68 to 103 decimal on each axis (1g gravity - I'm just tilting it). The actual voltages output by the accelerometer would be approximately 1.33V to 1.99V.

Now my newb question: I have the 18F1320 set to use the internal AVDD (5V) for a reference. If I set it for External VREF+ and feed RA3 with 3.3V from the regulator on the accelerometer, will I get a wider range of values in ADRESH? Or in other words, will I get better sensitivity?

Should I switch to 10-bit and rewrite my software?

This photo is slightly out of date. Had to add a power supply to the breadboard as the Junebug/PICkit2 can't supply VDD and do UART tool at the same time.

 

[ericgibbs]

I got my DE-ACCM3D accelerometer and have it wired up to the Junebug. Junebug is reading AN1, AN2 and AN3 and spitting out numbers to the UART tool.

I have the 18F1320's AD in 8-bit mode, dropping the bottom 2 bits and am getting
numbers in the range of approximately 68 to 103 decimal on each axis (1g gravity - I'm just tilting it).

The actual voltages output by the accelerometer would be approximately 1.33V to 1.99V.

Hi futz,
Some calculations that may help:

5Vref, 10bit
Val1= [1.33/5] * 1023 = 272
Val2= [1.99/5] *1023 = 407

5Vref, 8bit
Val1a= [1.33/5]*255= 67
Val2a=[1.99/5] * 255 =101

2.5Vref, 10bit
Val1=[1.33/2.5]*1023 = 544
Val2=[1.99/2.5]*1023 = 814

2.5Vref, 8bit
Val1a=[1.33/2.5]*255 = 135
Val2a=[1.99/2.5]*255 = 202

Ideally to increase the resolution to cover the span and offset of the accelerometer you need a OPA with Offset.

Hope this helps.

 

[ericgibbs]

hi futz,

This is a simple instrumentation amp with offset, I designed for use with a altimeter.
The principle is the same for accelerometer, it would require a lower setting for the Offset voltage and a tweak to the Gain.

The Acc 1.33V to 1.99V would be offset to 0v thru +5V, giving an ADC value of 255 or 1023 max, depending upon the justification of the ADC value.

Do you follow OK.?

 

[futz]

Hi futz,
Some calculations that may help:

Ideally to increase the resolution to cover the span and offset of the accelerometer you need a OPA with Offset.

Hope this helps.

It does. Thank you for the comments and calculations.

I did some reading of the datasheet too, and calculated that at -3g the output voltage will be .66V and at 3g it will be 2.66V (it's a 3g accelerometer). It's already op amp buffered - not just a bare accelerometer chip. It looks to me like just doing a 3.3V ref voltage will give me the kind of results I want without extra circuitry.

So at 3.3V VREF+ I should see approximately:
-3g = .66V = 51
-1g = 1.33V = 103
0g = 1.66V = 128
1g = 1.99V = 154
3g = 2.66V = 206


I'll try it today and see.

The DE-ACCM3D datasheet.

 

[futz]

Hey Blueroom Bill! If you're reading this thread, why does AN4 have a pullup?

I moved my Z axis to AN4 (so I could feed AN3 with a 3.3V reference) and it won't work. I'm pretty sure it's because of that pullup. The accelerometer is fine and the cable is fine. I moved wires around to test all that.

Anyway, giving the AD a 3.3V reference worked as I predicted. Full range (-3g to +3g) gives me a ADRESH value swing from approx 51 to 206. Quite useable.

 

[blueroomelectronics]

AN4 has a pullup for 1wire stuff, also on older PICs including the 18F1320 RA4 is an open collector output.

I did design the Junebug with +VREF as one of the experiments (using VR2) and VR1.

You could move the Z axis to RB3 (yes it's analog) or RB4 (the RX pin). Use a software UART on TX.

Just my 2c

I always enjoy your Junebug articles and photos futz.

 

[futz]

You could move the Z axis to RB3 (yes it's analog) or RB4 (the RX pin). Use a software UART on TX.

I don't really need my Z axis right now anyway. I just unplugged it.

What I'm moving gradually toward is a balancing robot, so I'll really only need one axis. I know everyone says you can't do it without a gyro because the oscillations feed back and the thing falls down, but I'm going to try anyway. I can't believe you can't write some smart software that compensates and damps things.

Any robot I build will be very unlikely to be carrying my Junebug anyway. I'd probably either build a pic-proto type board for it or just use a solderless breadboard for easy changes.

And I think that proper accelerometer location on the bot could go a long way towards making it more stable. I figure that if I locate it at the "CG", or midpoint, the accel won't feel the g-forces as much and won't oscillate so hard. Watch me be dead wrong.

And if I fail I'll learn something anyway, and I'll have the chassis all ready to add a gyro onto.

 

[blueroomelectronics]

Balancing robots are cool.
http://www.geology.smu.edu/~dpa-www/robo/nbot/

I've seen one using a Sharp IR sensor to balance, can't recall the link though. Would be a fun mod for the Mongoose.

 

[futz]

Balancing robots are cool.
http://www.geology.smu.edu/~dpa-www/robo/nbot/

I've seen one using a Sharp IR sensor to balance, can't recall the link though. Would be a fun mod for the Mongoose.

They are cool. Guys are finding them too easy now, so the new thing is to build a unicycle (one wheel) balancer.

I've seen quite a few that use IR sensors, and a few that use ultrasonic (sonar). They're not as smooth and nice as gyro/accel types though. Even simpler are the ones that use a pot and floor sensor whisker, but they need smooth floors to run on.

 

[3v0]

In 2006 Scientific American had an interesting article on ball bots. They sort of looked like giant roll on deorderants.

EDIT: Found the article online.
https://www.electro-tech-online.com/custompdfs/2008/05/Ballbots.pdf

 

[futz]

In 2006 Scientific American had an interesting article on ball bots. They sort of looked like giant roll on deorderants.

EDIT: Found the article online.
https://www.electro-tech-online.com/custompdfs/2008/05/Ballbots-1.pdf

The unicycle bots I've seen used one wheel that balanced in one axis by the usual rolling back and forth method. The other axis was balanced by a rotating pair of weights or a weighted wheel, like a tightrope walker's arms or the balance stick they use. It just gets rotated the right way to correct the imbalance.

I guess you'd need another set of horizontal "arms" to steer with.

Here are two:
https://www.youtube.com/watch?v=OnRV-ggJmQ4
https://www.youtube.com/watch?v=IlMMWFwHti4

Here's the BallBot. Pretty cool machine:
https://www.youtube.com/watch?v=5le0tQBrGJU&feature=related

 

[futz]

If anyone is interested, photos, movies and source code have been published.

 

[Pommie]

Excellent. Are you going to take it further and build a balancing bot?

Mike.
P.S. Are you going to get that FAT16 code written?

 

[futz]

Excellent. Are you going to take it further and build a balancing bot?

Yes.

P.S. Are you going to get that FAT16 code written?

I haven't even got RAW mode working yet. I'm right there - so close. It almost works. But another shiny thing distracted me and the SD is on back burner now.

I'll eventually get back to it...

 

[futz]

Excellent. Are you going to take it further and build a balancing bot?

Hehehe

A few months ago I caught a guy on his way to the street to put his ancient Meccano set in the garbage. Saved it and now it's my balancer chassis.