Chief Delphi - RELAY!!

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- C/C++ (http://www.chiefdelphi.com/forums/forumdisplay.php?f=183)

- - RELAY!! (http://www.chiefdelphi.com/forums/showthread.php?t=87375)

krudeboy51

03-11-2010 10:58

RELAY!!

is it possible to set a relay to get the Y-axis on a joystick? I have tried

Code:

Relay->Set(Thirdstick.kYAxis());



Relay->Set(Thirdstick.kDefaultYAxis());

and also

Code:

Relay->Set(Thirdstick.GetY());

none of them worked

Alan Anderson

03-11-2010 11:06

Re: RELAY!!

A joystick axis gives a value from -1 to +1. A relay is either on or off. Can you describe in detail what you're trying to do? Right now, I'm as confused as the compiler is about the intended behavior.

krudeboy51

03-11-2010 11:19

Re: RELAY!!

the relay is used to control a motor on our arm. For the motor to go forward or backward I had set a button for it and used an "else" statement which would keep it off. Now I would like to use the joystick to make the motor go forward or backward.

Alan Anderson

03-11-2010 12:16

Re: RELAY!!

So you want the relay to be set "forward" if the joystick is pushed forward, you want the relay to be set "reverse" if the joystick is pulled backward, and you want the relay to be set "off" if the joystick is left at center?

The joystick Y-axis value will be negative if you push it forward. The value will be positive if you pull it backward. The value will be zero if you leave it at center. Does that help send you in the right direction?

krudeboy51

03-11-2010 15:17

Re: RELAY!!

Quote:

Originally Posted by Alan Anderson (Post 979419)

yes, Inderstand that concept, but the thing is, for victors and jaguars we would use Joystick.GetY. I dont understand what to put for a relay, I have tried all of those listed in the first post

Dave Scheck

03-11-2010 15:51

Re: RELAY!!

The code you have definitely won't work. It doesn't look like you're creating instances of the classes. Assuming that I'm misunderstanding your code, your problem comes in with what Relay::Set expects as input vs what Victor::Set or Jaguar::Set expect. Compare the prototypes that are found in WPILib

Code:

void Jaguar::Set(float speed)

{

}



void Victor::Set(float speed)

{

}



void Relay::Set(Relay::Value value)

{

}

See how Victor and Jaguar take in a float? That happens to be what Joystick::GetY is returning. In the case of Relay::Set, it expects a Value type. That can be found in Relay.h as

Code:

typedef enum {kOff, kOn, kForward, kReverse} Value;

So, in order to call Relay::Set, you need to pass in a Relay::kOff, Relay::kOn, Relay::kForward, or Relay::kReverse (look at Relay.h for a description of what they each mean)

In order to do what you want to do, you'll need some logic. Here's an example for using a forward and reverse threshold (I'm using .5 as my threshold in either direction) to set the state of the relay. Don't forget to turn it off if the stick is between the thresholds.

Spoiler for For Jared:

Jared Russell

03-11-2010 15:54

Re: RELAY!!

The joystick axes output a double between -1 and 1. Victors and Jaguars conveniently accept a double value between -1 and 1 as an input.

Relays can be set to kForward, kReverse, or kOff (or kOn, but that doesn't seem to matter here).

So you need to write some code that translates from [-1, 1] to [kForward, kReverse, kOff].

All you need to do is write an if...else statement that checks if the joystick axis is pushed forward, backwards, or is in the center. In other words, is the axis <0, >0, or ==0 (note that you might not want to check if it is exactly zero, since the tiniest bit of movement would make your motor move - you probably want a threshold so that if the stick is within, say, .1 of 0, just call it zero).

EDIT: Aww, Dave - he was getting so close! :)

krudeboy51

03-11-2010 16:12

Re: RELAY!!

Ok, now I understand, Thanks alot!!

Dave Scheck

03-11-2010 16:14

Re: RELAY!!

Sorry Jared :o

I went back and put the code in a spoiler tag if krudeboy wants to go through the thinking exercise.

EDIT: He just posted which means he probably saw it before the spoiler tag was in. Oh well. It can still be a thinking exercise for those new to programming

krudeboy51

03-11-2010 16:19

Re: RELAY!!

One Problem, Does anyone know what this error is:

[Qoute]
Fatal error "Attempting to resuse an allocated resource" in Allocate() in C:/WindRiver/workspace/WPILib/Resource.cpp at line 76
[/quote]

I looked at line 76 of the code, all I have there is a "wait" in autonomous

Dave Scheck

03-11-2010 16:41

Re: RELAY!!

The line 76 is in C:/WindRiver/workspace/WPILib/Resource.cpp not in your code.

That line is checking to see if the index has already been allocated.

Code:

if ( m_isAllocated[index] )

{

    wpi_fatal(ResourceAlreadyAllocated);

    return 0;

}

Looking further up to see where it is used, Relay uses is it in InitRelay. So this tells me that you have two relay objects that are set up on the same slot.

Check where you declare your variables. You'll get that error if you're trying to create two relays on the same slot. Make sure you don't have something like:

Relay r1(1);
Relay r2(1);

krudeboy51

05-11-2010 10:32

Re: RELAY!!

I only have one relay:

Code:

myRobot(1, 2),

                Leftstick(1),

                Rightstick(2),

                Thirdstick(3)

                        

        {

                LGC = new Servo(9);

                RGC = new Servo(10);

                pair1 = new Victor(1);

                pair2 = new Victor(2);

                CamKicker = new Victor(6);

                Winch = new Victor(7);

                Dribbler = new Victor(5);

                ArmRelease = new Relay(1);

                Zone1 = new DigitalInput(1);

                Zone2 = new DigitalInput(2);

                Zone3 = new DigitalInput(3);

                CamSwitch = new DigitalInput(7);

Dave Scheck

05-11-2010 11:16

Re: RELAY!!

I went back and added the spoiler tag to retain my original post but to hide it from the casual reader. As Joe said below, my analysis is incorrect. I'll leave the post here for reference.

Spoiler for Hiding bad info:

You're getting burned by the way you're building up Relay and DigitalInput. The code you have is syntactically valid and each line will run on its own, however, there is some code inside WPILib that is hurting you when they interact.

WPILIb provides the following constructors for Relay and DigitalInput

Code:



Relay(UINT32 channel, Direction direction = kBothDirections);

Relay(UINT32 slot, UINT32 channel, Direction direction = kBothDirections);



explicit DigitalInput(UINT32 channel);

DigitalInput(UINT32 slot, UINT32 channel);

With the way that you're calling those, you are only passing in a channel to the construtor, so you're calling the first construtor in for each class. Herein lies the problem.

The Relay constructor is going to call InitRelay with GetDefaultDigitalModule() as the slot number.

The DigitalInput constructor is going to call InitDigitalInput with GetDefaultDigitalModule() as the slot number.

In each of those functions, a Resource is allocated using the slot number passed in (in both cases the output of GetDefaultDigitalModule()) and a channel number (the channel number from your constructor). Inside Resource::Allocate is the code that I referenced in my previous post. You're telling it to create two Resources using the same slot and channel combination. It's at this point that the assertion fails and things break.

Specifically, it's these two lines

Code:

ArmRelease = new Relay(1);

Zone1 = new DigitalInput(1);

These both allocate Resources using the default slot with channel 1.

To fix this, you need to use the other constructor for these objects and specifically call out the slot number. I forget what the slot numbers are, but I found this in our 2009 code.

Code:

ap_rlyElevatorR  = new Relay(1);

ap_elevatorLimitRightTop = new DigitalInput(4, 1);

So that code creates the right elevator Relay on the default slot, channel 1 and creates the right top elevator limit switch Digital input on slot 4, channel 1.

Change up your constructors and you should be ok

jhersh

05-11-2010 12:44

Re: RELAY!!

Quote:

Originally Posted by Dave Scheck (Post 979745)

Specifically, it's these two lines

Code:

ArmRelease = new Relay(1);

Zone1 = new DigitalInput(1);

These both allocate Resources using the default slot with channel 1.

That's not correct Dave. The digital modules have 4 distinct resource types... PWM channels, Relay Channels, an I2C bus, and Digital I/O channels. Because they are separate resources, you will not get conflicts from using the same channel "number" in a different set of channels. This is best illustrated by looking at the digital sidecar itself and witnessing different pins for each of those channel types.

Quote:

Originally Posted by Dave Scheck (Post 979745)

To fix this, you need to use the other constructor for these objects and specifically call out the slot number. I forget what the slot numbers are, but I found this in our 2009 code.

Code:

ap_rlyElevatorR  = new Relay(1);

ap_elevatorLimitRightTop = new DigitalInput(4, 1);

This has no effect. The default digital module is 4, so explicitly specifying 4 is not any different than not specifying it. In either case, you are allocating the same channel. The reason this works is because the relay channels are separate from the digital I/O channels.

Alan Anderson

05-11-2010 13:00

Re: RELAY!!

What do the numbers in this line represent?

Code:

myRobot(1, 2),

How does that interact with these two lines?

Code:

                pair1 = new Victor(1);

                pair2 = new Victor(2);

jhersh

05-11-2010 13:04

Re: RELAY!!

Quote:

Originally Posted by krudeboy51 (Post 979739)

Code:

myRobot(1, 2),

...                        

        {

...

                pair1 = new Victor(1);

                pair2 = new Victor(2);

This is the source of your error. You presumably (since you didn't actually show it) have a RobotDrive member called myRobot which uses PWM channels 1 and 2. You then create 2 Victors which use PWM channels 1 and 2. These 2 channels are already in use by your robot drive object.

Dave Scheck

05-11-2010 13:17

Re: RELAY!!

Thanks for the correction Joe. After reading through the WPILib code again, I see how this is being done and agree with what you said about the resources. I also see what you mean about my code example. With the realays and digitial i/o on the same slot, it doesn't make any difference to specify the slot number in this case. I went back and put my original post in a spoiler tag to prevent confusion yet still have my bad analysis still available to learn from.

So, back to the analysis of the original error. The error clearly states that a resource is being allocated that was already allocated. I saw that Alan just posted a good suggestion that I was going to suggest next. My other suggestion (somewhat related) was to make sure there were no other places in the code that create relays, speed controllers, or analog/digital inputs on channels that were already in use for that resource type.

Dave Scheck

05-11-2010 13:21

Re: RELAY!!

Quote:

Originally Posted by jhersh (Post 979757)

One thing to add on to this is that RobotDrive creates Jaguar objects on these channels. Based on the code it looks like you are using Victors.

You might want to look into using one of these two implementations of RobotDrive.
RobotDrive::RobotDrive(SpeedController *leftMotor, SpeedController *rightMotor, float sensitivity);
RobotDrive::RobotDrive(SpeedController &leftMotor, SpeedController &rightMotor, float sensitivity);

jhersh

06-11-2010 15:52

Re: RELAY!!

Quote:

Originally Posted by Dave Scheck (Post 979758)

My other suggestion (somewhat related) was to make sure there were no other places in the code that create relays, speed controllers, or analog/digital inputs on channels that were already in use for that resource type.

Very true. We only saw a small snippet of code and it's quite conceivable that other objects are constructed else where. Wouldn't it be nice if the error told you which allocation cause the reuse?

All times are GMT -5. The time now is 14:26.