NAVX vs. Spartan board
 

We've used the NAVX for the last 2 seasons with pretty good success. But we did have issues during autonomous after bouncing over defenses with things getting off a bit. The camera helped out, but 2-ball seemed like an impossibility.

We've seen some of the top teams using the Spartan board which has a different sensor setup but seemed to perform quite well. It also has locking connectors for the PWM's which is cool (other than having to buy new connectors), but we really haven't had that much problem with PWM wires coming loose.

Has anyone used both of these? Have any good experienced comparisons for us? Thanks!

Re: NAVX vs. Spartan board
 

I can't speak to the NAVX or offer comparisons, but we had a great experience this season with the Spartan Board. If you PM AWol (Adam) on my team, he can give you better details than I can.

Re: NAVX vs. Spartan board
 

I'm a bit biased, but we used the first rev of the spartan board and liked it so much we asked the folks @ 971 if we could produce it. The intial spartan board had us hooked because we only drifted 1-2 degrees over an entire match using our swerve. We found that fairly impressive compared to what we had been using previously. Again I'm pretty biased but I figured I'd share our team's experience.

Re: NAVX vs. Spartan board
 

I can comment a bit but I will add that I haven't used the Spartan Board. I have however used the gyro that the Spartan Board uses (http://www.analog.com/media/en/techn.../ADXRS453.pdf). It's not any more or less accurate than the NavX IMU.

I'll also say that our team has used the NavX for a couple of seasons now and we're madly in love with it. So much so that we wrote the LabVIEW libraries for it. We're also doing some neat things with the NavX micro now too.

They are both great products and each have their uses (the locking PWM pins are very compelling). That being said, using an IMU or Gyro really comes down to your code for the most part.

If you're having issues bouncing over defenses then it's possible you were trying to poll data too quickly or not filtering out anomolous data or didn't do enough testing. It's likely not the hardware.

Re: NAVX vs. Spartan board
 

We have used the navX and navX-MXP for the last few years. I'm not sure what failure or anomaly would cause what you described; anecdotally, I'm sure many teams bounced over many defenses many times without issue.

Scott from Kauai has been incredibly responsive and helpful for any issues; I'd run this by him if you haven't already.

That said, I've never heard of the Spartan board until this thread. I see WCP has a product page, but there's no technical details listed at all. Where can you find more information? (I'd also be hesitant at the $199 price, but we only use the navX-MXP for the IMU features, the Spartan Board has more of the RoboRIO breakouts which we don't currently need).

Re: NAVX vs. Spartan board
 

I'll have a link up shortly on the wcp info.

Re: NAVX vs. Spartan board
 

The Spartan board has its own voltage regulators, locking PWM connectors, more exposed SPI, and 4 block DIO connectors. It is not an absolute need, but it provides lots of features that are very useful at the price point.

Re: NAVX vs. Spartan board
 

Having both used the navx and spartanboard on different teams I have to say that they are both excellent IMUs. Nearly no drift, and both are easy to use in programming.

Additionally though, while I can't speak directly for our wiring team, I do remember them being particularly pleased with the locking PWM pins.

Re: NAVX vs. Spartan board
 

It sounds like both boards have very good accelerometer/gyro capabilities. I don't really know the details of the issues we were having over the defenses, but the SW guys definitely contacted the right folks about the issues and worked around them where possible. It was very possibly in the code and how we were using the values. I'm just the hardware guy :-).

Does anyone have a comparison of other features on the boards besides the gyro capabilities (assuming these are fairly similar)? Things like the number of extra DIO's, other breakout capabilities, locking connectors, etc.

Re: NAVX vs. Spartan board
 

Link to Document


We'll have more info on our site.

Re: NAVX vs. Spartan board
 

One very useful feature of the Spartan board is the "clip" on each of the PWM connectors. These latches bite into the connector of the PWM cable and prevent it from coming out, even if the robot takes a huge impact. Knowing that going over a huge bump or taking a big hit will neither mess up your gyro data nor cause a wire to come loose is a huge relief :]

EDIT. Here is a list of pros and cons for each system based on the data sheets and info I have on both. PLEASE let me know if I missed anything or if any information is incorrect!

Re: NAVX vs. Spartan board
 

As creator of the navX-MXP/MICRO I have to say that the Spartan connector breakout is very nicely done - kudos to WCP on that.

Moving beyond the side-by-side gyro accuracy comparisons which I understand are very similar, I'm not aware that the Spartan board has accelerometers or magnetometers on it. YMMV as to whether these features are valuable, but certain teams definitely use the accelerometer data to balance the robot, and the magnetometer to acquire initial compass orientation before the motors are energized at the start of a match.

Beyond the sensing capabilities, there's one key architectural feature in navX-MXP/navX-MICRO that definitely differentiates it - Simulaneous Multi-port data: using a dedicated 100Mhz microcontroller with simultaneous multi-port communication at 200Hz update rate (TTL UART, I2C, SPI and USB are all simultaneous).

The simultaneous multi-port data capability enables some very interesting features in a distributed processing environment, like connecting a navX-MXP/MICRO to both the RoboRIO and a separate video processor like the Raspberry PI or the nVidia Jetson. This allows the video processor to acquire IMU/1-millisecond resolution timestamp data from the navX at the instant each video frame is acquired, send that along with detection info to the RoboRIO, after which the Robot Control Software in the RoboRIO can look back into a 3D time history to correct the angles calculated by video processor to account for any motion occurring during the detection processor.

Note that this is a 3D time history of orientation, which includes not only changes to yaw but also tip and tilt; navX fuses gyro and accel data to yield a quaternion which represents 3d orientation.

The libraries and drivers to allow teams to easily add this capability to their robot control system are under development and are expected to be released by the time the 2017 season starts - as a free upgrade to existing navX-MXP and navX-MICRO customers.

Another useful feature this enables is to connect navX-MXP/navX-MICRO over USB to your PC to monitor it's behavior and/or stream sensor data to the PC disk at the same time it's connected to the RoboRIO.

Lastly, since I'm implying there's a dimension of apples and oranges in the comparison, one possibility I haven't heard discussed here is using the best of each. This configuration would use the Spartan board w/out the Gyro - for it's superior IO connector design - and then add a navX-MICRO sensor connected over USB for 9-axis, multiport orientation data.

Re: NAVX vs. Spartan board
 

This past year 1836 did this so that we had freedom to place our roboRio in any orientation.

Re: NAVX vs. Spartan board
 

Cool.

Re: NAVX vs. Spartan board
 

Hmm, perhaps that's also worth putting in the side-by-side comparison Ahad put together - the Spartan requires mounting perpendicular to the robot chassis (parallel to the Z-axis plane), whereas the navX-MXP can be mounted in any of 8 possible orientations. That ends up impacting RoboRIO mounting since both use the RoboRIO MXP port. The navX-MICRO - which doesn't use the MXP port - can be mounted independent of the RoboRIO.

Re: NAVX vs. Spartan board
 

[Citation needed]

Re: NAVX vs. Spartan board
 

Scott, thanks for the suggestion! I made an edit to the list to add in your points.

Re: NAVX vs. Spartan board
 

Both of them have been used successfully by many teams, and you can't go wrong using either for helping determine your robot's heading.

Honestly it is really hard to judge a gyro by its spec sheet - you always end up with apples vs. oranges (ex. the ADXRS has *excellent* tilt and vibration rejection specs, whereas the MPU-9250 can use its linear accelerometers for tilt rejection), and various manufacturers may be more or less conservative about the relationship between their specs and their actual median product performance.

When it comes to pure yaw performance, I'm a bit surprised that nobody has done a benchmark yet :) (Put both gyros on the same robot, calibrate right before starting, drive around for 2 minutes, return and manually align the robot to exactly the same angle...repeat for N trials). I'd be shocked if there was a significant difference, to be honest.

Of course, there's no doubt that NAVX wins hands down in pitch, roll, linear acceleration, and direction of gravity measurement though.

Re: NAVX vs. Spartan board
 

Per the ADXRS453 datasheet, the Gyro on the gyro-enabled version of the Spartan board is single-axis, and is the SOIC_CAV package designed for yaw rate sensing. I haven't come across any Spartan board mounting instructions, but if we thus assume the purpose of the ADXRS453 is to be a yaw rate sensor, then any mounting configuration in which the sensor is not parallel to the FRC field surface will result in integrated yaw angles which include an error proportional to the offset angle from parallel. For instance, if the board is mounted vertically, the sensor would be measuring a "tip" or "tilt" angular rate rather than yaw. This is as compared to a triaxial gyro which can measure yaw rate even when mounted vertically.

If you think this is incorrect, please let me know.

Re: NAVX vs. Spartan board
 

I'll put in that we had no issues with NavX heading getting off due to defenses. During our autonomous, our robot was able to reliably and precisely get itself to the tower (using the NavX and encoders on a tank drive for dead reckoning), even after slamming down over the rock wall.

Re: NAVX vs. Spartan board
 

That is correct. The roboRIO needs to be horizontal.

We developed the Spartan Board mostly to solve brownouts and latching connectors. If it hadn't been for the brownout problems with the roboRIO, we would have likely developed the board only for 971 and not bothered to sell it. The regulators brown out right about when the roboRIO CPU browns out.

We've been using the ADXRS453 for a number of years, and have been impressed with it. Once you are making a board with a bunch of active circuitry, adding a gyro is easy. I might have picked a different gyro if I were to start over today.

One of the main drivers for selling the board was because there was enough interest from our friends in the board that we couldn't continue to fabricate enough of them each season. By selling it, we were also able to get it approved by FIRST, and add PWM pass-throughs. Selling the board has honestly been a lot of work... RC and WCP have been a huge part of figuring out how to build the boards in quantity and to sell them.

Re: NAVX vs. Spartan board
 

My apologies, I was assuming you meant to say either of the Spartan Boards could not physically be mounted in other planes. I didn't want teams getting the wrong idea that they couldn't mount a Spartan Board without gyro any direction other than parallel with the floor.

Re: NAVX vs. Spartan board
 

The navX-MXP can also be mounted independently, assuming you use USB to connect to the roboRio

Re: NAVX vs. Spartan board
 

Thanks everyone for the great comparisons and feedback. As I suspected, both boards are great at the basics but do have some differences which may make a difference depending on what you want to do or how you want to use their capabilities. The idea of the base spartan board with the Navxmicro is really intriguing. I'll consult the rest of the team and see where we want to go for this season.