Open Source Robot

VEX V5 General Discussion VEX Robot Showcase
1

At the beginning of February I posted a teaser for what I was calling an open source robot. This is a robot that I put together for my own use which is more complex than say a clawbot but not quite at the level of a full competition robot. The reason that I built this was so I had a test platform for the various software examples that I post as well as being able to test student code when they have problems. The original teaser thread is here.

https://vexforum.com/showpost.php?p=326386&postcount=1

At that time I had planned to release some detailed explanation of how the robot is built so that anyone who wants can copy it. I’ve realized that I’m never going to find the time to document the robot to that level of detail so I’ve decided instead to just post what I have and leave it there for now.

**Summary
**
Drive
A 4 motor drive with mecanum wheels using 393 motors set for torque. The motors directly drive the wheels. Each motor is encoded using a VEX integrated motor encoder. The drive uses the 25x25 Aluminum chassis kit as its basis.

Tower/Arm
Two 393 motors set to torque drive the arm system through an 8.33:1 compound gearbox. The arm is able to move through approximately 270 degrees. One of the motors uses an IME for feedback into the arm control software, however, as an alternative the arm is setup to allow either one or two potentiometers to be used as feedback. Limit switches are installed that are used by the software to limit movement at full forward and backward limits of travel.

Intake
The intake is currently a scoop style intake that uses two 393 motors set to torque with a 3:1 gear ratio. A quadrature encoder is used for feedback into the intake control software along with a limit switch that is used as an index for the encoder. The intake is able to move through a full 360 degrees.

Sensors
In addition to the 5 IMEs, quad encoder and limit switches, the robot is fitted with the following sensors.

Rear ultrasonic
Three line tracking with adjustable height.
Bumper switch for emergency stop or other software control.
LCD display for user input and status.
Yaw rate gyro

BOM
The full BOM for this robot, including control system, is as follows. These are the parts that you would need to order to be able to build this from scratch, I will post another BOM at some point with the quantities of each individual piece.

OSR_BOM.jpg
OSR_BOM.jpg579Ă—845 96.4 KB

You can download this as a spreadsheet from the link at the end of the post.

CAD

There are links at the end of the post to a 3D pdf file and also the Inventor database (2012). The Inventor file really needs more cleaning up, the root folder is called DemoBot and the top level assembly is HB_Full.iam. Set the project to point at DemoBot/HB_Full.ipj.

Software
A simplified version of the software is linked below, this allows driving using joystick channels 3 & 4 for forwards/backwards and strafing, buttons 8L and 8R for rotation, buttons 8U and 8D for manual arm control using PID and buttons 6U and 6D for the scoop. The arm and scoop are not synchronized in this version, however, the scoop will level if the arm is lowered too far. I will post a much more complex version after worlds.

Links.

Gallery of photos.

Inventor database (large file 45MB)

3D pdf file (even larger file, 92MB)

Excel spreadsheet for BOM

Simplified control software (needs ROBOTC V3.51 or later)

Please don’t quote this post as I linked to all the images rather than attaching them.

enjoy.

2 Likes
2

It looks like a nice setup the utilizes most all the sensors VEX has to offer. It looks like you’re running the VEXnet system. Where does the open source come into play? Correct me if im wrong, but when I hear open source I think Arduino, Raspberry Pi, PcDuino, etc.

3

Open Source does often refer to the source code of software being available but more generally (from wikipedia):

Thus, the entire design is available for anyone to use and make modifications to.

4

i understand now. If I didn’t have my robot I would make one but my setup has served me well. Will this robot be at Worlds?

5

Disregard.

I seem to be misunderstanding everything today…

6

Your answer is in jpearman’s first paragraph, where he says, “This is a robot that I put together for my own use which is more complex than say a clawbot but not quite at the level of a full competition robot. The reason that I built this was so I had a test platform for the various software examples that I post as well as being able to test student code when they have problems.”

7

The idea is that if anybody wants to make an exact copy they could. The CAD and parts list are available and also the software to make it operate. I don’t claim that it’s a very good robot, in fact with the short wheelbase it’s a bit unstable when the arm goes over to the back of the robot, that was partly deliberate as I want to work on some anti-tipping code using the accelerometer. The scoop works but my interest there was how to encode and add the index using a limit switch, I talked about that a little in this thread.

https://vexforum.com/t/absolute-encoding-using-a-limit-switch-as-an-index/22906/1

There’s no reason for this robot to be at worlds, it’s not associated with a team, I posted it up here because I can, perhaps it will inspire others to make a better version.

1 Like
8

When i hear open source, i think incorrect term. The correct therm wqould be free hardware/software.

9

“In production and development, open source is a philosophy, or pragmatic methodology that promotes free redistribution and access to an end product’s design and implementation details”

Open source can mean more than just “open source software” in this case it includes open source hardware as well as open source software (in as much as the robot control software is open source).

1 Like
10

The design looks look a great educational design. I’m in a robotics class at school and the robots are not that good or cool. I would like to see a curriculum developed with this robot. I would be glad to help with that if that is something others are interested in.

once again this Robot looks great!

11

You miss the point! Is it about freedom, or pragmatic methodology? Freedom is better than a simple pragmatic methodology! From that freedo, you can have that pragmatic methodology.

The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

These are more important than it simply being open, rather, it must be free!

12

Rather than being picky and argumentative over why he named the robot what he did, maybe you could talk about, you know, the robot?

Great work jpearman, you are a gigantic inspiration to us all! :slight_smile:

13

@swflint Are you arguing with the term open source in general, or jpearman’s use of the term in this context? The former doesn’t belong in this thread…

@jpearman:
You’ve done it again! :slight_smile: This robot is probably one of the most (if not the most) aesthetically pleasing I’ve seen yet. I like how nicely everything is contained.

Thanks very much for posting this–a lot of people I talk to seem to want some help/guidance getting started with a VEX robot that’s more advanced than the Tumbler/Protobot. I’m now going to point them in this direction.

14

Which part is not free ? Oh, I guess the part where you need to write VEX a check for $1608.63 (+tax&shipping) :slight_smile: Now lets move on.

1 Like
15

It does not have to be free to be open source. I have Arduinos which are open source but they didnt send any to me for no cost. I do really like this robot and it gives a great starting point for anyone who is just getting interested or a hobbyist.

16

I put the more complex version of the source code up on github for anyone to use.

http://jpearman.github.io/OSR_1/

This code uses some more libraries I wrote last year as well as the PidLib, gyroLib and smartMotorLib that have been published before.

driveLib
Standardized arcade and mecanum drive code.

ctlLib
Standardized joystick and button control.

These together make it possible to create simple driver control with only a few lines of code, for example.

task main()
{
    // Init smart motor control
    SmartMotorsInit();
    SmartMotorRun();

    // Init drive system with standard controls
    DriveSystemInit( Mecanum4Motor, MotorLF, MotorLB, MotorRF, MotorRB );
    DriveSystemRun();

    while(1)
        wait1Msec(10);
}

All that is needed for a macanum drive with standard joystick control.

or

task main()
{
    // Init smart motor control
    SmartMotorsInit();
    SmartMotorRun();

    // Init drive system and use Ch3 (fwd), Ch4 (strafe) and Btn8R/Btn8L (rotate)
    DriveSystemInit( Mecanum4Motor, MotorLF, MotorLB, MotorRF, MotorRB );
    DriveSystemAttachControls( Ch3, Ch4,  Btn8R, Btn8L );
    DriveSystemSetChannelScale( 2, 0.3 );
    DriveSystemRun();

    while(1)
        wait1Msec(10);
}

To use the joystick Ch3, Ch4 and two buttons for rotation with reduced speed.

pstLib
Standardized presets for lifts and intakes.

The arm on the OSR uses similar code to the driveLib code, used in conjunction with the preset library it allows this type of initialization for joystick control of the arm.

    // Arm system
    ArmSystemInit( EncArmR, MotorArmR, MotorArmL );
    ArmSystemSetLimits( 0, 3350 );
    ArmSystemSetLimitSwitches( ArmRLimitLow, ArmRLimitHigh );
    ArmSystemAddPresetPositions(    0 );
    ArmSystemAddPresetPositions(  200 );
    ArmSystemAddPresetPositions( 1000 );
    ArmSystemAddPresetPositions( 2500 );
    ArmSystemAttachControls( Ch2, Btn8U, Btn8D, Btn7U, Btn7L );
    ArmSystemRun();

The arm was initialized with two motors and one encoder for feedback. The upper and lower encoder limits were set, two limit switches attached as hard stop points, four preset positions were added at 0, 200, 1000 and 2500, some joystick and buttons were attached for control (need to see the full code to understand what they do) and then a task started to handle everything.

These libraries were developed on an ad-hoc basis as I was playing with various ideas last year, they certainly could be better and, time permitting, I may rewrite everything to be a bit more consistent (and take advantage of V3.60 that fixed a few bugs that caused certain variables to be declared short when I wanted them to be long). Anyway, browse the code and it may inspire you to come up with something even better. The code needs ROBOTC V3.55 or later, I sort of assume everyone has updated to at least V3.60 at this point so that’s all that was tested today.

1 Like
17

Thanks James, I will forward this on

18

It was suggested that I explain the last couple of lines of code in this example.

task main()
{
    // Init smart motor control
    SmartMotorsInit();
    SmartMotorRun();

    // Init drive system with standard controls
    DriveSystemInit( Mecanum4Motor, MotorLF, MotorLB, MotorRF, MotorRB );
    DriveSystemRun();

    while(1)
        wait1Msec(10);
}

This part

    while(1)
        wait1Msec(10);

The short answer is that this code spins in an infinite loop, whilst doing nothing. Well, it’s not quite that simple, the purpose is to keep the task running while constantly yielding time to other tasks. What is not apparent from this example (because it’s just to give a taste of how little code is need to use the driveLib) is that DriveSystemRun() function starts another task that checks the joystick and sends appropriate commands to the drive motors. If the main task exits then all the other tasks will stop as well. I should have commented the code as follows.

task main()
{
    // Init smart motor control
    SmartMotorsInit();
    SmartMotorRun();

    // Init drive system with standard controls
    DriveSystemInit( Mecanum4Motor, MotorLF, MotorLB, MotorRF, MotorRB );
    DriveSystemRun();

    // Keep this task alive, all work happens in the drive library
    while(1)
        {
        // Nothing to do so yield by calling wait1Msec
        wait1Msec(10);
        }
}

For the whole story on ROBOTC multi-tasking, see the series of posts in the ROBOTC programming tips thread, specifically posts 23 through 30

1 Like
19

Maybe the problem is that we are not one to one. We are currently configured with a 18 sprocket on the motor and a 12 on the wheels. What continue’s to baffle us is that one of the three was running great. We got 7 two minute game conditions without a hitch.

I’ve placed two of the drive train motors and two lift and intake motors on ports 2,3,4 and 5 and the other side of the machine on ports 6,7,8 and 9.