Loading ...
Sorry, an error occurred while loading the content.
 

Mirco with good Serial ability

Expand Messages
  • Robin Bailey
    Fellow SRS ers I m working on a RoboMagellan robot and we are attempting to have a microcontroller read the TTL-level Serial data from a NEMA gps receiver and
    Message 1 of 9 , May 2, 2006
      Fellow SRS'ers
      I'm working on a RoboMagellan robot and we are attempting to have a microcontroller read the TTL-level Serial data from a NEMA gps receiver and decode it and send it to another micro then that micro will send it with other data to the laptop which does the path planning. The protocall between the two micros if figured pretty well.
      My question is reading in from the GPS, using qualifiers, that can read a string of characters. For example a picaxe has the prequalifier option, but it reads only one byte.
      My only workaround figured is to just send the raw data from the GPS to the laptop and the have the laptop decode it itself. This will be done by occasionally sending a second or two of the gps strings, between the other data transmission, by just throwing it onto the serial link to the laptop.
      Due to the nature of the robot, the GPS cannot be connected to the laptop directly.
      Comments or suggestions....?
      Robin Bailey
      Utah State U Robotics Club
      p.s. We are hoping to have a competition robot by the end of the summer.

      [Non-text portions of this message have been removed]
    • The Earl
      You may be able to use some of the code from the GPSd project. http://gpsd.berlios.de/ On 5/2/06, Robin Bailey robin-at-robinbailey.com |6812-the|
      Message 2 of 9 , May 2, 2006
        You may be able to use some of the code from the GPSd project.

        http://gpsd.berlios.de/

        On 5/2/06, Robin Bailey robin-at-robinbailey.com |6812-the|
        <...> wrote:
        > Fellow SRS'ers
        > I'm working on a RoboMagellan robot and we are attempting to have a microcontroller read the TTL-level Serial data from a NEMA gps receiver and decode it and send it to another micro then that micro will send it with other data to the laptop which does the path planning. The protocall between the two micros if figured pretty well.
        > My question is reading in from the GPS, using qualifiers, that can read a string of characters. For example a picaxe has the prequalifier option, but it reads only one byte.
        > My only workaround figured is to just send the raw data from the GPS to the laptop and the have the laptop decode it itself. This will be done by occasionally sending a second or two of the gps strings, between the other data transmission, by just throwing it onto the serial link to the laptop.
        > Due to the nature of the robot, the GPS cannot be connected to the laptop directly.
        > Comments or suggestions....?
        > Robin Bailey
        > Utah State U Robotics Club
        > p.s. We are hoping to have a competition robot by the end of the summer.
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >
        > Visit the SRS Website at http://www.seattlerobotics.org
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
      • Tom Capon
        So, you want the setup: GPS --[raw data]-- microcontroller --[decoded data]-- microcontroller --[lots of data]-- laptop Am I correct? Just about any micro
        Message 3 of 9 , May 2, 2006
          So, you want the setup:

          GPS --[raw data]--> microcontroller --[decoded data]-->
          microcontroller --[lots of data]--> laptop

          Am I correct?

          Just about any micro can do this, although I'm not sure how many small
          chips have two hardware UART's (I know none of the PICs do, some AVRs
          might). But you can bit-bang one of the UARTs, or use a synchronous
          protocol (like I2C) between the two micros (many PICs have separate
          UART and SPI modules)

          Once you get the serial stream into the micro, it can byte-wise decode
          the stream, hopefully on the fly. Unless there is really complex
          calculations involved in decoding, I see no reason why a laptop has to
          do it.

          For example, you could have the micro look at each byte as it comes in
          and check if it is a certain byte; if it gets the flag byte it will
          then store a certain number of bytes and then send them to the other
          micro. That's a pretty simple program.

          You'll probably want to go with a pretty "hard-core" micro,
          programming the basic chip in assembler or C rather than a composite
          chip (like the basic stamp) or a higher-level language like Basic.

          Hope this helps.

          --Tom Capon


          On 5/2/06, The Earl <1m5p8j603@...> wrote:
          > You may be able to use some of the code from the GPSd project.
          >
          > http://gpsd.berlios.de/
          >
          > On 5/2/06, Robin Bailey robin-at-robinbailey.com |6812-the|
          > <...> wrote:
          > > Fellow SRS'ers
          > > I'm working on a RoboMagellan robot and we are attempting to have a microcontroller read the TTL-level Serial data from a NEMA gps receiver and decode it and send it to another micro then that micro will send it with other data to the laptop which does the path planning. The protocall between the two micros if figured pretty well.
          > > My question is reading in from the GPS, using qualifiers, that can read a string of characters. For example a picaxe has the prequalifier option, but it reads only one byte.
          > > My only workaround figured is to just send the raw data from the GPS to the laptop and the have the laptop decode it itself. This will be done by occasionally sending a second or two of the gps strings, between the other data transmission, by just throwing it onto the serial link to the laptop.
          > > Due to the nature of the robot, the GPS cannot be connected to the laptop directly.
          > > Comments or suggestions....?
          > > Robin Bailey
          > > Utah State U Robotics Club
          > > p.s. We are hoping to have a competition robot by the end of the summer.
          > >
          > > [Non-text portions of this message have been removed]
          > >
          > >
          > >
          > > Visit the SRS Website at http://www.seattlerobotics.org
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          >
          >
          > Visit the SRS Website at http://www.seattlerobotics.org
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
          >
        • Jim McBride
          I was in the same situation. My robomagellan uses a Mini-itx computer. I needed to serially talk to GPS, Camera, motor control uC, and a sensor reading Uc. My
          Message 4 of 9 , May 2, 2006
            I was in the same situation. My robomagellan uses a Mini-itx computer. I
            needed to serially talk to GPS, Camera, motor control uC, and a sensor
            reading Uc.
            My first solution was to have one uC that was connected to the Mini-itx
            through serial and connect everything else up to that via I2C. The camera
            needed 115200 baud. So I would have to have a little PIC talking to it with
            uart and then pass on info via I2C.

            My ultimate solution was very simple. Buy a PCI to Serial adapter and get
            multiple serial ports on the itx. This won't work for you though.

            As Tom said, many PICs have hardware UARTs, SPI and I2C built in. But I
            think there are two simpler solutions for you.

            Use two small PICs with hardware UARTs. Connect the PICs together via one
            of the 8 bit ports and just do parallel data transfer between them. One PIC
            can talk to the GPS and do any calculations you need and the other can pass
            info on to the laptop.

            Now, I don't know much about GPS yet but if you don't need super fast baud
            rates there is a much simpler solution. Many compiler (PICBasic, CCS C++)
            will let you set up a hardware uart and a software uart at the same time. I
            did this on my vacuum robot. I had one motor control PIC that read encoders
            and did PID, the other one did all the mapping and behavior. They talked to
            each other over hardware UART using interrupts and everything. My behavior
            PIC also talked to my PC over a software UART for debugging. I think you
            should be able to pull this off with one PIC running at 40 MHz. Higher baud
            rates might get tricky but do-able.

            JIMc

            At 09:37 AM 5/2/2006, you wrote:
            >Fellow SRS'ers
            >I'm working on a RoboMagellan robot and we are attempting to have a
            >microcontroller read the TTL-level Serial data from a NEMA gps receiver
            >and decode it and send it to another micro then that micro will send it
            >with other data to the laptop which does the path planning. The protocall
            >between the two micros if figured pretty well.
            >My question is reading in from the GPS, using qualifiers, that can read a
            >string of characters. For example a picaxe has the prequalifier option,
            >but it reads only one byte.
            >My only workaround figured is to just send the raw data from the GPS to
            >the laptop and the have the laptop decode it itself. This will be done by
            >occasionally sending a second or two of the gps strings, between the other
            >data transmission, by just throwing it onto the serial link to the laptop.
            >Due to the nature of the robot, the GPS cannot be connected to the laptop
            >directly.
            >Comments or suggestions....?
            >Robin Bailey
            >Utah State U Robotics Club
            >p.s. We are hoping to have a competition robot by the end of the summer.
            >
            >[Non-text portions of this message have been removed]
            >
            >
            >
            >Visit the SRS Website at http://www.seattlerobotics.org
            >Yahoo! Groups Links
            >
            >
            >
            >

            JIMc
            x22661
            National
            Ignition
            Facility



            [Non-text portions of this message have been removed]
          • Tom Saxton
            I don t understand why you want to have two micros before the laptop, ... I assume you meant to say the protocol *is* figured out. What is that protocol?
            Message 5 of 9 , May 2, 2006
              I don't understand why you want to have two micros before the laptop,
              and I suspect that's an important part of the issue. Your mail said:

              > The protocall between the two micros if figured pretty well.

              I assume you meant to say the protocol *is* figured out. What is that
              protocol? Obviously, the two micros have to support that
              communication. If it's SPI or I2C, there are lots of miros that
              support TTL serial and one of those, many cheap AVR and PSoC chips
              will do. If it's serial, then there are fewer choices, either a more
              expensive AVR chip like the ATMega128, or a PSoC.

              I would read the incoming serial data in an interrupt handler, filter
              and parse the NMEA records you care about with a state machine, and
              send along the parsed data.

              I should warn you that the resolution of GPS data is pretty coarse
              compared to the size of the RoboMagellan course. You're trying to find
              something about a foot in diameter on a course a few hundred feet in
              diamter, by navigating a path that usually has choke points a few feet
              across using data that tells you your position to within 20 to 50 feet
              at best. That assumes that you can even get a GPS signal, which is
              pretty dicey at the Seattle Center. (I don't know where you're
              planning to compete.)

              Robots using pure GPS navigation have consistently slowly wandered
              around the field, seemingly at random, until they collide with
              something or run out of time. I've heard people talk about using GPS
              to correct mistakes in dead-reckoning, but I have no idea how that
              would work given the coarse granularity and unreliable signal.

              --
              Tom Saxton
              carbonring@...
            • Robin Bailey
              ... Yes, that is exactally it. Our system is very modular. For example the high level micro sends a speed/distance command to the micro that runs the motors.
              Message 6 of 9 , May 2, 2006
                > From: "Tom Capon" <robot256@...> Wrote
                > GPS --[raw data]--> microcontroller --[decoded data]-->
                > microcontroller --[lots of data]--> laptop
                > Am I correct?

                Yes, that is exactally it. Our system is very modular. For example the
                high level micro sends a speed/distance command to the micro that runs the
                motors. The motor micro checks the wheel odometry and adjusts for terrain
                changes or a stall condition.
                The GPS is similar, we will just want the system to grab a string of bytes,
                an conversion by that micro may not be needed due to the navigation
                processing will be done by the laptop. The laptop will be the only part of
                the system using the GPS data. But if the conversion was done onboard it
                would be better. We are converting Lat-Long to Northing and Easting. The
                Datum is very simple not taking into account the non-sphereical shape of the
                earth. The calculation itself is fairly simple, the decoding may be
                tricky.

                > Just about any micro can do this, although I'm not sure how many small
                > chips have two hardware UART's (I know none of the PICs do, some AVRs
                > might). But you can bit-bang one of the UARTs, or use a synchronous
                > protocol (like I2C) between the two micros (many PICs have separate
                > UART and SPI modules)
                > Once you get the serial stream into the micro, it can byte-wise decode
                > the stream, hopefully on the fly. Unless there is really complex
                > calculations involved in decoding, I see no reason why a laptop has to
                > do it.
                >
                > For example, you could have the micro look at each byte as it comes in
                > and check if it is a certain byte; if it gets the flag byte it will
                > then store a certain number of bytes and then send them to the other
                > micro. That's a pretty simple program.

                I imagine that is alot like what we will be doing. Although some of the
                flag bytes are mor ethan one byte long.

                > You'll probably want to go with a pretty "hard-core" micro,
                > programming the basic chip in assembler or C rather than a composite
                > chip (like the basic stamp) or a higher-level language like Basic.


                >From: "Jim McBride" <mcbride7@...>
                > As Tom said, many PICs have hardware UARTs, SPI and I2C built in. But I
                > think there are two simpler solutions for you.
                >
                > Use two small PICs with hardware UARTs. Connect the PICs together via one
                > of the 8 bit ports and just do parallel data transfer between them. One
                > PIC
                > can talk to the GPS and do any calculations you need and the other can
                > pass
                > info on to the laptop.
                >
                > Now, I don't know much about GPS yet but if you don't need super fast baud
                > rates there is a much simpler solution. Many compiler (PICBasic, CCS C++)
                > will let you set up a hardware uart and a software uart at the same time.
                > I
                > did this on my vacuum robot. I had one motor control PIC that read
                > encoders
                > and did PID, the other one did all the mapping and behavior. They talked
                > to
                > each other over hardware UART using interrupts and everything. My behavior
                > PIC also talked to my PC over a software UART for debugging. I think you
                > should be able to pull this off with one PIC running at 40 MHz. Higher
                > baud
                > rates might get tricky but do-able.

                Yes, that sounds alot like what we are wanting to do. I have not personally
                delt with UART's or I2C very much. I'd like to get a chance to learn that.
                What is a good micro you might recommend and where might be a good place to
                learn more.

                > Tom Saxton
                > carbonring@...
                >I don't understand why you want to have two micros before the laptop,
                > and I suspect that's an important part of the issue. Your mail said:

                Well our setup like I said above is very modular. It makes it easier to
                modify a part without effecting the whole. Also it is a club project so we
                are trying to give everyone a part.
                About the issue of using only one serial interface with the laptop, we are
                keeping the option of using some wireless radios or having the laptop wired
                onboard.

                > Tom Saxton
                > carbonring@...

                > I assume you meant to say the protocol *is* figured out. What is that
                > protocol? Obviously, the two micros have to support that
                > communication. If it's SPI or I2C, there are lots of miros that
                > support TTL serial and one of those, many cheap AVR and PSoC chips
                > will do. If it's serial, then there are fewer choices, either a more
                > expensive AVR chip like the ATMega128, or a PSoC.

                About protocol (I mis-used that term), we do know what data is being
                communicated to each part of the robot, but much of the actual protocol
                remains to be firgured out. At the moment we have a OOPicII that was going
                to act as the central unit that everything passes through. The motors have
                a serial (TTL) connection with a TX and RX line. We stil have to choose a
                micro to run two sonars, two sharp IR's, and four servos. We also have some
                other tactical sensors to interface. This we were thinking would be a I2C
                to the OOPic. The GPS interface has not been given much work.

                GPS-------->raw data>-----Micro---->decoded data>-----Central Micro-----<all
                data to laptop>-------Laptop

                ^

                |
                Sensors----<control/data>----Micro---->decoded data>-------

                I have never done anything with the AVR or PSoC chips. If there is one that
                is powerful and lots of I/O and communications that people have good luck
                with I'd like to know. I'd be fairly open to most anything below $150.


                > Tom Saxton
                > carbonring@...

                > I should warn you that the resolution of GPS data is pretty coarse
                > compared to the size of the RoboMagellan course.


                I agree on the inaccuracy of GPS. The GPS data is going to be used for
                very broad bahaivors. It will more give a robot a initial orientation to a
                goal and perhaps an occasional progress status. We are going to design the
                system so that once it knows where the goal is relative to start it will be
                able to do well without the GPS. We figured if one thing would fail, it
                would be that signal.
                We also have another receiver that we were thinking of using on a
                basestation that would consist of the laptop and second gps. We would then
                be able to do a diff-gps system, but primarally the robot should be able to
                compete by using localization on it local map alone.
              • Jim McBride
                I learned PICs in school and have pretty much stuck with them. Price is a problem for tools though. For the CCS C compiler and their (really nice)
                Message 7 of 9 , May 2, 2006
                  I learned PICs in school and have pretty much stuck with them. Price is a
                  problem for tools though. For the CCS C compiler and their (really nice)
                  In-circuit-debugger/programmer you are looking at around $300. www.ccsinfo.com

                  If did not already have the equipment I have and was just starting out I
                  would go with the AVR chips. Free GNU C compiler. Programming only takes a
                  parallel port and a hacked parallel cable. They sell them ( cables )really
                  cheep too. Check out www.avrfreaks.com. I think this would be the cheapest
                  way to go.

                  At 01:55 PM 5/2/2006, you wrote:
                  >Yes, that sounds alot like what we are wanting to do. I have not personally
                  >delt with UART's or I2C very much. I'd like to get a chance to learn that.
                  >What is a good micro you might recommend and where might be a good place to
                  >learn more.

                  JIMc
                  x22661
                  National
                  Ignition
                  Facility



                  [Non-text portions of this message have been removed]
                • Tom Capon
                  I ve found the best way to learn about a micro family is just to browse around the manufacturer s website and read the datasheets. I ve heard great things
                  Message 8 of 9 , May 2, 2006
                    I've found the best way to learn about a micro family is just to
                    browse around the manufacturer's website and read the datasheets.
                    I've heard great things about the avrfreaks website, so maybe they
                    have some intro pages that would help you decipher the datasheets.
                    It'll take a bit of work to get used to the particular architecture,
                    but you'll find the payoff is pretty good considering the price and
                    power of what you get.

                    Once you leave the realm of pre-made controller boards and start
                    building your own circuits around individual microcontroller chips,
                    things start getting cheap. I'd guess you could make what you need on
                    a piece of proto-board for about $15, and that's assuming a pretty
                    nice chip (~$7-10). You probably could do fine with an 18-pin device,
                    $4 chip. The only thing that would cost $150 is if you went with a
                    pre-made board like the ones Larry Barello sells on his site. But
                    those are definitely overkill for small node like this.

                    --Tom Capon



                    On 5/2/06, Jim McBride <mcbride7@...> wrote:
                    > I learned PICs in school and have pretty much stuck with them. Price is a
                    > problem for tools though. For the CCS C compiler and their (really nice)
                    > In-circuit-debugger/programmer you are looking at around $300. www.ccsinfo.com
                    >
                    > If did not already have the equipment I have and was just starting out I
                    > would go with the AVR chips. Free GNU C compiler. Programming only takes a
                    > parallel port and a hacked parallel cable. They sell them ( cables )really
                    > cheep too. Check out www.avrfreaks.com. I think this would be the cheapest
                    > way to go.
                    >
                    > At 01:55 PM 5/2/2006, you wrote:
                    > >Yes, that sounds alot like what we are wanting to do. I have not personally
                    > >delt with UART's or I2C very much. I'd like to get a chance to learn that.
                    > >What is a good micro you might recommend and where might be a good place to
                    > >learn more.
                    >
                    > JIMc
                    > x22661
                    > National
                    > Ignition
                    > Facility
                    >
                    >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                    >
                    >
                    > Visit the SRS Website at http://www.seattlerobotics.org
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                  • dalfxxx
                    I m using a PIC18F6722 for a motor control project. It has two independent I2C channels and two USART channels. I have not used the secondary I2C channel or
                    Message 9 of 9 , May 2, 2006
                      I'm using a PIC18F6722 for a motor control project. It has two
                      independent I2C channels and two USART channels. I have not used
                      the secondary I2C channel or the secondary USART channel, but I have
                      used both primary channels without any difficulty.

                      Good luck,
                      Stan

                      --- In SeattleRobotics@yahoogroups.com, "Robin Bailey" <robin@...>
                      wrote:
                      >
                      > Fellow SRS'ers
                      > I'm working on a RoboMagellan robot and we are attempting to have
                      a microcontroller read the TTL-level Serial data from a NEMA gps
                      receiver and decode it and send it to another micro then that micro
                      will send it with other data to the laptop which does the path
                      planning. The protocall between the two micros if figured pretty
                      well.
                      > My question is reading in from the GPS, using qualifiers, that can
                      read a string of characters. For example a picaxe has the
                      prequalifier option, but it reads only one byte.
                      > My only workaround figured is to just send the raw data from the
                      GPS to the laptop and the have the laptop decode it itself. This
                      will be done by occasionally sending a second or two of the gps
                      strings, between the other data transmission, by just throwing it
                      onto the serial link to the laptop.
                      > Due to the nature of the robot, the GPS cannot be connected to the
                      laptop directly.
                      > Comments or suggestions....?
                      > Robin Bailey
                      > Utah State U Robotics Club
                      > p.s. We are hoping to have a competition robot by the end of the
                      summer.
                      >
                      > [Non-text portions of this message have been removed]
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.