navX Library v2 - From Team 900 - The Zebracorns

[Caboose]

Together with KauaiLabs, Inc., Team 900 has updated the LabVIEW library for the navX-MXP and navX-Micro.
Check it out. https://github.com/FRC900/navX-MXP-LabVIEW/

[Ari423]

What are the major changes with v2 from v1?

Also what kind of luck have you had using LabVIEW with GitHub. My team has tried it a number of times but it never seemed to work out how we wanted.

[Caboose]

Originally Posted by Ari423

What are the major changes with v2 from v1?

Also what kind of luck have you had using LabVIEW with GitHub. My team has tried it a number of times but it never seemed to work out how we wanted.

The biggest change is how the navX is read from, better support for Serial, and better recovery support for power issues.
In v1 SPI/I2C were read and cached if needed when ever the user would make the read request. Where as the Serial had a background loop VI running to handle the serial buffer that would dump data into global variables.
In v2 all interfaces run in a background loop VI that handles and navX reading and writing for the navX, stores the navX registry cache, handles any brownouts/disconnects to the navX, and makes sure that the latest data is always available to the user. This also allows for using a common set of VIs for reading and updating the navX and switching interfaces without the need to rewrite code. The Serial protocol can now also be switched during runtime.
The biggest thing for myself is a better organization of the files. In v1 I started with I2C and SPI as my team didn't see the need for serial. I was later asked to add Serial by Scott from KauaiLabs so that was sort of just shoehorned in. In the new version all interfaces are handled the same.

On LabVIEW and GitHub:
LabVIEW and Git are not the best of friends, but can be made to work together. Here is an NI Community Doc after a quick Google search about LabVIEW and Git.

[Caboose]

Latest Release
Fixes #9 - Missing NAVX_INTEGRATION_CTL functions

[Caboose]

Build v2.0.5.0
Fixes:

• #10 - Device not open for immediate ZeroYaw.vi
• #11 - Async processing loop not closing on robot code abort

[aeastet]

What do you think about these upgrades?

I added a state machine to the code.
I simplified the communication.
I changed it so you only make one call to get the registry values vs calling for every vi.
I added action engines (functional globals) so that the data is easy to get into the robot code. If you drop the example two code into the periodic tasks all you have to do is open the vi and get the action engines that you what data from. Drop them in your code and it works that easy.


I wanted to get your opinion of what I did before I went any further. I would be happy to help contribute to the development of this library. I have used the NavX board for the last two years. I took the code that you developed the first year and simplified it to do only want I wanted it to do. This time I made it do everything still.

Thanks,

Tim

[Caboose]

Originally Posted by aeastet

What do you think about these upgrades?

I added a state machine to the code.
I simplified the communication.
I changed it so you only make one call to get the registry values vs calling for every vi.
I added action engines (functional globals) so that the data is easy to get into the robot code. If you drop the example two code into the periodic tasks all you have to do is open the vi and get the action engines that you what data from. Drop them in your code and it works that easy.


I wanted to get your opinion of what I did before I went any further. I would be happy to help contribute to the development of this library. I have used the NavX board for the last two years. I took the code that you developed the first year and simplified it to do only want I wanted it to do. This time I made it do everything still.

Thanks,

Tim

Hey Tim,
I'm always open to feedback and/or if I'm doing something backasswards. I've tried to keep the navX library for LabVIEW as easy to use as possible. The user just needs to open the device and use the get/set VIs similar to the default FRC NI sensor VIs. Originally there was a loop VI that needed to be placed in the Periodic Tasks.vi and a Global var for the registry but when I rewrote the code I decided against that as it was an extra hoop the user would need to jump through to get started.
Looking over your code from your ChiefDelphi post, I assume this is the latest, I have a few comments. First, placing the DrvrStn Start Comm.vi loop inside your state machine will cause you to never exit the 'INI' state, never ending loops in loops. Unless you will be rewriting how the data processing is handled and the Open*** VIs, how you are currently writing the 'Action Engines' you are going to be caching a cache, and there is a small possibility where you could read across two updates with how they are decoding the data. In addition caching all of the values inside of the VIs will inflate the memory footprint of the library.
I would like to hear what your definition of easier to use is when it comes to the current library. To me it is currently on par with the native FRC NI sensors, Open -> Get/Set -> Close, the processing happens 'magically' in the background.

[Caboose]

Build v2.3.254
Update to match the new navX firmware 2.3.254 from Kauai Labs

• Modified VIs which were previously limiting update rate to 60Hz (now 100Hz)
• Modified the processing loop wait time to (1/update_rate) - 4. Empirical testing on a RoboRIO indicated that this update rate allows all 100 samples/second to be received successfully on a RoboRIO. The previous update rate was not quite sufficient, and would lead to missed updates.

[Bpk9p4]

is there any difference between the navx-Micro and the navx-MXP

[slibert]

Originally Posted by Bpk9p4

is there any difference between the navx-Micro and the navx-MXP

navX-MXP has expansion IO and mounts directly into the RoboRIO MXP port; it has SPI, I2C, TTL UART and USB interfaces. Specifically designed for plug-n-play use in FRC. Great for use as a FRC Chassis Orientation sensor. $99.

navX-Micro is smaller (2x2" square), and only has I2C and USB interfaces. Great for FTC robots, and also placing on arms and cameras on FRC robots if you want to measure their orientation separately from the Robot Chassis. $79.

Other than those differences, the sensor and motion processing firmware is the same.

The RoboRIO libraries (C++, Java, LabVIEW, Python, C#) will work with either, no code change required except to specify which interface to connect to it with.

We are aware of teams who are using both simultaneously on a FRC robot, which is also supported.

- scott

Also, please note that there's currently an issue w/reconnecting to the RoboRIO if communicating over USB if the navX-device gets reset. Kauai Labs is currently working with National Instruments to resolve this issue, but until it is resolved, we are not actively encouraging using the USB interface in competition settings. We'll notify the FIRST community once this issue has been resolved.