To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.handyboardOpen lugnet.robotics.handyboard in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / Handy Board / 2256
2255  |  2257
Subject: 
Re: Vector 2x giving me lots of trouble...
Newsgroups: 
lugnet.robotics.handyboard
Date: 
Mon, 2 Jun 1997 14:39:23 GMT
Original-From: 
root <root@snotnose.%stopspammers%wizard.org>
Viewed: 
1387 times
  
Well, I seemed to have narrowed down the problem I was having with the =
Vector2x compass. ... hose the pcode, and crash. ... It was functioning
fine...  All I had to do was write clean code that called comp_disable(1)
at the end.

Yes, I had this problem also.


I think we should try and write some code for the compass so that works
as a slave, and you could just request the current heading from it.

That is a good idea but there's no reason to put the compass into Slave mode
to do it. According to the Vector docs while the compass is in Master mode
you can either hold P/C low for continuous sampling or pulse P/C low briefly
(about 10mS minimum) to get one reading. With this in mind there's really no
reason to do anything except just alter the current code a bit.

The thing to do is to let the interrupt code handle the SPI interrupt stuff
(reading the bytes) and simply trigger P/C in your C code. And if you hold
down P/C a little too long, big deal- you get two readings instead of one.
It shoves the data into the same location so you won't know the difference
anyway. And best of all, no more crashing.

Also its probably a good idea to enable the SPI interrupt in your C code too
(right before bringing P/C low). Modify the ASM code so that compass_init()
doesn't turn on the SPIE bit and make sure to to leave the SPIE bit CLEARED
when it returns from servicing an interrupt. Don't mess with it anywhere else
since the interrupt-service routine needs to use it while reading the SPDR
bytes.

Here are some code snippets for setting a particular bit. The 'PortVal'
variable is the current value of the port. If you can read the port directly,
that is the best way and you can replace 'PortVal' with something like
'peek(port)' but since a lot of the Handyboard (and Gadget board) ports are
"set only" you'll need to keep a private copy of what you think the port
should be. A litte alteration and these routines work on regular numbers too.
Both routines accept the SAME mask- SET the bits you want set or cleared by
the routine.


int PortVal = <current_port_value>;


void bitset(int loc, int bits) {  /* set bits in byte in loc */
        poke(loc, PortVal | bits);  /* Make sure these bits are set */
        }

void bitclr(int loc, int bits) {  /* reset bits in byte in loc */
        poke(loc, PortVal & ~bits);  /* Make sure these bits are not set */
        }


To enable the SPI interrupt, you will need to set the SPIE bit (SPI interrupt
enable) of the SPCR register. To disable the SPI interrupt you reset the SPIE
bit. The bits of the SPCR register are:

SPIE SPE DWOM MSTR CPOL CPHA SPR1 SPR2

So, using the routines above you would say something like:

bitset(0x1028, %10000000);

or to clear the bit you would say

bitclr(0x1028, %10000000);

Any bits not explicitly declared as ones will be left alone- ie retain their
previous state- assuming the value stored in PortVal is correct. Practicaly
speaking the value of PortVal will be the same as the value stored in the
SPCR register in the interrupt routine- probably something like %11000000.
As an aside, the SPR1 & SPR2 bits are completely irrelevant while the CPU is
in SPI Slave mode so they can be set to any value.

So, I don't think that setting the compass to Slave mode is really required.
However, if someone does get the compass working in Slave mode I'd like to
hear about it. I messed with it for quite a while and I've given up. The
problem appears to be that the 6811 is not clocking the data out of the
compass correctly. I don't know enough about the SPI stuff to know exactly
what to do about it though. I'd like to experiment with RAW mode (or at least
see what the data looks like- if anybody has tried RAW mode I'd like to hear
what you think about it).

Finally, do any of you folks out there using the Vector worry about
calibration? I haven't tried calibrating my compass yet. It seems reasonably
accurate the way it is. I don't know if what it says is 0 degrees is really
north or not but it does seem to be stable- in other words 0 degrees is always
in the same direction. So even uncalibrated it appears to be useful. In my
application I only care about the relative angle anyway and not really north
or south (although knowing the real direction is useful information). I have
not extensively checked to see if there is any drift in its heading between
power cycles but from casual observation there is none. So it is my guess that
calibration only aligns it with the true poles by tweaking some sort of
internal offset. Does anybody else mess with calibration?


I also find it difficult to shield the Vector2x from the magnetic =
effects of the HandyBoard itself, and the motors.  I've had to position =
it quite a distance away (kind of difficult on my small robot), and =
spent quite a bit of time leveling it.  Perhaps I should have picked up =
the gimbled version...

I have the gimballed version and in my opinion its pretty cheesy. The gimbals
are made of cheap plastic and certainly not worth another $50 in my view. It
adds another inch or so to the height of the compass as well. If I were to
buy it over again, I'd just get the $50 version and forget the gimbals. If
your robot just runs around on the floor or table top you especially don't
need the gimbals. Use the extra $50 to by a Polaroid unit or something :)

Mine has just gone into the robot (physically) yesterday so I haven't had a
chance to see if the motors will affect it much. I suspect they will as I've
noticed that if I walk near the compass it drifts a few degrees. That also
might be a useful phenomenon if I can figure out how to exploit it. However,
I have had my compass virtually on top of the Gadget board the whole time I
was messing with it and didn't notice any differences due to the CPU. I wonder
if building some mu-metal shields for the motors would help at all? I seem to
recall Radio Shack having sold little mu-metal squares at one time. Does
anybody know if that's still available?


John Whitten
brat@naxs.com



1 Message in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR