Programming tricks (and former trade secrets)

[JonA]

Pro-Tip: Don't use 255 as a full forward value.
With stop at 127, there are 127 effective negative numbers (0-126) and 128 effective positive numbers (128-255). Enforcing 254 as the maximum forward value allows you to easily change the sign of the number (254-n) by using the 8 bit number circle.

Pro-Tip: Use object oriented design. (And implement it that way)
Objects allow you to divide up your code based on things in real life instead of what the processor can do. It also is the easiest way to do abstraction, encapsulation and modularity in C. Even though the language (C) does not natively support objects, there are many ways to implement objects. My preferred way is to define a typedef structure with all of the members/attributes in the class and then implement functions that are prefixed with the class name that take in a pointer to the class structure. To get encapsulation put public function definitions in the header file and private function definitions in the c file.

[Snappel328]

Well, this year we made whole different .c and .h files for every part on our robot.
Arm.c
Grabber.c
Lifter.c
Drive.c

I don't know how obvious this is to anyone else, but it got quite confusing last year when we kept typing all our code in userroutines.c

[JJG13]

Blame it on hardware.

[Redneck]

Originally Posted by JJG13

Blame it on hardware.

Quite the tempting idea when, on my team at least, anyone who's not involved with programming immediately says "Blame the programmers" when something doesn't work...


One of the cool things my team did this year was use VNC when teaching the rookie programmers. As one of the experienced programmers worked on the code, the rookies could follow along by connecting to the computer remotely.

[Roger]

Quite the tempting idea when, on my team at least, anyone who's not involved with programming immediately says "Blame the programmers" when something doesn't work...

The shop was riding us pretty hard, even on stuff that was obviously their problem. I think they slowed down (but not totally stopped) when I started replying "I'll get right on it."....

"Aw gee, the arm broke again -- must be a programming error."
"I'll get right on it!"
"Pneumatics tube popped out -- programming error!"
"I'll get right on it!"

They do not want me touching anything but a keyboard....

They also slowed down when I got their #@$$^% robot to actually work

[♥♣♠♪]

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')

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.

Our code did the abstractions, but to the point where we had #define unsign(x) ((x)-127-((x)==255))
We #defined all the pwms to things like pwmL, pwmR, pwmA, etc.
The worst was when we needed to use two motors to control the wheels on the left and right. pwmL is #defined as (pwm05=pwm06)

[Adamskiy]

We did similar to the above quote of meatmanek, but scaled it from -100 to +100....lost some resolution, but it made calculations much more simple. And although we had a tank drive, we set the left thumbstick on our Xbox controller to the throttle, and the right thumbstick controlled steering. We did that after picking drivers, as one of them loves Halo and figured it would be more easy for him to control.

For our elevator, the motor that acted as the winch was a small CIM with a BaneBots gearhead/encoder on it, so we used the encoder to have set rack positions (high/med/low) that would be assigned to a single button on the Guitar Hero controller. We then had a limit switch at the bottom (load position) that would reset the encoder count to 0 to account for slight variations that would occur....obviously not the best method, but it was accurate to about an inch, so good enough since we lower the tube onto the rack to score.

[meatmanek]

I also wrote sscanf but haven't gotten a chance to use it yet. My stupid state machine based input code works well enough, so I haven't bothered to change the code to use sscanf yet.

It compiles, and it works when I test it on my linux box. Only has %c, %u, and %d at the moment, but it should be pretty easy for someone to add other stuff to it.

http://meatmanek.net/scanf.c

[Eldarion]

I created this: http://www.falconir.com/products.php

After calibrating once at our home practice field, it was literally "set it and forget it". We did not have to recalibrate once at either of the two regionals! It even handled a dim target light on the practice field.

Then we changed our arms out and autonomous broke permanently

[JBotAlan]

Originally Posted by Eldarion

After calibrating once at our home practice field, it was literally "set it and forget it". We did not have to recalibrate once at either of the two regionals! It even handled a dim target light on the practice field.

Whoaa, cool! I do wish that this was open-source, or at least a few more details were included on the website...but good job! I did consider briefly a PC with a webcam onboard--that would be much easier to deal with than a CMUcam...but I'm also starting to lose confidence in the camera module. The lens seems to distort the image horribly, and it's not a defect because it does it on 2 cameras. I don't know as if I'll ever use the CMUcam. Too complicated...

My little bit: stay SIMPLE! And make sure the basics are done first! Autonomous mode does no good if the arm control module doesn't work...I should know, I just got it done yesterday during our last build window before Waterloo. I know I can do much better next year.

JBot

[Mike]

Originally Posted by Eldarion

I created this: http://www.falconir.com/products.php

After calibrating once at our home practice field, it was literally "set it and forget it". We did not have to recalibrate once at either of the two regionals! It even handled a dim target light on the practice field.

Then we changed our arms out and autonomous broke permanently

Looks cool, but have you checked out your main open-source competition: the avrcam

[Eldarion]

Originally Posted by JBotAlan

Whoaa, cool! I do wish that this was open-source, or at least a few more details were included on the website...but good job!

If you want to, you can download the manual from the website. It offers some insight into the basic algorithms involved (adaptive image segmentation is the main one). Another featue is that the system natively uses 320x240 images, and scales the centroids down by two for output purposes. I will probably put a little more detail on the main products page; thanks for the suggestion!

I did not make this open source as I have been working on the algorithms for the past 2 1/2 years, and would like to make a little bit of profit so that I can fund my other vision systems research. It is hard to continue researching with no funds available to test ideas with! Besides, it is written for an FPGA, an FPGA which is pretty much filled up by the code. (1 million logic cells, all in use! )

The OV7620 camera module itself is not a bad module for this kind of work. I have yet to see this distortion you speak of, and I have had the oppertunity to work with 6 different OV7620 modules. Out of curiosity, did you plug both of them (one at a time, of course ) into the same CMUCam board or different CMUCam boards when you noticed the distortion?

[Eldarion]

Originally Posted by Mike

Looks cool, but have you checked out your main open-source competition: the avrcam

That's interesting, but I think it will be hard to beat the raw processing power of a dedicated FPGA. The FPGA allows me to use 320x240 resolution, over 6 times the resolution of the CMUCam or the avrcam. It does sacrifice speed a little bit, runnig at a little over 6 FPS, but I have found that to be more than adequate. The increased resolution allowed me to stably track the lights from the home zone, (and far beyond it, actually ).

It is hard to go up against an open-source project, though...

[Matt Krass]

Originally Posted by Eldarion

If you want to, you can download the manual from the website. It offers some insight into the basic algorithms involved (adaptive image segmentation is the main one). Another featue is that the system natively uses 320x240 images, and scales the centroids down by two for output purposes. I will probably put a little more detail on the main products page; thanks for the suggestion!

I did not make this open source as I have been working on the algorithms for the past 2 1/2 years, and would like to make a little bit of profit so that I can fund my other vision systems research. It is hard to continue researching with no funds available to test ideas with! Besides, it is written for an FPGA, an FPGA which is pretty much filled up by the code. (1 million logic cells, all in use! )

The OV7620 camera module itself is not a bad module for this kind of work. I have yet to see this distortion you speak of, and I have had the oppertunity to work with 6 different OV7620 modules. Out of curiosity, did you plug both of them (one at a time, of course ) into the same CMUCam board or different CMUCam boards when you noticed the distortion?

I don't mean to be rude, but I took a look at the code you provide and I must say, it's terribly disorganized and disheveled. I find it hard to navigate and poorly commented, it took me and a friend several minutes to figure out what is apparently a timeout reset of the cameras. Your project looks promising, but I think you should polish it up quite a bit more before charging such a hefty sum for it. And I'm not certain but is that full blown development board depicted in your picture actually entirely necessary? Seems like you could design your own hardware to house the device and save some money in removal of unnecessary parts.

Again I don't mean to be rude, and if I'd made a mistake in my conclusions, please forgive me, your site is somewhat sparse on details, I'll happily stand corrected if I am wrong.

[Vashts6583]

We have an accerlerating, exponentiating drive code, which means, if you slam the joysticks from center to full forward, the robot, accelerates at an increasing speed.

For controls, we have our "conditional limit" system. operator moves arm, then holds a button, which corresponds to a spider, then stops at that limit and can't move. It can go past all the other limits (except top and bottom of course), but its very convenient. Also, our limit switches were velcro-ed on, to allow for mobility and last-minute-changability.

What else did I do this year? OH YEAH! Those LEDs on the OI....I made them all have a purpose. switch 1/2 - drive forward/back for each side. switch 3/4 - arm up/down and max limit/min limit. relay 1->3 - 3 levels of spiders. Fun times.