View unanswered posts | View active topics It is currently Sun Sep 21, 2014 9:16 pm






Reply to topic  [ 133 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9
Endcoders better? 
Author Message
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Endcoders better?
What exactly did you change to make it from working to not working?


Sun Apr 24, 2011 7:17 pm
Profile
Novice

Joined: Mon Oct 18, 2010 9:31 pm
Posts: 86
Post Re: Endcoders better?
In Case 4... in the () i had 30. To go 30 inches.

I changed it to 15, and I get the error.


Sun Apr 24, 2011 9:28 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Endcoders better?
That's strange. I compiled the code with 15.0 in case 4. And it did not give me any problem. Try rebooting your laptop. I found sometimes RobotC behaved strangely and the problem goes away if I either close and reopen RobotC or simply reboot the computer.


Sun Apr 24, 2011 10:41 pm
Profile
Novice

Joined: Mon Oct 18, 2010 9:31 pm
Posts: 86
Post Re: Endcoders better?
I am still working on it... but here is what i have right now.


Last edited by Team2844 on Thu Oct 13, 2011 11:55 am, edited 1 time in total.



Mon Apr 25, 2011 9:54 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Endcoders better?
Just did a quick scan on your code. Here is what I found:
  • If you are not using IRGetACDir, get rid of the function. It is not doing anything and nobody is calling it.
  • I don't quite understand your autonomous probably because the comments weren't updated to reflect the action. For example, case 0 said going forward, but you are starting servo 4 and 5. I don't even know what servo 4 and 5 do.
  • In case 1, you are waiting for 500 msec but you did not do a ClearTimer(T1) in case 0. So T1 may not start with zero so your wait is not really accurate.
  • In case 4, the comment said turn right 90 degrees but the code is turning left 90 degrees.
  • In case 8, I don't understand what you are trying to do? You are doing 1.7 second timed drive, but you are waiting for g_driveEanbled in the next case. Did you forget to do a DriveSetTarget in case 8?
  • Again, case 10 and 11 is doing the same timed drive.
  • In case 12 and 13, why are you doing timed and SetArmTarget? Shouldn't SetArmTarget itself be enough?
  • From case 14 on, you keep setting motorA to 95. There is nothing wrong with it but if you are setting it to the same value, you can skip it. Just set it once in case 14 and don't touch it until you need to change it to some other value.
  • From case 14 through 36, I don't understand what you are trying to do. It seems you are rocking the bucket back and forth between 5 and 10. There is a more efficient way to do that than keep repeating the code. Do you realize the "step" varaible can go backward as well as any value you want. So you can have a count variable counting how many time you "rock" the bucket and if you are still not done, you can set step backward. For example, you can get rid of case 13 through 37 and replace it with:
    Code:
    task main()
    {
        int step = 0;
        int count = 0;

        StopTask(displayDiagnostics);
        eraseDisplay();
        initializeRobot();
        waitForStart(); // Wait for the beginning of autonomous phase.
        nMotorEncoder[motorArm] = 0;
        while (true)
        {
            GyroTask(g_Gyro);

            nxtDisplayTextLine(5, "Step=%d", step);
            switch (step)
            {
                ...
                ...
                ...
                case 13:
                    // step 3: wait to complete.
                    if ((time1[T1] > 500)&& (g_armEnabled == false))
                    {
                        // motorA to turn on.
                        motor[motorA] = 95;
                        count = 0;
                        step++;
                    }
                    break;
    //**** 1 ****
                case 14:
                    servoTarget[twist] = 5;//Turn Bucket
                    ClearTimer(T1);
                    step++;
                    break;

                case 15:
                    // step 3: wait to complete.
                    if (time1[T1] > 500)
                    {
                        step++;
                    }
                    break;
    //***** 2 *****
               case 16:
                    servoTarget[twist] = 10;//Turn Bucket
                    ClearTimer(T1);
                    step++;
                    break;

                case 17:
                    // step 3: wait to complete.
                    if (time1[T1] > 500)
                    {
                        // repeat 6 times of 1 and 2 above.
                        count++;
                        if (count < 6)
                        {
                            step -= 3;
                        }
                        else
                        {
                            step++;
                        }
                    }
                    break;

    Of course you have to renumber the subsequent case numbers.
  • Since I don't really know your autonomous routine (the comment wasn't clear on that), I can't tell you if it is doing what you want overall. But one important thing you have missed is you need to call DriveIRTask at the end of the state machine loop.


Mon Apr 25, 2011 2:34 pm
Profile
Rookie

Joined: Mon Dec 12, 2011 10:26 pm
Posts: 4
Post Re: Endcoders better?
MHTS,

I've been looking at, and now playing with, your code for this gyro sensor.

This:
Code:
  TFuncName("GyroTask");
  TLevel(TASK);
  TEnter();

  ...

  TExit();


Looks like a task/timeslice call, but it doesn't look like what's in Robot-C intrinsics. Further, I can't figure out where in your code you're defining the T* functions/macros, and I can't grep that pattern in my Robot-C distribution. Is this a v2.xx vs v3.04 issue? If not, where am I getting lost in the weeds?

Thanks!


Mon Dec 12, 2011 10:30 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Endcoders better?
kz2zx wrote:
MHTS,

I've been looking at, and now playing with, your code for this gyro sensor.

This:
Code:
  TFuncName("GyroTask");
  TLevel(TASK);
  TEnter();

  ...

  TExit();


Looks like a task/timeslice call, but it doesn't look like what's in Robot-C intrinsics. Further, I can't figure out where in your code you're defining the T* functions/macros, and I can't grep that pattern in my Robot-C distribution. Is this a v2.xx vs v3.04 issue? If not, where am I getting lost in the weeds?

Thanks!

Don't worry about the T* functions. They are debug tracing macros. You can safely remove them if you are making a copy of the gyro module. If you want to use it unchanged, the debug tracing macros are defined in dbgtrace.h. Here is a link to the latest version.
http://proj.titanrobotics.net/hg/Ftc/20 ... 857/ftclib

Our library doesn't really use task. They are implementing cooperative multi-tasking (i.e. meaning you have to call the task yourself). In order to use the gyro module unchanged, you need to do the following:
- If your gyro is connected to a HiTechnic Sensor MUX instead of directly to the NXT, you need to include HTSMUX-driver.h from Xander's driver suite.
- Include trcdef.h from our library. This defines a lot of the useful macros and constants.
- Include dbgtrace.h from our library. This defines all the debug tracing macros.
- Include the gyro.h module from our library.
- Declare a global variable g_Gyro object in your code.
- In your RobotInit code, initialize the g_Gyro object.
- In your robot main loop, make a call to GyroTask.
Code:
#include "..\RobotCDrivers\drivers\HTSMUX-driver.h"    //Don't need this if you are not using Sensor MUX.
#include "JoystickDriver.c"
#include "..\ftclib\trcdefs.h"
#include "..\ftclib\dbgtrace.h"
#include "..\ftclib\gyro.h"

GYRO g_Gyro;

void RobotInit()
{
    GyroInit(g_Gyro, gyroSensor);
//if your gyro is connected to a SensorMUX then, GyroInit should be:
//  GyroInit(g_Gyro, gyroSensor, GYROF_HTSMUX);
    ....
    ....
}

task main()
{
    RobotInit();
    waitForStart();
    while (true)
    {
        getJoystickSettings();
        GyroTask(g_Gyro);
        ....
        ....
        ....
    }
}


Mon Dec 12, 2011 10:59 pm
Profile
Rookie

Joined: Mon Dec 12, 2011 10:26 pm
Posts: 4
Post Re: Endcoders better?
Thanks! All is clear. Thank you for posting your code, it'll save us some time which is in short supply now :)


Mon Dec 12, 2011 11:24 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Endcoders better?
You are welcome. Glad to help.


Mon Dec 12, 2011 11:29 pm
Profile
Rookie

Joined: Mon Dec 12, 2011 10:26 pm
Posts: 4
Post Re: Endcoders better?
MHTS,

1 Simulink model and a little trial-error for our PID Kp/Kd constants, and we have a very working robot!

I kept telling the kids to not worry about the misalignment and stresses on the frame as they mounted superstructure/payload to the bus (this year's robot has an open front to collect racquetballs), that we'd 'fix it in software'.

We look like geniuses to the kids now - first demo run without straight-line gyro, and the robot drifted right about 1" in 24". Press the magic button (demo code) and the robot drifted not-at-all.

Awesome, and thanks, you really did save us (me) a bunch of time!


Sat Dec 24, 2011 12:44 am
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Endcoders better?
Glad you found the library useful. I don't know how many features you are using but the library has a lot of capabilities if you want to explore more. Have you tried multi-tasking with state machines? You can apply PID control to almost everything. For example, our robot has an elevator that lift the crates. It has a Tetrix motor under PID controlled.


Sat Dec 24, 2011 2:48 am
Profile
Rookie

Joined: Mon Dec 12, 2011 10:26 pm
Posts: 4
Post Re: Endcoders better?
I'm trying to coach the kids into finding their own answers, to include research on the 'net. Reuse is part of it, as is problem-solving. Which is to say, I don't want to hand them a complete library and say 'learn to use it', I'd rather hand them pseudo-code and concepts for now, and work on how to draft the concepts (simulink, uml, architecture documents) that they develop to solve issues.

Even if it means weird and limited operation of the elevator or conveyor mechanism, it's the kids' concept. It's hard for me to bite my tongue a lot, and help them move in a direction that I might not have chosen, instead of trying to lead/show them a different way. Sometimes this means telling them about an easier way when they've made the hard way work, other times it's suggesting that we try a different approach after they've discovered their way didn't work.

I told them early (last August) that we could have the robot correct for misalignment. I wasn't really careful about that back then, and the assumption made by the team was the 'black magic' was above their skill level and therefore Coach must do it. Coach sighed, did it in a weekend (lifting your code), and then spent a week explaining it with models and diagrams and circles and arrows and a paragraph on the back of each one...


Sat Dec 24, 2011 2:02 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: Endcoders better?
We took a different approach. We first introduced the basic robotics programming using the CMU provided cirriculum videos. That covers the fundamentals without going into the advanced stuff. Then, from the fundamentals, we presented various issues that require advanced techniques. Questions such as:
- How do you perform multiple operations simultaneously?
- How do you use sensor feedback for more accurate and smoother autonomous operations?
- How does each type of sensors work and how do you use them to help accomplishing a certain tasks?
The leads to the introduction of the library and what problems it can solve. Then, we will also dive into how each module works. That's why the source of the libary is open and not a black box. In the course of explaining the inner workings of the library, students also learn programming techniques and good programming style.
This is similar to the FIRST FRC program where they provided the WPI library which contains all the difficult pieces of code (e.g. vision processing). As long as the source is open and the students are encouraged to explore, they should be able to learn a lot from it. The library is also work in progress and the students take part in identifying new functionalities and features that may be added to extend the library. In fact, the library is not completely bug free so the students need to understand the library and debug it if necessary.
Having said that, we do encourage the students to experiment with their own design even though that's probably not our best choice. But they learned most when they failed and we do fail a lot.


Sat Dec 24, 2011 8:26 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 133 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.