Programming tricks (and former trade secrets)

[meatmanek]

Originally Posted by buddy.smith

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

Amen to that.

[efoote868]

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)

[meatmanek]

Originally Posted by efoote868

(points to meatmanek for winning out)

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.

[JimGRobot]

Great thread, there are many good ideas out there.

We talked about the remote PROG button ourselves, but never implemented it.

One thing we did for the drivers was create an "Auto Trim" button for the joysticks. You use the regular trim adjust to get them close, then push the button. This saves the current joystick positions and subtracts those values from all future readings. This is built into a joystick "class" that is part of a code library that will be released to the world this spring.

We have an automatic scoring button, as others have mentioned, and separate buttons for all of the arm preset positions. We used a potentiometer for arm position feedback, and it works well.

One other cool thing is a micro-switch on the tube gripper to automatically close the jaws with a tube is present. This makes tube pickup very quick and easy.

We wired a bunch of momentary switches across a string of resistors connected to a single joystick input on the OI, instead of using 10 digital input bits. I will be making some PC boards over summer so others can do this very easily. The code does a little math to convert the input value into a switch number; this is built into another library class.

I guess that's all for now...
Jim

[dpick1055]

Do you think you could talk more about the auto-trim button. We're having a lot of trouble keeping our joysticks in the right trim position. Or is it a closely guarded secret

[JimGRobot]

Thanks for the note, no, this one is a loosely guarded secret...

We do some strange things with the scaling of our joysticks, but the principle is the same regardless of how you do it.

Start by creating a static global variable for each joystick axis, like:

char p1_x_offset = 0;
char p1_y_offset = 0;

Any place that you normally use the raw joystick value, use the joystick value minus the offset value, like:

pwm01 = (p1_y - p1_y_offset); //used to be p1_y only

Set the offset value to the joystick value when a button is pressed:

if ( button_pressed )
p1_y_offset = p1_y;

I think you get the idea. You are better off working with integer variables to avoid overflows, and handle limit checking, then converting back to char for writing to the pwm output.

Another thing to consider is adding a button to clear the offset. If you use this method to remove a large error, remember that the offset correction will not be present when the robot is reset, and the thing might take off.

In our implementation we limit the offset value to about 6 counts...

Let me know if you have other questions.

Jim

[dpick1055]

I'm still having a little trouble understanding this. Say when your joystick is centered it gives a value of 130. If you set that to your offset and then move your joystick to 200. Wouldn't that only send you forward at a speed of 70? And then when your joystick is somewhere near 127 you would be going in reverse?

Thanks
-David

[JimGRobot]

Sorry for the confusion, what I posted earlier only works if you scale your joysticks around zero by subtracting 127 from the joystick reading, and adding 127 back in before writing to the pwm.

So, here is a tweak to my earlier post. Instead of setting the offset to the joystick value, set it to the joystick value minus 127:

p1_y_offset = p1_y - 127;

If the joystick value is 130, and you press the auto trim button, the offset will be 3. When this value is subtracted from 130, you get the null value of 127. When the joystick value is 200, you get 197, and 100 you get 97.

If the offset value is too big, it will limit the range of the joystick value. Suppose you auto trim when the joystick value is 77, the offset is -50. When the raw value of the joystick is 254, the corrected value would only be 204, and if the raw value was less than 50, the corrected value would already be limited at zero.

Play around with this a little. The principle involved is to capture the difference between the joystick's actual value when trimmed, and what you want it to be when trimmed, and apply that difference to future readings.

Jim

[dpick1055]

Oh haha now I get it. I actually scaled our joystick values too so I could use a squaring function for driving. Thanks for the help, this is definitely something our drivers will appreciate.

[6600gt]

I started in the summer but I got in working during the build season. When I started I didn't even know the difference between C and C++. Through extensive research I was able to create a kind of "master" dashboard using Visual C++ 2005. It was designed to decrease the debugging time. I also had to develop the support code on the RC to work with this application through the program port.

You can watch any 10 int values simultaneously in a list form. Just choose form two drop down lists, one picks the type of variable(pwms, analogs, D In, D out, joysticks axes, etc.) and the other one is for choosing the number, ex. pwm05, and one can watch any preprogrammed value in real time. No need to reflash just to watch a different pwm!

It also has 16 extras that can be assigned to any variable like this, e_01 = variable(reprogramming is required but its much faster that modifying multiple printfs). Call up E1 from the GUI drop down list and you get a real time stream. The RC only sends 21 bytes over the serial port every loop, yet it provides the GUI with 10 int values.

The GUI can also graph the first 2 columns, allowing one to watch the relationship between the joystick input and the pwm output as it run through his/her algorithms, for example.

Also contains a camera simulator that shows the green tracking box and red cross hair target based on the camera T packet.

Though I haven't gotten around to it yet, I am working on an "fake" OI simulator that will allow me to control the robot from the computer

It was used somewhat for debugging but the robots were never really done...

[Bomberofdoom]

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.

[Jake M]

Originally Posted by JimGRobot

Great thread, there are many good ideas out there.

We talked about the remote PROG button ourselves, but never implemented it.

One thing we did for the drivers was create an "Auto Trim" button for the joysticks. You use the regular trim adjust to get them close, then push the button. This saves the current joystick positions and subtracts those values from all future readings. This is built into a joystick "class" that is part of a code library that will be released to the world this spring.

We have an automatic scoring button, as others have mentioned, and separate buttons for all of the arm preset positions. We used a potentiometer for arm position feedback, and it works well.

One other cool thing is a micro-switch on the tube gripper to automatically close the jaws with a tube is present. This makes tube pickup very quick and easy.

We wired a bunch of momentary switches across a string of resistors connected to a single joystick input on the OI, instead of using 10 digital input bits. I will be making some PC boards over summer so others can do this very easily. The code does a little math to convert the input value into a switch number; this is built into another library class.

I guess that's all for now...
Jim

Speaking of trim, I was considering how to make a circuit that would give some kind of feedback (LED perhaps) when the voltage off of the joystick pots themselves corresponds to about 127 (about 1.82 volts, if I remember correctly) That way you could know how good your trim is, without even needing to use dashboard, or printfs. I was going to use the two weeks before competiton, and after shipping to do this. Then we learned that we had to ship the OI Board along with the robot, and all of our other joysticks are faulty in some way or another.

[Cuog]

You can use the LEDs on the OI and have them turn on when the joystick input is where you want it.(for info on this look at the bottom of default_routine() in the default code

[Dave Flowerday]

Originally Posted by JimGRobot

If the joystick value is 130, and you press the auto trim button, the offset will be 3. When this value is subtracted from 130, you get the null value of 127. When the joystick value is 200, you get 197, and 100 you get 97.

Be very careful with this. By doing this you're effectively overriding a safety feature built into the OI by IFI. That feature sets the OI outputs to 127 when the joystick is unplugged. If you have your "auto trim" set to subtract 10 (or whatever), then when a stick gets unplugged your robot will start driving.

[Jake M]

Originally Posted by Cuog

You can use the LEDs on the OI and have them turn on when the joystick input is where you want it.(for info on this look at the bottom of default_routine() in the default code

Very true, but my whole reasoning for making such a circuit is not simply to let us see when the joysticks are trimmed or aren't, it's to let us do so without using up other OI features (such as the LEDs) which we could use for other feedback, concerning the actual driving of the robot. We can only acesss 8 of them, through the joystick ports and we could easily find 8 other uses for an LED.