View Full Version : C coding
12-18-2007, 07:02 PM
Just wondering, for you veterans, of F.I.R.S., this is my personal first year, and I choose, to help with programming the robot, but the problem is I don't know how to program in C. So any one who can tell me how C works, or how to write it, or explain it to me, any help would be appreciated. Thanks, to all those who answer!
12-18-2007, 07:04 PM
Welcome to ChiefDelphi. Lots of friendly folk here.
Take a look at the programming section of the site:
There a bunch of stickies there about how to get started, among numerous threads about other people getting started just like you. If you have any specific questions, be sure to put them in the Programming section.
12-18-2007, 08:58 PM
I learned the basics of C outside of FIRST, which I think is much easier to understand rather than jumping into the robot right away. I was just in the same position as you (except for an offseason competition) and these are my tips to anyone just starting to program for FIRST.
http://aelinik.free.fr/c/ is the tutorial I used.
You could only do the first 10 lessons and have a basic understanding, but like everything else, the more you know, the better off you'll be. Learn as much as you can before the season starts.
During the season, remember that your main goal (assuming the game is similar to prior years) is to have the controls running so that the controls are natural to the driver. In order to do this efficiently, make sure that you understand the electrical system, as it is the core of everything you program for. Watch everything that the electrical team wires and ask as much as you can about what they are doing.
Once you have the controls "done", you should at least attempt an autonomous (again assuming that it is in this years game.) Whether you attempt to score or just set the driver up for an extra few seconds it is very effective in helping your team. Just remember to start small with your autonomous and add to it little by little until you understand everything and have a finished product.
For the specifics on how to upload code to the robot the best place would be the programming section posted above.
Remember don't be afraid to ask about anything on here, everyone here was a new member once and knows how hard it is to jump into something you have never done. Just keep working at it and you will improve.
12-18-2007, 09:14 PM
Another good idea, especially if you are new to C coding, is to try EasyC. EasyC made learning C much simpler for me, and once I understood the basics, I could still use EasyC to make more advanced codes.
12-18-2007, 09:52 PM
During the season, remember that your main goal (assuming the game is similar to prior years) is to have the controls running so that the controls are natural to the driver.
I would like to add emphasis to this point. This is probably the single most important thing for a programmer to realize. As both a programmer and a driver (among other things...) I can tell you it makes a HUGE difference in robot effectiveness. There is a common saying that the three most important things in having a successful robot are 1) Drivetrain 2) Drivetrain and 3) Drivetrain. Yet a drivetrain is useless without driver skill, so I would propose that the two most important things are 1) Drivetrain 2) Driver Practice/Skill. Good programming can take a mediocre driver and make them good, or a good driver and make them amazing. Bad programming will not enhance a driver's natural abilities, and may even make them worse. Essentially, it can take the place of practice time and make the practice the drivers do have more effective.
This doesn't only go for drive systems it applies to game piece manipulators too; case in point, in our last two matches at VCU, when we finally got our arm working using a thrown together control method we scored, I believe, one ringer (part of that was a drivetrain problem stemming from a broken wheel, but the point still stands). At Palmetto, with improved algorithms we scored 3.5 per match (this is an actual number determined from our actual matches, not inflated conjecture; however, it does not include our first two matches when loose wires kept us from being able to score. But, since our lack of scoring in those matches has nothing to do with control, more like wiring sloppiness, those matches are irrelevant to the statistic in this use).
At Battle of Baltimore, I believe we scored at least 6-7 tubes in the first quarterfinal (I don't know exactly, I don't remember that match too well. 1089, the other scorer on the alliance, was pretty much neutralized by a double-teamed defense the entire match and yet the alliance still ran out of tubes in the player station. So, we must have scored quite a few) All along our robot was the same (actually, our turret broke at BoB, so it was scoring more even partially disabled and with a new, inexperienced base driver); yet, there is a big difference between 0-1 and 6-7 tubes. All of that was control algorithms and practice. (Actually, I expect that we could probably score up to nine tubes in two minutes if our turret was working and our controls were refined just a bit more)
Anyway, the effect of good programming can be huge. My first year as a driver our programmer (this was before I learned C and became a programmer myself) wouldn't listen to my requests for control changes and such, believing them unnecessary. Don't do this. Period. Autonomous is ten to fifteen seconds (usually), and teleoperated is one-hundred and twenty seconds. Don't shortchange the driver. If the driver wants a control change, listen to them. If you think a different method might make it easier to drive, suggest it and let them try it out, but do not force a certain method upon them. Your basic goal is to (as cheesy as it sounds) make the robot and the driver work in harmony, not opposition; to make operating the robot feel to the driver as natural and easy has operating their own feet and hands. If you reach that goal, even if the robot lacks an autonomous mode of any kind, I would say you've reached the pinnacle of FIRST robot programming.
12-18-2007, 11:39 PM
If you have done any sort of programming before, learning C will be a breeze. Programming logic translate directly from language to language (usually). The only thing you need to do is get used to the syntax of the language. Control structure logic will be mostly the same. (while, for, if, etc).
By looking at the links said previously, you can get a handle of what's going on. And if you read the error messages, you'll be able to fix what's going on. (Don't forget ;s)
Like likevanoort said, you should strive to have a fluid system between the driver and the bot. But also remember that you cannot solve all mechanical problems through programming (so, it's probably a good idea to stay in the design and build development loop, motors can only take so much rigorous testing). Everything they request might not be able to be implemented (and if they aren't a programmer, they probably won't know why). Be sure to talk with the people making the requests, and make sure they are specific in their requests. I've gotten quite mad when I was only told "This doesn't feel natural" when it was a physical problem which I had been struggling with for long before they showed up, had their epiphany, and told me to fix it. In retrospect, I should have kept them in the development loop, but still. As a programmer, you shouldn't disregard all requests, but if you know right then and there they won't work, explain. If you figure out later they won't work... explain.
Try to get a basic control background going in your bot code (taking in and processing inputs, figuring out what to do with them, and then outputting). You might not be able to do specific things without a good portion of the bot first, but you should be able to get it to drive. Preseason, figure out how to use sensors, they make life much simpler (and it will show in your auton). =)
Oh, also, if your team doesn't already know, make sure they know programming takes time, and can't be shoved into a couple days of the season. The bot is nothing but a nice looking paperweight without programming.
12-20-2007, 03:18 PM
Sorry if this is in the wrong thread.
I am also looking to learn C before the seanson starts.
My question is: Is there a compiler I can download to learn C with?
Any help will be great.
12-20-2007, 04:05 PM
I use dev c++ http://www.bloodshed.net/devcpp.html
It's an IDE which comes with both C and C++ compilers, and is fairly easy to set up.
12-20-2007, 04:07 PM
I would recommend Easy C or if you are going to have a basic robot such as tank drive with a basic manipulator Mplab is pretty easy to learn the basics. It only took me about a week to learn most all the basics needed to program in regular C.
12-21-2007, 09:11 AM
I know a little easy C from programing my vex robot, not a lot.
I also am learning PASCAL in my computer science class.
Thank you for all your help.:)
12-21-2007, 09:42 AM
You can download easyC Pro at http://www.intelitekdownloads.com
and you can have a mentor e-mail us to request your team CD-Key.
If you are a 08 Rookie we can create a team key to get you started.
If you have a Vex robot can you prototype code in Vex mode to learn
how things work.
12-21-2007, 10:01 AM
Welcome to programming! I just learned how to program a few months ago, and I'm pretty good now. If you're anything like me, then you learn by a hands on example. To get started, download the robot code off of ifirobotics.com; while at IFI, download the IFI_Loader. Next you'll need MPLAB with the C18 compiler. The main program you'll program with is User_Routines.c Just look at the code and try to figure out how it works. pwm?? are the PWM outputs on the controller. 127 is center/off. Relays are H bridges, so fwd triggers one relay, and rev triggers the other relay. If you have both on or both off, whatever you are controlling will remain off. You must have a 1 and 0 or a 0 and 1 to turn something on. In robotics, you will usually leave rev at 0 and then turn fwd on and off because of the polarity of the devices. Controls are pretty simple too, it's all in user_routines.c Good luck with programming and feel free to contact me.
12-21-2007, 02:13 PM
pwm?? are the PWM outputs on the controller. 127 is center/off. Relays are H bridges, so fwd triggers one relay, and rev triggers the other relay.
Just a minor correction: The Victors translate the RC style PWM signal (~1ms-2ms pulse) into a straight duty cycle (0-100%) and direction signal for controlling the actual FETs in their H-Bridge. The Spikes are configured similarly to an H-Bridge, but use relays instead of FETs. Relays are electromechanical switches. Notice the audible click when they are actuated.
The MPLab IDE is fairly easy to set up and use from my experience. The code FIRST gives you takes a lot of the learning curve of programming micro-controllers out of the picture and allows you to code basic functionality without knowing the particulars of the device. It may seem intimidating at first because of the sheer volume of code, but once you figure out which sections you need to be concerned with you should find programming the robot controller straightforward.
vBulletin® v3.6.4, Copyright ©2000-2014, Jelsoft Enterprises Ltd.