Programming tricks (and former trade secrets)

[♥♣♠♪]

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

[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?

[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.

[Eldarion]

Originally Posted by Matt Krass

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.

Very good points. I did just throw together the example code for a temporary example, as I do not have an RC with me right now and so I could not clean up and test the code. I will pull it until I can clean it up and test it.

Would someone be able to direct me to a place that can handle the manufacturing and assembly of circuit boards that can handle BGA devices in small runs? At this point, I have almost zero capital, so I cannot invest in a run of 2000 boards and hope to sell them later.

I kind of rushed this product out here to "test the waters" and see if there would be any interest in a system like this. The actual system itself is very mature and stable, I am having some difficulty with the peripheral stuff, like sample IFI drivers. If you click on the "Add to Cart" link, you will see that I am not actually offering this for sale to the general public yet. (I should probably make that more clear.) What I would like is for one or two teams to be willing to test this, make sure that the manual is clear and such, that I am not overpromising, etc. before making this generally available and investing in a new board design.

You were not rude; this is my first time attempting to bring something to market and as such it is a learning experience for me. I appreciate your criticism and feel free to poke as many holes in my logic above as necessary.

Maybe we could discuss this further via the PM system so as not to tie up this thread?

Thanks again.

[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 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...