Programming tricks (and former trade secrets)

[Alan Anderson]

Now that the robots are on their way to their respective drayage, I'd like to hear about some of the innovative, clever, or just plain cute programming features that teams came up with this year. Did you implement a particularly elegant control system? Did you manage to make the driver's job trivial this year? I understand if you want to keep things mysterious for a few weeks, but please consider adding to the thread once you've demonstrated your robot in competition.

Here are a few novel things the TechnoKats did this year.

• The programmers figured out how to be lazy and not have to physically reach into the robot and push the PROG button in order to load new software. With a single wire connected between a digital output and the external PROG pin, the robot can push its own button. We have it programmed to set the output low when the letter 'p' is received on the program serial port.
• Since the team managed to build a second robot with a fully-functioning appendage, we needed to keep track of two separate sets of PID control constants. That was enough of a push to get us to adapt Kevin Watson's EEPROM-based configuration code for our use. With a special "tuning box" plugged in to one of the OI ports, we can adjust the constants on the fly, and then save them to EEPROM. No more recompiling just to accomodate a slightly lighter or heavier bit of hardware!
• Since we already had the necessary EEPROM framework in place, we also gave the operators "presets" that they can store and recall at will.

Anyone else feel like sharing?

[Rob2713g]

Our programming team created a 2 joystick drive for mecanums, which provides much more control than the common single joystick drive.

[Bharat Nain]

We renamed and (re)defined everything in our program making everything VERY modular and easy to read. Some of these things can even be copied, pasted and tuned for many other robots.

[meatmanek]

Along the lines of renaming things...

Our team uses an 'abstraction layer' which consists of a bunch of global variables and two functions: abstractIn() and abstractOut().
The global variables are things like driveLeft, driveRight, joyL, joyR, etc.
Our abstraction code takes renaming it one step farther. Rather than using the 0-255 scale where 127 means stop, we shift it down 128 (signed char, rather than unsigned), and we also invert motors where it makes sense. (one side of the drivetrain, any appendages where the motor is 'backwards')

This helps make our code MUCH more readable and configurable, and makes algorithms a bit simpler.

Another trick we did this year was one big state machine for teleoperated mode. In the past, our robot has been nothing more than a glorified remote control car. This year, our robot knows what it's supposed to be doing, with a set of states for each objective, and so the drivers are freed to think more about the game, rather than the robot.

[benhulett]

Designed a "level code" to make the arm operator's job 10x easier
Ex: you push this button, the arm moves to level 2 and sets the motor to neutral (until you push another button)
We can have it working with and without an encoder

[Cuog]

I made the robot fight gravity actually it was a code w/ the accelerometer that would try and push back, but with no testing it made driving impossible because I got the direction that it corrects wrong, so it fights itself, oops

In the way of useful things I did this year, I got our omniwheel bot to drive mostly straight(still have to tune that) using a gyro chip that hopefully will self calibrate. The drive code also very nicely allows us to drive it FPS style with one joystick for translation and the x axis on the other for spin.

[Robo_Coyote]

Our programer made our lift motor a 20000 position servo with a program that state level 1 is between position 5000, and 7500 and so forth. He also got most of our operational programing done first time ever for that.

[Kevin Watson]

I've been working on a library that will work with version 3.0 of the C18 compiler. I'm almost there...

-Kevin

[meatmanek]

Originally Posted by Cuog

I made the robot fight gravity actually it was a code w/ the accelerometer that would try and push back, but with no testing it made driving impossible because I got the direction that it corrects wrong, so it fights itself, oops

In the way of useful things I did this year, I got our omniwheel bot to drive mostly straight(still have to tune that) using a gyro chip that hopefully will self calibrate. The drive code also very nicely allows us to drive it FPS style with one joystick for translation and the x axis on the other for spin.

Last year, we used mecanum wheels to drive our robot. I played with some code using the YRG to make the joystick always be relative to the driver, rather than the robot. Push forward on the joystick, and it goes down the field, push right on the joystick, and it goes right on the field, twist the joystick and the robot will turn. Unfortunately, our drivetrain was too fast, capable of turning about one revolution per second (without the rest of the robot, I don't know what it was with all of that). The YRG was limited to 80 degrees per second. I wanted to get another gyro, but we never followed through on that.

If you're using a DAA to control an arm, you might consider using a quadrature encoder. DAAs are prone to drift, and aren't very accurate when you integrate them twice to get position.

[Cuog]

I had to slow down the speed of our spin because at full speed the spin is roughly 2 rev/sec, not drivable at all, the YRG is on there to adjust the spin so that we spin reliably and dont over spin.

the DAA was intended to push back against another robot when they bump us, sadly it ended up fighting itself so thats something I'm going to try and fix on thursday otherwise it will just be scrapped.

[kitscuzz]

We were just proud to get so many systems to work together:

The adc is now working in conjunction with the gyro code to integrate 400 times a second (which needs a long long, but we made it reset every 360 degrees to prevent overflow).

I'm soon to add in the Dual Axis Accelerometer to account for tilt so that I can kill the gyro integration if the tilt exceeds a certain angle.

We used the eeprom and trig funtions in order to make field-oriented holonomic (which I almost had working perfectly when they tore it out of my hands to ship it... hardware team didn't get the robot done until yesterday... sadness). And we're working on sticking the gyro bias into the eeprom as well in order to prevent recalculation every time you turn on the robot.

The encoder (a banner IR sensor) counts the number of times a wheel turns in order to keep track of the height of the arm.

And we were going to do the camera, but the autonomous ended up being so enormous, that we had to abandon it. We made the whole thing with multiple light tracking, and we had a plan, but it was just too difficult to get it running straight without a working Dual Axis Accelerometer and perfect camera code that we had to give up. 15 seconds is not very much time.

Although it's not particularly useful code, anyone who wants it can PM me for the accelerometer and gyro code we made. It's a little too processor intensive if your planning on doing the camera, but it can integrate up to 6200 times a second to keep really close track of the gyro angle or velocity. For whatever reason, we couldn't seem to make it keep track of the velocity very well, but we cut the error on the angle down to .5 degrees for a full spin on the bot.

[JBotAlan]

I wrote a two-shot arm control module--if the arm's potentiometer value is more than a certain amount, it will send full speed out to that joint, otherwise, it will send a slower value until it is within a "deadband". Unfortunately, I didn't get as much testing in as I wanted to because the gear that meshes with the worm-tooth kept losing teeth and the robot dentist got more and more agitated as the night went on...I nicknamed our 'bot "gear muncher" because I broke 3 gears yesterday and 2 the day before. Little brass teeth are littering the floor. Not Good. We have some hardened steel gears coming, though.

I also have an EEPROM solution in place--you move the arm to where you want it, then hold a button combo on the handheld and the robot saves that position to the EEPROM and will recall it when that button is pressed.

Of course, our code still isn't done. It's...functional...which is an improvement over last year.

JBot

[kitscuzz]

Originally Posted by JBotAlan

I also have an EEPROM solution in place--you move the arm to where you want it, then hold a button combo on the handheld and the robot saves that position to the EEPROM and will recall it when that button is pressed.

JBot

Hey, that's an excellent idea! Well now I have a solution for resetting the arm position before each match. The banner IR encoder solution I talked about is arbitrary, this will keep it in place.

[kaszeta]

Originally Posted by meatmanek

Our team uses an 'abstraction layer' which consists of a bunch of global variables and two functions: abstractIn() and abstractOut().
The global variables are things like driveLeft, driveRight, joyL, joyR, etc.
Our abstraction code takes renaming it one step farther. Rather than using the 0-255 scale where 127 means stop, we shift it down 128 (signed char, rather than unsigned), and we also invert motors where it makes sense. (one side of the drivetrain, any appendages where the motor is 'backwards')

We've done this for several years. We have one set of functions that maps user inputs into various abstract state variables (speed and heading, for example, arm angle, etc), and a second set of functions that maps these state variables into pwms and relay settings. This is nice, since it means that the autonomous modes are programmed the same way.

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.

[kaszeta]

Originally Posted by meatmanek

Last year, we used mecanum wheels to drive our robot. I played with some code using the YRG to make the joystick always be relative to the driver, rather than the robot. Push forward on the joystick, and it goes down the field, push right on the joystick, and it goes right on the field, twist the joystick and the robot will turn. Unfortunately, our drivetrain was too fast, capable of turning about one revolution per second (without the rest of the robot, I don't know what it was with all of that). The YRG was limited to 80 degrees per second. I wanted to get another gyro, but we never followed through on that.

Get the ADXRS300EB gyro (or the Sparkfun breakout board equivalent, which is easier to wire), and you won't regret it. Last year we made a prototype holonomic drive, and it was way fun to drive, and user-centric coordinates allow you to easily do things like spin while driving.