Hello, teams! I am the programming captain of team 245, the Adambots. My team and I have been working for a very long time in doing a few ideas for robot programming that are a bit out there. We made a makefile and a makefile generator (configure.py) for WINE so that teams that were interested in using Linux could flash code onto the FRC.
Last year, we began development on a coprocessor project. It was inspired by work done in kinematics the previous year that simply didn’t turn out due to the tedium of using trig functions in C. (Yes, we know, lookup tables, thank you). A coprocessor is another computer that does the processing instead of the Microchip. This is a great way to get around many limitations of the Microchip, as almost any coprocessor has more processing power than the Microchip (on our Gumstix coprocessor last year, we ran 5 independent PID loops without any slowdown or overhead!).
Having tested our code last year, we have decided that it is finally time to release it to the public. Now anyone can try their own coprocessor on for size.
The coprocessor is very easy to test. Simply hook any Linux machine to your FRC Controller through the Serial Port (on the coprocessor side) and the Program Port (on the FRC Side). Then, you can flash the FRC with our prewritten code to turn it essentially into a hub and run our python script on your coprocessor. The robot will then be running off of your machine!
Skippable: The Short Details-
*Our coprocessor solution turns the Microchip 18F8722 into a dummy. All it does is sends and recieves signals such as PWMs and radio data to the coprocessor. The coprocessor then does all important processing on this information and spits the output back to the 18F8722. The code on the FRC is a stripped-down version of the default code that communicates through the program port with Kevin Watson’s serial code. The code on the coprocessor was written from scratch and uses python libraries, due to the ease of programming, and just because we like python. For reference: With some work, the coprocessor infrastructure that we created could interface with many languages. That is, you could be programming in whatever language you want, although we haven’t written that code for you. *
Yes other processors are legal as long as they pass the cost accounting rules(under $200 for any electronic component). I believe they used a GumStix<www.gumstix.com>.
Yes, we specifically used a gumstix last year. It is a bit fragile perhaps for robot use. We are still deciding whether or not we will use gumstix or MicroATX (Just a regular small motherboard) this year.
Because we customized a version of Linux to put it on there, we got boot time to around six seconds, I believe. Also, I forgot to respond to the earlier question.
Yes! Coprocessors are 100% FIRST legal so long as each individual component costs no more than $200.
This is a really great system. Our team tried to utilize something similar with the gumstix, but ultimately we ran into too many problems to actually get it off the ground (only one person really could work with it and wasn’t in the greatest of health).
Having a nice code base to turn the PIC18 into a dummy for communication with the “master” gumstix (two master controllers are better than one ;]) is a great way to help teams get started with implementing a coprocessor solution. I’ll check more into this tomorrow, thanks for the information!
Samuel H - The bzr/kickoff-polish/ directory is not actually empty. It is a Bazaar branch. In order for you to get the code, you must first download Bazaar (a version control system that we have found to be incredibly useful {and I use all the time in personal applications}). Bazaar can be found at http://bazaar-vcs.org/.
Then, simply go to whatever directory you want to put our code into and use the command
I plan to get working with this some starting tomorrow. I’m hoping that with the great boost that 245 is offering I will have some nice modules completed and available for later usage. Good luck everyone.
For reference, soon some changes will be made to the code to protect some intellectual property. We’re all in this together, after all. Once I make these changes, I will alert you all. There should be no significant changes in functionality.
Thank you all for being so patient.
(Note: The encoder modules are very old, and I haven’t looked at them in a while. Use at your own risk, although I’d be more than willing to give you some support!)
I couldn’t find the actual python code anywhere online…
We have been able to set up the PID module for the power to each motor. The joysticks decide the value to be reached and the pwm values change until that value is reached.
Our next task is how to use a velocity target value and connect that to the motor output (based on the error velocity value).
We plan on doing this using potentiometers to determine the velocity…can anyone help us on somehow reaching the target velocity by altering the pwm output on the motors?
I’ll scour around for some of the old encoder modules, although I don’t recommend you use them just yet.
You intend to use potentiometers to figure out velocity? I would recommend that you use encoders to control velocity, as potentiometers deal more with position. However, if you would still like to use potentiometers, Post again and I can walk you through code to do so.
Also, for reference, that application of PID is not terribly useful in any real application, although it is fine to test that PID functions. This is because to use a PID loop here is to match joystick output to voltage, which is already perfectly responsive. To add a PID loop only lowers this responsiveness. A more appropriate use of PID would be to match joystick input to velocity output on the motors given by encoders. In this way, you could move the joystick to a position to attain a given velocity, meaning even if there is some resistance against your robot, the PID loop would compensate for it (less driver control).
We decided to match the joystick to the voltage only temporarily to test the PID loop, and until we had a way of measuring the velocity of the wheels. Our main problem is this:
Once we have a set velocity based on the joystick, by how much do we increment the pwm to each motor to reach this velocity? The PID loop will tell us the error in the velocity and the correction value in terms of velocity right? How do we translate this in terms of change in pwm to each motor?
*