Hi, this Labview Arduino interface will be perfect for all kinds of projects for kids!
A particularly great addition to projects is one or two microservos for just a few dollars. In the past I combined Labview with 555 timers or the like to create 50 Hz pulse trains to control servos, but it appears microprocessors like Arduinos are well suited to create good clean pulse trains, see for example: http://itp.nyu.edu/physcomp/Labs/Servo
Just as a suggestion, it would be really great to add a servo control subvi to the Arduino interface library, to greatly expand the type of projects possible.
For example, a simple wood armature/stick mounted to a servo, with a simple infrared transmitter and receiver proximity sensor mounted at the stick end, allows to first see the nature of the analog proximity measurment in action on a live graph, and then try proportional and derivative feedback control to, for example, have the system try to maintain the same distance between a person's hand and the stick end. It really is like magic, especially to students, and they get to create the system themselves! Soon they're doing custom projects.
The path to the firmware is incorrectly stated in the documentation. It should read C:\Program Files\National Instruments\LabVIEW 2010\vi.lib\LabVIEW Interface for Arduino\Firmware\LVIFA_Base
Thank you for your feedback. If you are referring to this KB, I have edited it and it is awaiting to be pushed live. Let me know if this is not what you are referring to. Thanks again!
I like this idea. I've created a sensor requiest thread for just this type of request. I am currently working on documenation for adding your own custom sensors, but motor controll VIs are high on the list of candidates for the next update.
Hi, I was planning on starting a local group (ranging from elementary to college students) for doing multiple projects with Labview through Arduino. Once this group gets going I can upload the resulting talks that teach the software and hardware through the projects.
However it has been awhile since programming in C, and I could not immediately determine how to go about inserting a case for servo control into the LIFA sketch and modifying a LIFA vi. Unfortunately I don't currently have a lot of time to thoroughly familiarize myself with the LIFA code (and as said my C is somewhat rusty)
Sam and Ben, you guys clearly put in a lot of work and did an excellent job in creating this thing. So in a way I hate to ask for more and be kinda pushy, but servo control will be central to these group projects I hope to start asap. Hence two questions. First, can you add servo support? Second, if so, do you have any kind of timeframe when your first LIFA update would come out? Having an estimated time in my head will help greatly in planning how to go forward.
Hi Sam, just saw your post. It really is awesome you guys and NI sound dedicated to providing support to this kind of new trail/brave new frontier being forged.
In my opinion on the sensor side what you guys have now for good reliable analog inputs (which in a youtube video mentioned about 200 Hz sampling rate with one analog channel; on my initial test with a Duemilanove got about 50 Hz, although had to upload LabVIEWInterface.pde rather than LVIFA_Base.pde to get to work, but I just ordered an Uno) I think is a home run, being that now with the existing generic analog read LIFA vi, kids can learn how to make the signal conditioning vi's (and accompanying control algorithms for servos, LEDs, sounds, etc.) and simple supporting breadboard circuitry, like a video game, for various analog low cost sensor types, whether infrared, hall effect, induction, thermistor, capacitive, etc.
In all honesty, the piece missing, which has always been tricky to get good controlling pulse trains for, is servos. Wonderful yet simple (except for the rectangular coordinate to joint angle conversion math) two joint robotic arms, or hacking the servos by removing the internal potentiometer and stoppers to become speed and direction controlled motors still controlled via pulse train timing, can be achieved with extremely low cost servos, allowing everyone to get in on the fun! (especially considering the student Labview has come down substantially in cost).
Since you are so pumped about LIFA (which I love to see) I'll get to work on this. I can't set a time line due to other obligations but I'll add servo control asap and release an update. I'll likely start with these buggers: http://www.sparkfun.com/products/9065.
I'll keep you posted on my progress. I'll also document it so that anyone can add sensors (which I was planning to do next week anyway).
Excellent. What I was thinking was a basic analog read and digital write setup like below, where in place of the digital write vi, there would be a servo vi, which in my mind would be best to have a period input (with 20 millisecond default) and a pulse width input. The user can quickly determine by sliding through values the pulse width range for their servo (typically a range of up to 0.5 to 2.5 milliseconds, with values in between corresponding to positions the servo internal controller will seek). The user then adds a few components to their vi, to for example to convert an analog sensor signal value to a servo pulse width value, first through a simple proportional conversion. Then optionally adding a derivative term to get much better feedback performance for the servo arm with the analog sensor at the end. Having the user do these straightforward but important steps is very important to help build confidence and familiarity with using Labview and the whole system and principals.
Putting an analog read and a digital write (which is to be replaced with servo vi, in which pulse width input would constantly update the delay variable in the Arduino sketch for the digital pin used for the servo) in line like this simply cut the loop execution rate in half.
Also I was pleasantly surprised reading the 6 analog channel port had same sampling rate as reading a single analog channel.
Even for younger kids I really kind of favor using lower level VIs and custom making more of the supporting program, being that Labview is already quite easy and fun to learn and use (I think we sometimes forget how much so), and you get a better feeling for what you're doing.
Excellent. What I was thinking was a basic setup like the below, where in place of the digital write vi, there would be a servo vi, which in my mind would be best to have a pulse period input (with 20 millisecond default) and a pulse width input. The user can quickly determine by sliding through values the pulse width range for their servo (typically a range of up to 0.5 to 2.5 milliseconds, with values in between corresponding to positions the servo internal controller will seek). The user then adds a few components to their vi, to for example convert the analog signal shown below (I was surprised reading the 6 analog channel port had same sampling rate as reading a single analog channel) to pulse width values, first through a simple proportional conversion. Then optionally adding a derivative term to get much better feedback performance for the servo arm with the analog sensor at the end.
I just sent off LIFA version 220.127.116.11 which is now compatible with LV2009 and later and also includes beta servo functionality. I hope that it will be up by the end of the day, but may take until Monday to go live. Keep an eye out for it and let us know what you think about the servo VIs. Make sure to update the firmware on your arduino to 18.104.22.168.
Here's a feature request. Add a watchdog timer for PWM outputs to have them stop in a 'neutral' motor state after some length of time. It would not fun trying to chase after a robot running on LIFA and a bluetooth module after the connection fails... not that it would ever happen or anything...
Two big issues I have with my Mega 2560:
1) USB Serial does not initailize properly. Disabling the Initialize Serial block in the Initialize function fixes this.
2) I2C Multiple Byte Read gets mixed up.
#1 is well known, so I won't go much into that.
#2 I have not seen mentioned elsewhere. I've tried to read the 6 Degrees of Freedom board from Sparkfun.com and the HMC6352 Honeywell Compass from Sparkfun.com. Both the Gyro on the 6DOF Board and the Compass have a burst read mode, where you ask it to send data, and it replies back with 2 bytes of data. In LabVIEW, I request to read back 2 bytes, but often, the bytes are swapped, or just plain missing, giving me bad data. If I read back 4 bytes, the data can be rotated, shifted, and other combinations. I'm pretty sure it's not supposed to do that.
On the 6DOF board, I have the luxury of reading back the LSB or the MSB independantly, so that's my work around for it. The compass does not have that luxury without digging deep into the EEPROM.
If I set the # of read bytes to 3 or 4, you can see what happens to the other byte.
You can see in the 2nd Front Panel Window, that the data that should be first, is in element 3, and then the data that should be 2nd is in element 0, and element 1. This device does have the characteristic of spitting out the second (LSB) byte of data repeatidly until asked to read again. But why isn't it working in the right order?
Kind of an update...
I've noticed this issue only crops up once a 0x10 gets sent... then all heck breaks loose.
0x10, for those who don't remember, is the new line character... I believe LabVIEW is getting this confused with this.
I've run into this issue before when using LabVIEW and a PIC24 when using a writeString function of some sort.
Maybe something to look into.