Several questions (language comparison)

[flameout]

Our team (well, I, as our only veteran programmer) is trying to decide on the language to program the robot in next year. While thinking this over, I have come up with several questions.

Please correct me if I'm wrong in these questions.

In the C++ WPILib, is there a way to set thread priorities? I believe it can be done in both LabVIEW and Java.

What about UDP communication? I know LabVIEW contains primitives, but is this doable in Java and C++?

Is there some sort of event handling available? Could I, for example, run a section of code whenever a new image is available from the camera, or run a section of code when a digital input changes without polling?

I'll post more questions when I can think of them.

Thank you for any help.

[AustinSchuh]

I can help answer one or two of your questions, and hopefully someone else can step in to fill in any gaps in my answers and answer the other questions.

Originally Posted by flameout

In the C++ WPILib, is there a way to set thread priorities? I believe it can be done in both LabVIEW and Java.

There is a way. At the very least, you can call the vxWorks calls and set the priority. I don't know the exact commands off hand though.

Originally Posted by flameout

What about UDP communication? I know LabVIEW contains primitives, but is this doable in Java and C++?

It's very doable in C++. We've done it... If I remember right, we used standard UNIX sockets, and it just worked.

[flameout]

I'll look up VxWorks calls. Any additional help on this would be appreciated.

Any clue if all of the standard library is available? I don't have the software environment set up (I'm on Linux here) so I can't test anything.

Thank you for your help.

[Radical Pi]

Originally Posted by flameout

In the C++ WPILib, is there a way to set thread priorities? I believe it can be done in both LabVIEW and Java.

Use the class Task. In the constructor: Task("myTask", function, priority), where function is a pointer to the thread's main and priority is thread priority (100 is default). Call Start with any arguments to the main function to start the task.

Originally Posted by flameout

What about UDP communication? I know LabVIEW contains primitives, but is this doable in Java and C++?

vxWorks implements the socket system in C++. You can see how it's used in the CANJaguar SpeedControl example or in Vision/PCVideoServer.cpp (the former copy-pasted the latter)

Originally Posted by flameout

Is there some sort of event handling available? Could I, for example, run a section of code whenever a new image is available from the camera, or run a section of code when a digital input changes without polling?

I don't have the exact code in front of me, but I can push you in the right direction on how to do this. Team 639 used a rotating kicker and had a IR sensor that pulsed a Digital Line whenever the kicker reached a certain angle.
Any class that inherits from InterruptableSensorBase (That means DigitalInput, but not AnalogChannel) can interrupt the code. I think the code was somewhere along the lines of this:

DigitalInput *sensor;

void InterruptFunction() {
//do stuff here
}

Init() {
//blah
sensor = new DigitalInput(1);
sensor->RequestInterrupts( (tInterruptHandler)InterruptFunction);
sensor->EnableInterrupts();
//blah
}

I'm unsure of the line with the RequestInterrupts function, other than that I'm sure of everything.

No idea if an equivalent exists in Java

[flameout]

Okay, so I think I'm starting to get a better idea of this.

I guess I'll have to install WindRiver to look at more documentation -- I cannot find those interrupt functions in the WPILib user's guide, and they do not have the same names as the VxWorks ones.

Thank you for the help.

[Radical Pi]

The interrupt functions aren't in the documentation. We had to figure out how to use them ourselves

[flameout]

For now, we only have one computer usable (i.e. a laptop other than the Classmate) for programming the robot, but it is running Linux.

Therefore, I'll probably (I'm still very undecided about all this) suggest Java. I'm willing to use my laptop as the team's programming laptop, if I can get NetBeans installed.

I'll start working on it soon.

Thank you.

[Ether]

Originally Posted by Radical Pi

Team 639 used a rotating kicker and had a IR sensor that pulsed a Digital Line whenever the kicker reached a certain angle.

Why did you need an ISR to handle this? Was 20ms not fast enough?

[Radical Pi]

Originally Posted by Ether

Why did you need an ISR to handle this? Was 20ms not fast enough?

Our kicker rotated and launched outward when the kick button was pressed. The rotations were at an extremely high speed. To prevent the kicker from coming out at an unpredictable and generally unfavorable angle, we used the sensor as an interrupt to make sure the kicker could come out at a predictable angle. As the speed of the rotator increased, the range of angles for a good kick decreased, so the room for error in the timing of the code wouldn't allow for timing of the kick to occur in the main loop. The interrupt checks a flag for whether to kick, and also will delay the kick as needed to compensate for the speed of the kicker (without the extra timing code, the kicker only works around 75% power)

[Ether]

Originally Posted by Radical Pi

The interrupt checks a flag for whether to kick, and also will delay the kick as needed to compensate for the speed of the kicker (without the extra timing code, the kicker only works around 75% power)

What is the worst-case execution time of the ISR from the time it receives control until it returns? Do you enable interrupts in the ISR, or leave them disabled?

[Radical Pi]

Originally Posted by Ether

What is the worst-case execution time of the ISR from the time it receives control until it returns? Do you enable interrupts in the ISR, or leave them disabled?

I'm not sure of the exact number as I didn't write the timing code for it, but I think the time to run it is almost nothing. The only slow operation is the wait to delay the kick, but that would be a very small wait.

The interrupt is setup through WPILib, so I have no idea if interrupts during interrupts are enabled (never seen any problems though).

[Ether]

Originally Posted by Radical Pi

I'm not sure of the exact number as I didn't write the timing code for it, but I think the time to run it is almost nothing. The only slow operation is the wait to delay the kick, but that would be a very small wait.

When you say "very small" do you mean, say, a few microseconds?

Or are you talking milliseconds?

[Radical Pi]

Originally Posted by Ether

When you say "very small" do you mean, say, a few microseconds?

Or are you talking milliseconds?

I think it's in the single digit milliseconds, but again I'm making a guess from the speed of our kicker