1103 compound chain linear slide

Intelitek has fielded many inquiries about the lifting mechanism from Team 1103′s robot which won the 2010 Round UP championship. 1103 is one of the most successful VEX robot designs and lifting mechanisms ever created! No doubt there are some excellent lessons and principles in the design of the 1103 robot that could apply to Skyrise. More details on the compound chain lifting mechanism can be found on Intelitek’s Blog

They don’t explain much besides how awesome Intelitek is and why you should buy their product for skyrise. They make it sound as if the core of 1103’s lift is EasyC’s PID function.

Thanks for your kind feedback. Do you have specific questions about the lift mechanism or PID functionality?

I have few questions about programming:

In the video it is explained that the robot has fixed functions in driver control mode. The driver only clicks one to activate these features. What is the best way to do this? Do you use a counter variable? And how do you effectively insert driver control function in between these fixed functions?

Also, i can program both the lift and the base using encoder control loops separately, but it takes some effort to combine the two programs together. Is there a easier way to combine two control loop programs together in easy c?

It is very inspiring to learn that 1103 is a one mind team. It really pumped us up-- because currently only two of us are working on skyrise, and similar to round up, scoring seems so difficult in programming skills.

In addition, how did 1103 get intelitek’s sponsorship? Or do they have your sponsorship? Looks like they do. I am pretty sure a lot of us are thinking about intelitek for a very cool sponsor in VRC.

1103 no longer exists. He was high school age in 2011 so he has moved on. I am not positive on this so don’t quote me but I believe Intelitek bought the robot from him after the season ended to have a great example of VEX robot to show at their events and use to demonstrate their products.


For our robot this year we used RobotC, probably going to PROS. However, with respect to fixed driver functions, we had a couple of bots for Toss Up and had buttons on the remotes that would set certain angles/distances for the lifts to make it easier for the driver. i.e. a top button would move the lift to scoring position, a middle would move it to rail position (to knock off big balls), and a third would move it to buck floor collect position.

This made it much simpler to drive, as we only had one driver for our small bot, by hitting the button as you approached the goal and it would lift to the scoring position.

To do this, we used tasks in RobotC (although not the only way by any means to do it). Each joint had a task running that ran a P error loop. Other parts of the code could set the angle by just changing the target position, the task would manage the rest, like limiting up/down position, max current, etc…

I see many discussions for PID, but, honestly, think most of these bots will get by on P. At least to start for teaching autonomous control principles. It’s only one subtraction and a multiplication. Then move to PI if you really need accuracy, which we didn’t all year.

Our second bot had similar buttons, but it had a compound lift, so the tasks would run each joint.

The benefit to the tasks is it makes code fairly simple (although caveats) and they run “simultaneously”. You are using a task anyway, even if you use a super loop state machine in main(), because your main() is a task.

BTW, if yo are going to use tasks that share information (target position) or hardware (LCD display) make sure that you understand semaphores.

You don’t really need a semaphore to protect a single variable in ROBOTC. Use them when you need a series of statements to run in an “atomic” fashion.

The ironic thing is that the lift on Josh’s robot didn’t use PID, it’s a P loop with some magic numbers thrown to help hold it up. He did use PID for driving using line and ultrasonic sensors.

That’s correct, or else how would they still have his robot displayed at worlds, at the intelitek booth.

There has been a lot of talk about 1103 robot, which was definitely a great robot, but there are lots of other great robots out there as well. How come it seems that 1103 is the only robot (except for a few exceptions) that people discuss for ideas?

Don’t get me wrong, I still think it’s an excellent robot to talk about for ideas.

Thank you for that great and amusing response. :smiley: :smiley:

It’s not that it’s the only one. However the VEX community and competition have been so ___-bar heavy for the last few years that 1103 is one of very few robot examples of a well executed elevator.


Definitely believe you need to treat task shared global variables as “atomic” with protection also, but don’t want to hijack the thread, so I’ll bring it up under a C thread and see if ROBOTC is doing anything special to take care of the issues.

I just think that elevator lift itself is very cool in VEX. Not a lot of teams completely understand the principle until recent discussions, and except 1103 and 7702, not a lot of linear lifts having their speed and stability are revealed. When I first saw 1103’s video, I seriously thought that it was artificial intellegence. Mostly because I knew nothing about programming back then… For me, it is more than a successful lift. It is more like an icon in vex.

We haven’t forgotten about you. Your questions have been forwarded to people on the team much smarter and more capable than myself to specifically answer the question.

The code was posted on the forums back in April 2011 and is still there as far as I know. It really just runs as one big loop servicing all the various tasks to be done. Although the code was functionally successful, I have never pointed to it as the “way to do things” because, and this may be an unpopular statement, it’s not really a good example of how to write software.

Okay, darnit, so now you’ve piqued my curiosity. Are there any good examples of how to write complex software for Vex? I’ve seen plenty of little code samples, and I’ve been learning from and teaching from those, but what about when programs start to get highly loaded with sensor inputs and so forth?

Should I start a new topic to ask that question?

That’s a tough one to answer. There are two aspects I look for in good code, first I like to see good and consistent coding practices, is the code well structured, are variables and constants well named, is the code broken down into reusable modules each with a specific use, eg. drive code collected together in one file. I look for blocking functions, what happens if a sensor does not return an expected value, will the code get stuck. I’m a fan of RTOS so I like to see appropriate use of tasks which can then lead into the correct use of semaphores to protect critical sections and data structures, things like that.

Secondly, I want to see beautiful code, both beauty in the presentation of the source and beauty in it’s functionality. In my mind software development is a form of art and the author should be proud to show what he has created. Having said that, just as with traditional forms of art, there can be a certain amount of subjectivity in this area. Just because I find the use of camel case naming aesthetically pleasing, you may not. My own style jumps around quite a bit, I can look at code I wrote a couple of years ago and think it’s the worst thing I ever did. It also changes to fit the environment I’m working in, for example, if a software framework (ie. libraries provided by a development environment) uses hungarian notation for all of it’s variables then sometimes I adopt that as well.

So team 3018 released their code recently, that was pretty good.
Team 3018 TechnaPWM code

and I guess I could point to one of my own which is “ok” although starting to fall into the category of “if I did that again I would write it differently”.
Open source robot code

Thanks for the comments on coding. I never knew it had a name - CamelCase - what a great term! :slight_smile:

Actually, it is camelCase (the very first letter is lower case) and PascalCase (the first letter of each work is capitalized.

I agree that writing “good” code is definitely an art. I’ve been a software engineer for 25+ years and have seen a lot of “good” code and a lot of very, very “bad” code. Style preferences aside, good quality code is consistent, modular, concise and well documented. I should be able to look at code in just about any programming language using any coding conventions and be able to “read” the code and understand the basics of what it is doing.