|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools |
Rating:
|
Display Modes |
|
|
|
#1
|
||||
|
||||
|
Well, This year I was set on programming autonomous, but I am hardly sure we will have a robot that needs it
. It is 19% complete, and still in alpha stage, but I had promised myself that I would continue even though the robot is shipped (having problems trying to get the Controller to work without an OI, but I believe that that is default), and what I have now may interest some.As I said, it is VERY incomplete, and not altogether working. It is a terminal interface to the controller (mainly for debugging purposes) that eventually will replace most programming that a team would need to do (as far as autonomous and some others, PWM mappings and others will still need to be modified every now and then ).I have already integrated Kevin's Camera Processing routines, Serial IO routines, and EEPROM (still unverified, sigh) routines, and the interface is kinda cool. If you want some more info, check out the attachment. The main features are (/will be): - Easy autonomous programming by the end-user (a.k.a. the non-programmers) using the terminal interface - Easy Drive controls altering/setting using the terminal interface - QuickView info on various IO's (like pwms, DigIO, AnaIO, Battery voltage) through the terminal - On-the-fly Calculation of field placement using camera, accelerometers, gyros, IR, yada yada... - Easy autonomous programming... (wait, did I already say that?) using a (slightly) intuitive terminal interface Did I mention that all of this is through the terminal interface? Unfortunately, I haven't coded the IFI loader's interface menu yet, but HyperTerminal works absolutely fantastic for now, with auto-updating information on the fly and a much more user-friendly menu (I tried implementing a line-by-line menu; didn't work out at all, updated information tended to cause the menu to disappear rather quickly, yada yada.) Still in Beta! If anyone could assist writing autonomous action code (read about it in the documentation) please PM me! BTW, does anyone have a memory free count for the default code? I would like to post how much memory my "add-on" will take, and I forgot .Also, I would like to add code for things like Gyros and Accelerometers, but since We do not have such things (working or not) I cannot possibly program for it. At the current time almost none of my program uses timers (forgot how, :stupidme and If I cannot use data from sensors, the code would be blind. anyways...Like I said, 19% complete, still need LOTS of code, see attachment for more info. Catch you all later! ![]() |
|
#2
|
||||
|
||||
|
Re: Programming tricks (and former trade secrets)
Quote:
|
|
#3
|
|||
|
|||
|
Re: Programming tricks (and former trade secrets)
Hm... We used mecanum wheels. We coded the usual translation routines, then used a third axis on the joystick (twist) for rotation.
We didn't design it this way, but what emerged was that driving in circular arcs was VERY easy, which the drivers love because of the design of the rack. Other features...the arm's motion is limited by a pot, but if the pot fails (becomes disconnected), the arm will still be usable. I wish I could say we thought of this BEFORE the pot failed (wiring problem).... I'd love to restructure the First code...I really don't like their coding style, but 6 weeks isn't enough time for that, so making the robot work was priority #1 --buddy |
|
#4
|
|||
|
|||
|
Re: Programming tricks (and former trade secrets)
One of the neater things we did this year has to do with our arm. We use a pot to get position feedback about the location of the arm. Out of the 0-1023 range the pot can give us, we only use about 250. On every activation of the robot, the contoller reads the initial pot value, and makes it the temporary zero for the match. Hence, even if the pot slips between matches, or moves, or we have to change it, it still works.
|
|
#5
|
|||
|
|||
|
Re: Programming tricks (and former trade secrets)
Amen to that.
|
|
#6
|
|||
|
|||
|
Re: Programming tricks (and former trade secrets)
Quote:
|
|
#7
|
|||
|
|||
|
Re: Programming tricks (and former trade secrets)
I implemented a globals.h file to handle all variables that need to be accessed across multiple .c files, and a handy macro that can make all these declarations in a single statement, which makes things easy if you need to add more variables, or change the name of an existing one.
Code:
/******************************************************************************** * FILE NAME: globals.h * * DESCRIPTION: * This file contains the definitions of global variables, used by multiple * modules in the robot program. A macro is used to resolve the separate * definition of each variable, in each module. Simply include this file in * all of your C Source files, but also make sure to insert the line * #define MAIN_C * in your main.c file. * ********************************************************************************/ /* GLOBAL_VAR(Type, Name, Initial Value); */ #ifdef MAIN_C #define GLOBAL_VAR(t, n, v) t n = v #else #define GLOBAL_VAR(t, n, v) extern t n #endif /* example */ GLOBAL_VAR(unsigned char, test, 0); Code:
#define drt_hand_piston_fwd relay2_fwd
#define drt_hand_piston_rev relay2_rev
...
#define RELAY_FWD 1
#define RELAY_OFF 0
#define RELAY_REV -1
#define Generate_Relay(r)\
{\
r##_fwd = 0;\
r##_rev = 0;\
if(r == 1)\
r##_fwd = 1;\
else if(r == -1)\
r##_rev = 1;\
}
...
GLOBAL_VAR(char, drt_hand_piston, 0);
...
Generate_Relay(drt_hand_piston);
|
|
#8
|
|||||
|
|||||
|
Re: Programming tricks (and former trade secrets)
Things not implemented in team 2230's robot code:
We wanted to make a very simplified control system with the gyro in order to make the robot move from the drivers prespective. I.E: You need your robot to go left from your position. You turn the joystick to the left, the robot will turn left untill it reaches it's angle and will continue in that direction as long as the joystick is held in that direction. New joystick direction? The robot will stop and turn to the new direction and continue. Of course, that was not implemented, because we lost our gyro a single day after we received it(about 2 weeks before the shipping of the robot instead of 4). Things implemented - Automated arm levels. Every push of the joystick's wheel in the certian direction will raise the arm of the robot to the direction and certain level we defined(1st level, the chute, 2nd level etc...). - Automated platform lowering and manual raising. The platforms for the robots are automaticly lowered. With a special saftey press-code on the joystick, only after the driver is sure he wants to lower his platforms in the place he is he will lower it. At the end of the game, after the saftey inspectors go over the robot making sure the raising of the platforms won't damage anything, the platforms are raised slowly and manualy. -Automatic jack system. With the help of the trusty acclerometer, we've been able to make sure all jacks attempt to level eachother while progressing to the height while trying to keep all motors at thier max speed in order to maintain stabilty. Things hoping to be implmented - A complete autonomous mode. In the "practice" day, we'll try to get values from the arena and define the certain values we need to make an autonomous mode that will use the values of the position the robot starts, the number of lights it should look for and which way to go in order to set the robot in the direction of the defined number of lights. That's pretty much it. ![]() |
|
#9
|
||||
|
||||
|
Re: Programming tricks (and former trade secrets)
we worked on writing a new scripting language for autonomous mode.
so easy to write new logic I had mechanical people writing some stuff. |
|
#10
|
||||
|
||||
|
Re: Programming tricks (and former trade secrets)
Quote:
That's exactly what we were thinking of doing! But we never got around to actually putting the code in. Pretty much the only "trick" we put in there was an acceleration code, which would only let the motor value go up by 5 every loop. I believe there was a thread about that sorta thing... (http://www.chiefdelphi.com/forums/sh...520#post572520) |
|
#11
|
|||
|
|||
|
Re: Programming tricks (and former trade secrets)
this year we used 2 SVN servers to keep track of all of our code, and changes. One was for the inexperienced programmers, so that they could learn, and the other was for the final versions of the code (code that would always compile, instead of having to track down all the convention mistakes and what not). Helped so that more than 1 person could work on the code at once, and allowed for much faster programming.
Also, for 868's state machine, we had multiple people write their own version, so that we could easily take the best of them. (points to meatmanek for winning out) |
|
#12
|
|||
|
|||
|
Re: Programming tricks (and former trade secrets)
It's amazing how excessively commenting your code (read: Just about every line that isn't a duplicate of a previous line) can bring about the appearance of quality.
|
|
#13
|
||||
|
||||
|
Re: Programming tricks (and former trade secrets)
Quote:
I also got the students to use a rigorously defined finite state machine for the autonomous mode this year, and it really paid off. We gained a lot of autonomous functionality without a lot of extra effort, and it's a lot more debuggable. Otherwise, the other neat innovation was using large numbers of infrared sensors to do a lot of our work (especially in autonomous). They also give us a "virtual bumper" that can keep us from hitting things we don't want to. |
|
#14
|
|||||
|
|||||
|
Re: Programming tricks (and former trade secrets)
We do much the same thing, but our abstraction layer is only two global variables. One is a structure full of commands like desired position or turn rate, and the other is a structure full of feedback like manipulator position or current heading. Keeping things together like that helps keep the code more understandable, I think.
|
|
#15
|
||||
|
||||
|
Re: Programming tricks (and former trade secrets)
Our biggest difference this year is using the USB chicklet with an XBox controller to control our arm. The little chicklet lets us use 12 buttons by using two analog ports along with digital.
Other than that, we have switches that we set before each match and read so that we can choose between up to sixteen different autonomous modes. It's really too bad that the only one programmed is "Do Nothing"... |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Former FIRST student and mentor dies in a tragic rocket attack in Iraq today. | Munkaboo | General Forum | 48 | 19-04-2005 12:21 |
| Off-season competetions and former teams | Venkatesh | Off-Season Events | 5 | 10-12-2004 17:23 |
| Harry Potter and the Chamber of Secrets | Ryan Dognaux | Chit-Chat | 33 | 01-12-2002 19:57 |
| scouting tips and tricks | Rick | Scouting | 1 | 08-01-2002 00:52 |