A friend and I are up at Clarkson University this summer for a research project involving robotics. We are working with one of Team 229’s old test robots. Our end goal will be to have the robot navigate campus autonomously, but right now we are in the stage of adding sensors. I’m handling all the electrical work, and my friend is doing all the programming (you’ll probably hear from him in that forum; in think he signed up as Immortalares).
Right now I am finding a way to collect data from an ultrasonic rangefinder. We have this sensor, which operates on an I2C bus. I am able to understand the bus enough to set it up, but I need to know if we will be able to use the RC to interface it. I already found out that the RC is based on a PIC18F8520, but before I read the lengthy data sheet for that chip, does anyone know on what type of bus the RC operates? If it is an I2C bus, is the bus accessible for us to add an additional slave device?
Thanks in advance.
I found in the PIC datasheet that it does support I2C communication, and I have plenty more reading to do on that. I still would like to know how to access the bus on the RC.
Unfortunately you will not be able to use the I2C hardware on the PIC. The synchronous serial module that is used for I2C can be set up for either I2C or SPI, and the RC uses the SPI mode in order to transfer data between the master and user processors.
We ran into a similar problem with our robot (it was a gyroscope, though.) We have thought about synthesizing the protocol using some programming and three digital I/O ports, but that never went anywhere. The closest we got to actually doing something is picking out a secondary PIC with I2C and SPI capabilities, and thinking we’d have the gyro interface with that, and that the secondary PIC would report to the RC. Kinda inefficient, but that’s where we stopped.
Hope this helps!
There are software serial libraries included with PIC 18 C. You would have to use them for SPI or I2C. You might want to look at this app note.
This would be the coprocessor solution. The coprocesssor could also drive a hobby servo to scan a wider arc or 360 degrees. You would have to decide on the protocol for the master slave communications. With the above link, these micro controllers include coproc functions in the language. You would have to duplicate it on the FRC. The above implementation only receives the first ping to return. I believe the device you are looking at can return multiple echos. Useful for finding things like door ways but adds allot of complexity
Some of the IR devices have a narrower field and can be better for close range.
Thanks for the feedback.
I consulted with our research mentor and the route he wants to take is to purchase an PIC18Fxxx series chip that will work with the Microchip compiler, along with an evaluation/proto board and program it to collect our data and pass it on to the RC.
I just emailed several links to our mentor for review; he’s away today but I should hear back from him tomorrow. My partner and I were thinking of a PIC18F452 since the company that makes the ultrasonic rangefinder provides that as an example system on their website, along with some sample code.
Here is the info on that chip:
Microchip offers a demo board with that chip built in and prototyping space for $100, so that is one potential choice:
Another choice would be to buy a blank proto-board and a standalone chip and do the rest ourselves:
On a side note, here are a couple pictures of what we are working on:
i have a question for you. is there a reason you are sticking with the IFI system for this project other then it’s simplicity? there are many other micro controllers that handle I2C bus along with many other communication standards.
I have worked on a similar system for the DARPA grand challenge team i am on and it might open up the possibilities of what you are capable of, but this all depends on your time, budget, and goals for the project.
I think the reason our mentor is set on using the IFI controller is because he hopes to implement whatever we accomplish this summer into future Team 229 robots. In addition to working towards autonomy, our objective along the way is to refine the current code that the team is using, mainly because it lacks modularity. Once we have better code working for normal joystick operation, we put in sensors to collect data as we drive the vehicle, which is where we are now. Once the sensors are working effectively, we can start on the autonomy aspects. In then end, our work will be good experience under our belts and a more organized batch of code for the team.
Stephen Yanczura (195) on these boards may be of some help. He is implementing a ultra sonic range finder in a Car/Truck Back-up Collision protection system for his PLTW senior project. I’m pretty sure he’s using a basic stamp to run the system.
Since Asycronous serial is relatively easy to implement on the RC, what I would do is setup an Async. Serial connection to another PIC, (a 16F would do) and have that be the master for an I2C bus, along with providing a few more analog inputs, and GPIOs. A 16F873 or 16F876 has both an USART and a MSSP (Master Synchonous Serial Port) as opposes to a plain 'ol Synchonous Serial Port. If you don’t want anything other than the Serial-I2C bridge, then you could have it simply get a byte from serial, output that, and then when it recieves a byte, it sends that back over serial, though you may want to add some control features to the bridge so you can do exactly what you want to.
But check the 18F8520 datasheet first, if your lucky there may be more than one SSP module, and if you are really lucky, those IO pins on the second SSP will be on the digitial-IO header.
Thanks for the advice.
Getting a second PIC to be the I2C master is what we decided to do. We ordered this eval board yesterday:
That has an 18F452 onboard already and comes with a 16F877 in addition. We chose that board because the manufacturer of our ultrasonic rangefinder shows both of those as examples on their website and provides sample code for each.
One problem with the ultra sonic sensor is the wide cone of detection. For example, say there is a 3" post in front of the robot 1 meter out and then there is a wall 3 meters out. You’ll get a ping from the post and a ping from the wall. You’ll know very precisely how far out the post is and the wall, but you’ll know nothing about the width of the post. You might also want to get an IR proximity sensor like Sharp GP2D12. It has a more focused cone of detection but is not as accurate in range. If it was mounted on a servo, it could scan and define the width of the post. You would have more info to avoid the post.