Arduino using WPI library?

Hello -

I’m going to be using an Arduino for a side project, and it’s my first time using an Arduino with LabView.

Does anyone know if I’ll be able to use the WPI Robotics LabView library with an Arduino?

Thanks, and sorry for the off-topic forum post!

I might be wrong, but I’m fairly certain that the WPI Robotics Library is developed specifically for FIRST, and since FIRST does not use the Arduino, it’s not supported.

However, check out the LabVIEW Interface for Arduino. It’s a Arduino program that communicates over serial to LabVIEW. It’s pretty neat, but I would NOT use it for large scale robotics where safety and control is critical, as there are no watchdogs or safety configurations built in.

Check it out:

I’m not sure if you have purchased an Arduino board yet, but if you haven’t, I’d try to steer you towards the Uno.

The Mega Rev2 board has a bug with serial communication, and LIFA has to run at a much slower baud rate of 9600 compared to the 115,200 baud rate of the Uno.

Of course, you lose quite a bit of functionality with the Uno compared with the Mega 2560.

We’re building an 8’ blimp, so safety isn’t as prevalent as if we were building an ankle biter.

I know it’s not officially supported, but I thought it might work to some extent. It’d be convenient, but I’m sure it won’t work the way it should.

I’ve put an order in for the Mega R3. Do they have the same serial issue?

I own a Mega R3 and I haven’t had any issues with it.

I recommend trying the native language, start with this sight for some very good robotics oriented libraries.

That’s good news, thanks.

I’ll probably experiment once it arrives. I’ll attempt to use the WPI library, and if it fails, I’ll be fine using the Arduino LabView Toolkit or the native Arduino language.

I’ll post an update once I make any progress.

AFAIK they don’t. You’ll have to go in and manually change the baud rate in the LIFA package, which isn’t hard to do.

I wouldn’t recommend this for a blimp though because there is no failsafe. If you lose communication, then your blimp will be on the run. Robots on the run are much easier to catch and disable than a flying blimp.

I’m not sure how much experience you have, or what hardware you have available, but I’ve done some playing around with the VEX controller and controlling outputs using LabVIEW… but you have to experienced with C programming to get it working.

It was a short lived project, as I ran out of time on it, but this is how it worked and how it was developed.

I was on a college level robotics team for a while (before college absolutely crushed my life into oblivion), and I took an old IFI robot controller, and wrote a control loop that had constant communication over the RS-232 programming port.

Basically, the system was made very easy to develop (and get Kevin Watson’s code from

All the PWMs are 8-bit unsigned, which ranges from 0-255… guess what else ranges from 0-255… the ASCII Table, which means I can control each motor with a simple character. What I did was package up all the PWM channels (16 total into 16 characters. Then there were technically 16 relay outputs (8 FWD, 8 REV) which can be sent in 2 8-bit characters. I didn’t have any ‘digital’ outputs. I just used the relay outputs for this. So, to control all 16 PWM channels and all 8 relay outputs, it took a total of 18 characters.

At the time, it seemed like a great idea to do it that way, but let me tell you, it’s more trouble than it sounds. Figure out how to convert it all to HEX, and it’ll make the whole serial communication less of a headache when using special characters such as line feed, break, etc… It’ll double your string size, but in reality, it’s still going so stupid fast that you won’t notice it and it’s still plenty fast to make it seamless. Anyway, terminate your lines with a new line ’
’ Once your program receives the new line, check for the number of characters, and if it’s consistent, then process the data. If it’s not equal, don’t process it.

After processing, it should send back sensor data from the digital input and analog input.

You’ll also want to implement a fail safe if for some reason, you lose control… not that it would ever happen at the worst possible time or location. You should set the servos to point the fans to come back to the ground, right? (Implement a Watchdog).

I can send you the code I have, but it’s not complete by any means, and I don’t even remember how functional it was.

It’s a more complicated project that you’re anticipating it to be. It’s doable, but I would seriously consider not using LabVIEW as a basis. C isn’t too hard to learn, and they give you a good starting point for it. You can try Arduino, but you should make your own communication interface if you want to use LabVIEW.

Hmm, alright. We’re going to need a higher level of control over PWM output to our motors than a simple character. I was hoping to be able to hook up a joystick and read values off of it. This is pretty much a requirement for the project, we’re going to need joysticks.

In the event of communication/power loss, we’ve designed the blimp to be able to coast downward at a safe speed so as to not hurt anyone or damage the airship too much. So I’d have all motor outputs be 0.

I don’t have any experience with C, but I’ve looked at a bit of it and feel like I’d be able to pick it up. I can also learn the Arduino language. I don’t know if there are any libraries for my project, but hopefully I’ll be able to learn enough to do what I want to do.

Of course, I might as well try to use something off of the WPI library before I discredit it all together. It might work, but I’m certainly not reliant on it or LabView.

EDIT: If I were to use C, would I be able to use the WPI C++ Robotics library?

You can only use the WPI Library for the CompactRIO basically. It like “trying to install MS Word on Linux. It just won’t work.”

Hmm, that’s a shame. I guess I’ll go library hunting now!

EDIT: I’ve taken a look at the WPI Joystick and Camera palate, and I don’t see anything which would restrict the platform to the FRC cRIO, however I believe the Camera palate will only work with the Axis M1011 or 206.

So I haven’t forgotten about you. I’ve been playing with my Arduino Mega 2560 over the weekend. I got away from the LabVIEW Interface for Arduino because of its various glitches, speed, etc… The Arduino is actually really easy to program. I was told this many times, but I never really tried it out.

It has the power of C++ with the simplicity of the Basic STAMP from Parallax. There’s tons of open source code and libraries available, so you can probably find a project where someone implemented an Arduino in a blimp.

As far as communication and control goes, you can still use LabVIEW. You’ll have to develop your own communication protocol for it, but it shouldn’t be too bad.

Some things to keep in mind. It’s usually considered good practice to always include some type of a sync word, meaning that you have a number that increments with each packet of data you send. That way, if you detect a packet out of order (number sent was less than last packet), you’ll trash it.

I’ve been using the BlueSMiRF RP-SMA. There’s little configuration to get it working fairly well. I haven’t found the max distance yet, but to note, this isn’t FCC Legal, as they have changed the antenna configuration.

Because we have changed the antenna configuration on the Bluetooth module, the FCC certification is no longer valid. But the module is completely suitable and legal for all home, hobby, and research applications.

I find the best way to send data is using a new line ’
’ (ASCII DEC 10 or HEX 0xA) as the termination character. You can create an event driven while loop in LabVIEW using the termination character. On the Arduino side, you’ll have the SerialEvent() function, which is triggered on a serial receive event. You can then check to see if the newline ’
’ character was sent, and if it was, then process your data.

Here’s the format I would use:


For receiving back data, the format will be very similar. You’ll have a sync word and sensor values. You’ll want to look at an ASCII table, and you should note that sending over raw data values is a no-no for the BlueSMiRF unless you format it properly. You’ll have data loss, as it doesn’t pass through some values. If one of your sensors sends back a 10, then you’ll trigger it to send the data. Try to convert all of your sensor values to ASCII text and ASCII number values. It uses more bandwidth, but it should still be relatively fast.

Let me know if you have any questions. The best way to get started with the Arduino is to just get started. Play with it, send numbers to it, try to echo back those numbers, then add numbers. Make an LED turn on when you send it a center character, and make it turn off if you send another one.

Gearing up for WPI, will have more time to invest into this project after.

I was planning on using the Ethernet shield to plug it into a router configured to act as an Access Point, and pump info to the Arduino via TCP/UDP. Will this suit my need?

I had my school pay for the Arduino, so I’m waiting on whenever they place the order in…unfortunately, nothing has come to my doorstep yet.

I looked at the Ethernet shield library, and it all seemed pretty easy, but I never tried it.