Having just completed this season’s robot, I have developed a high level of interest in making a custom circuit board coprocessor to process sensor inputs from a robot so that, via a simple RS-232, TTL, or whatever connection (maybe even USB or RS-485), a master processor could poll this coprocessor and get back the output of multiple PID loops or navigation software. I really have no end goal except that the coprocessor would process sensor inputs from a CMUcam, encoders, potentiometers, or just about any other sensor and provide an output to a master processor. Now, I have read up on the Adambots solution to this idea, which was to use a gumstix computer. I have also considered using a mini-ITX motherboard. The only problems I see with these solutions are 1) I have no interest in learning linux just for a coprocessor 2) I’m not convinced an RTOS (realtime operating system) is really necessary 3) Even with an ITX motherboard or a gumstix computer I would need another solution to get sensor inputs.
All that said, I have begun to look at AVR microprocessors. Gumstix sells a $49 robostix board which sports an AVR ATmega128 chip and enough IO ports to handle all the sensors I am thinking of using.
I have just a few questions:
-Is there a better approach to this idea? Is an AVR solution better than PIC?
-Is it worth it to instead build the entire custom circuit rather than buy something like the robostix?
We have a pic on a custom circuit board acting as a coprocessor. It communicates with the robot controller by way of the ttl serial port.
An RTOS isn’t necessary, for one, it will have significant amounts of overhead and will require an auxiliary board to handle sensors, etc(Gumstix implementation). This further contributes to overhead. While any modern x86 style processor has the processing power to overcome such overhead - it still has significant amounts of I/O latency,
A microcontroller, such as the PIC, is likely a better solution, while far less powerful, it requires far less overhead, and because of this, can work with much lower latency.
We have a hardware counter chip to read in the quadrature encoders, this is probably not needed, but reduces overhead even more. A mentor designed and fabricated for us, and they have been incredibly useful so far.
I would suggest going with a PIC or AVR over an embedded linux processor, especially if you don’t have any experience with them. If you have never used a PIC or AVR before (other than in the robot controller) I would suggest using an AVR. They have a more powerful instruction set, up to 20MIPS vs 10MIPS for most PICs, and all the software development tools are freely available (including C compilers). They also have extensive open source libraries. You can make your own programmer for under $10 by hacking a parallel cable or you can get the AVRISP mkII programmer for $36 bucks. I have used both without too much trouble. If you don’t want to mess with making PCBs, you can just buy a dev board, but I would recommend designing your own because it will give you a lot more flexibility.
One of the biggest advantages, however, of the PIC8722 over an Atmel AVR is that they are completely compatible with the Robot Controllers, being able to run the exact same software.
They utilize the exact same IDE and compiler, and this familiar interface can be very helpful. Our boards have an interface for an ICD2 compatible debugger, and this is incredibly helpful.
I’m not sure if something similar to the MPLAB + mcc18 + ICD2 combination exists for the AVR.
What an ICD2 does is this - it allows you to specify a breakpoint in the C code, and will stop the program from running as it gets there. At that point, It can list out the status of all variables and registers, and at the same time, allow you to step forward or backwards, and MPLAB will display the steps on screen - in C. You can order it to move through the steps slowly, and MPLAB will animate the parts of your code where the program is currently executing. This has been incredibly helpful in our development process.
The fact the FIRST board lacks a jack for an ICD2 annoys me - but being able to test code out on our custom circuit board then port it to the RC is one reason why we chose to use a PIC. (The other reason was the mentor designing these things is very familiar with pics)
If you need any more details, simply ask. Our custom boards can interface with a radio, and has headers for PWM outputs along with Digital/Analog inputs and an integrated breadboard. We plan to use them for other projects after this season is over.
If you would like to see a circuitboard, please drop by our pit at Oregon Regional.
Debugging - keep in mind, there is no port for a debugger on the FRC controller - and printf is a poor substitute for a debugger. Even if you intend to write code for the RC only, it’s a good idea to test such code on the circuit board first, so it can be debugged there, and then utilized on the RC later.
The second thing is to offload processor intensive tasks such as keeping track of the encoder count to another processor. While generally, encoders shouldn’t make a significant difference, if you use high pulse per revolution encoders and a very fast wheel, you can easily end up with the red light of death.
we do basically the same thing as 114 (if I understood all your technical lingo properly,) although with a different board.
We also worked over the summer with AVRs and had our programming student build his own micro processor board, it worked very effectively for what we were using it for. Even got it to work controlling some Victors via PWMs (not for competition, I know it’s against the rules )
We use a smaller PIC (18F252) to interface to the SRF04 Ultrasonic module - handles the trigger/echo timing and converts to a digital input. I find it amusing that the SRF04 uses a small PIC to generate the ultrasonic pulses in response to the trigger, generating the echo pulse, which we measure with a 2nd PIC, so we can send the data to the PIC in the RC.
whether you are using a PIC18F722, AVR or another microcontroller, your C code will be very similar, the PIN names might change but if your willing to learn another micocontroller’s “.h” file , then don’t worry about porting to a new microcontroller. More importantly, you should consider the processing speed performance and the available peripherals (CAN, I2C…etc) and the I/O options (ADC, DAC …etc)
IFI Robotics is protecting their design by not bussing out the ICD2, you could possibly build a complete replica of the RC if they bussed out an ICD2.
I agree not having an ICD2 port on the RC is annoying. The good news is, most of the other hobby micro-controller companies open their JTAG ports and source code.
All right. So I looked at the documentation for the gumstix robostix and the number of external interrupts that are connected to pins is to small. Thus, I have decided to use a MEGA AVR (don’t know which one yet). This means we will have to build our own circuit board. Does anyone have suggestions for how to go about designing, building, or implementing a board? Should I go for perfboard or order a PCB per a design that I make? Is there a free CAD software I should use? What about outputs from the board: should I provide other connections than just the no-brained TTL/RS232? I really want to have a prototpe that might work with next year’s control system.
Any suggestions/comments are very much appreciated! I so intend to document the prototyping project and make it nearly entirely open-source so other teams can learn to do this too…
Altium is available for free to all teams. I use it for my day job as an electrical engineer. You would be very hard pressed to find something better (in my humble opinion), even if you were to pay.
I understand this point - but I believe certain differences do exist in the way the processors handle things such as interrupts. At the same time, for those of us who tend to use things such as timers or counters, relearning how can be slightly annoying. For the students involved, its often nice to have consistency between the co processor and the main processor.
As for IFI - why? It’s not like the board design is complicated nor ingenious. It simply a PIC with some software, and a master processor which has a relay to control the outputs of the user processor.
Our team has a similar board which was designed by a mentor to have almost identical capabilities to the IFI board, it has PWM headers along with analog/digital in/out abilities. At the same time, it has other robotics specific features such as a 2 channel counter for quadrature encoders.
This isn’t considered anything especially complex to do - nor is it unique. Even if the ICD2 header was open, and someone reversed engineered it, people would be required to purchase and use the KOP boards anyways, and I haven’t heard of anyone buying the RCs separately for use in other applications.
I have a feeling that they may use the i2c bus to handle communications with the modem. If this is the case and they exposed a header to connect to it, then it would be theoretically possible to interfere with this (either accidentally or intentionally). This might allow a robots output to be active while in disabled mode, which would be a large safety issue.
I would definitely suggest making a PCB over doing a perfboard because it will be more compact and reliable, not to mention look better. A perfboard may be better for your initial prototype, however. I use Eagle for making PCBs. The interface isn’t the greatest, but you get used to it. As for outputs, I would recommend having several indicator LEDs, an LCD, I2C, UART(with and without level conversion), and SPI.
I attached the schematic of the motorcontroller board from UW-Madison’s entry into the Intelligent Ground Vehicle Competition last year. This board was designed to interface between a laptop and Victor 883 motor controllers. Some of the specs: It had an ATMEGA16, now it has a 32. It has an 8 bit parallel data bus to communicate between the quadrature decoders, latched LED bar graph and LCD. It has a software controlled PWM source select so we can switch between input from an RC receiver and the AVR. It has an RS232 port for communicating with the laptop. We use avrdude to program it. If you insist on using windows, you can use AVR Studio or WinAVR. If you are interested in the board layout or software let me know.
UT-Austin also did a similar microcontroller board (designed in eagle) that interfaces to Victors 883 and a laptop using a 9S12C from technological arts. We did a serial master communication from the laptop to control PWM, encoders, sonars and various switches. If you want to see pictures of the various robots , see the IGVC photo gallery. Our documentation is not as clean as Ken’s and I don’t suggest other teams to use the 9S12 unless you’ve been trained on the architecture. We use that microcontroller in our classes and freescale donates quite a bit of the hardware.
)