ANNOUNCING: navX MXP Robotics Navigation Sensor

[ayeckley]

Thanks for the response. It's going to take us a while to digest that. Doing our own integration in real time does not seem like an attractive option, at least at first blush.

[slibert]

Originally Posted by ayeckley

Thanks for the response. It's going to take us a while to digest that. Doing our own integration in real time does not seem like an attractive option, at least at first blush.

I may not understand why "total rotation" is needed - however my intuition is that transforming the quaternion to yaw angle is all you need. Quaternions were developed to avoid gimbal lock and can easily yield a yaw angle that is 0 to 360 rather than -180 to 180; my thinking is this completely eliminates the need for a total rotation value.

The code to do this is pretty trivial:

float q[4], yaw_radians, yaw_degrees;

// Convert navX Quaternions to a +/- 2 pi radians range
q[0] = ((float)quat_w) / 16384.0f;
q[1] = ((float)quat_x) / 16384.0f;
q[2] = ((float)quat_y) / 16384.0f;
q[3] = ((float)quat_z) / 16384.0f;

// Range-check quaternion values
for (int i = 0; i < 4; i++) if (q[i] >= 2) q[i] = -4 + q[i];

// calculate yaw angle (0-360 degrees)
yaw_radians = atan2(2*q[1]*q[2] - 2*q[0]*q[3], 2*q[0]*q[0] + 2*q[1]*q[1] - 1);
yaw_degrees = yaw_radians * (180.0/3.1415926);

[dellagd]

2607 is very excited to get working with their board when it arrives this coming week!

Question though: Given the high accuracy of the device, has anyone attempted to do distance estimation from a double integration of the accelerometer data? I'm curious how it would perform, even for small distances.

[Gdeaver]

Got ours on Friday and gave it to the programers on Sunday. They're happy with the initial testing. We have the same question on distance. Will have to test. Short distance and short period of time.

[AustinH]

Originally Posted by dellagd

2607 is very excited to get working with their board when it arrives this coming week!

Question though: Given the high accuracy of the device, has anyone attempted to do distance estimation from a double integration of the accelerometer data? I'm curious how it would perform, even for small distances.

If you guys do come up with any theories on how to do that, we would be very, very interested to help with testing...

[Trevor4004]

My team recently received our navX board and we are very excited about the possibilities it will give us. However, the power LED on the RoboRio turns a solid red when we plug it directly into the MXP area of the RoboRio as described in the Plug-n-Play section of the navx-mxp wiki (https://code.google.com/p/navx-mxp/wiki/RoboRioInstall). The RoboRio User Manual says that a solid red for the power LED means "Fault condition detected. One or more user voltage rails are in short-circuit or overcurrent condition."

Our first thought was that the short-circuit or overcurrent problems were due to some strange interaction between the naxv board connecting to the RoboRio via MXP and our daisy chain going from the RoboRio to the PDP and containing 4 talon srxs and the PCM. But this doesn't seem to make a lot of sense considering this board is supposed to be designed to work with the RoboRio for FRC and a daisy chain of 4 talons and the PCM seems like a common setup in FRC.

We can still connect to the robot with out driver station, and we get full communication and robot code when we do. We are able to drive the robot around normally, but we are worried about trying to test the navx in our code until we can determine why the RoboRio is detecting a short-circuit or overcurrent condition. Any insight into why the RoboRio is detecting these problems would be greatly appreciated. Thank you.

[AustinH]

Originally Posted by Trevor4004

My team recently received our navX board and we are very excited about the possibilities it will give us. However, the power LED on the RoboRio turns a solid red when we plug it directly into the MXP area of the RoboRio as described in the Plug-n-Play section of the navx-mxp wiki (https://code.google.com/p/navx-mxp/wiki/RoboRioInstall). The RoboRio User Manual says that a solid red for the power LED means "Fault condition detected. One or more user voltage rails are in short-circuit or overcurrent condition."

Our first thought was that the short-circuit or overcurrent problems were due to some strange interaction between the naxv board connecting to the RoboRio via MXP and our daisy chain going from the RoboRio to the PDP and containing 4 talon srxs and the PCM. But this doesn't seem to make a lot of sense considering this board is supposed to be designed to work with the RoboRio for FRC and a daisy chain of 4 talons and the PCM seems like a common setup in FRC.

We can still connect to the robot with out driver station, and we get full communication and robot code when we do. We are able to drive the robot around normally, but we are worried about trying to test the navx in our code until we can determine why the RoboRio is detecting a short-circuit or overcurrent condition. Any insight into why the RoboRio is detecting these problems would be greatly appreciated. Thank you.

Have you considered plugging it in via the onboard I2C/SPI ports instead of the MXP? IIRC, we're going to be attempting that due to the less than ideal mounting location of our RoboRio. You'd have to supply the board with its own power, but it could be useful for troubleshooting purposes.

[slibert]

Originally Posted by AustinH

Have you considered plugging it in via the onboard I2C/SPI ports instead of the MXP? IIRC, we're going to be attempting that due to the less than ideal mounting location of our RoboRio. You'd have to supply the board with its own power, but it could be useful for troubleshooting purposes.

AustinH, you could also consider using a MXP extension cable. This would allow you to continue to use the expansion ports on the navX MXP - which you won't be able to do if not connected to the MXP connector. There's more info on alternative mounting options here.

[slibert]

Originally Posted by Trevor4004

My team recently received our navX board and we are very excited about the possibilities it will give us. However, the power LED on the RoboRio turns a solid red when we plug it directly into the MXP area of the RoboRio as described in the Plug-n-Play section of the navx-mxp wiki (https://code.google.com/p/navx-mxp/wiki/RoboRioInstall). The RoboRio User Manual says that a solid red for the power LED means "Fault condition detected. One or more user voltage rails are in short-circuit or overcurrent condition."

Our first thought was that the short-circuit or overcurrent problems were due to some strange interaction between the naxv board connecting to the RoboRio via MXP and our daisy chain going from the RoboRio to the PDP and containing 4 talon srxs and the PCM. But this doesn't seem to make a lot of sense considering this board is supposed to be designed to work with the RoboRio for FRC and a daisy chain of 4 talons and the PCM seems like a common setup in FRC.

We can still connect to the robot with out driver station, and we get full communication and robot code when we do. We are able to drive the robot around normally, but we are worried about trying to test the navx in our code until we can determine why the RoboRio is detecting a short-circuit or overcurrent condition. Any insight into why the RoboRio is detecting these problems would be greatly appreciated. Thank you.

This sounds like a short between one of the power (or potentially signal, if active) pins and one of the ground pins on the navX MXP's MXP Expansion connectors. This could be any of the DigitalI/O\PWM\QuadEncoder, Analog In, Analog Out, I2C, SPI or TTL UART connectors. In this case, the navX MXP's RED Power LEDs, and green S1/S2 LEDs will be all off - the navX MXP isn't getting any power from the RoboRIO in this case, because the RoboRIO is protecting itself from a short. The RoboRIO appears well-designed to deal w/this case.

Note that the RoboRIO can be powered via USB, in which case the navX MXP's sensors and microcontroller will work, even if there's a short on the MXP Expansion voltage rail. But in this case, the voltage on the navX MXP expansion connectors will be unavailable, so you won't be able to communicate w/the RoboRIO from the navX MXP via the TTL UART / I2C or SPI interfaces - and you won't be able to use the navX MXP expansion connectors. You'll be limited to using USB unless the source of the short is found and corrected.

So work on finding any shorts, I believe this is the source of the issue you are seeing.

[Tom Line]

Is it possible to download the nav6 files with a single click?

As far as I can see, the locations linked from the product webpages are SVN repositories, and most teams haven't ever used one (including us). Just looking at how to set up a SVN GUI client to get those files is fairly overwhelming, and clicking through each link individually to download the raw file is a royal pain.

If I'm missing some easy way to download these files, let me know. Goodness knows it wouldn't be the first time.

[Joe Ross]

Originally Posted by Tom Line

If I'm missing some easy way to download these files, let me know. Goodness knows it wouldn't be the first time.

From the nav6 or navX main page, click the latest build link.

[Tom Line]

Thanks Joe. I read through the main page 3 times and never looked in the left pane =/.

[bmammen]

We started playing with the example code tonight, trying to use the navX to Auto-Rotate to an angle but we're having an issue where no matter what values we use for PID, the bot rotates to the angle and constantly shakes back and forth trying to reach the exact angle.

I can post our code if that helps, we're using C++ and have a 4 motor/4 transmission tank drive configuration on our test chassis. Hoping someone might have some ideas for us. Thx.

[cjl2625]

Originally Posted by bmammen

We started playing with the example code tonight, trying to use the navX to Auto-Rotate to an angle but we're having an issue where no matter what values we use for PID, the bot rotates to the angle and constantly shakes back and forth trying to reach the exact angle.

I can post our code if that helps, we're using C++ and have a 4 motor/4 transmission tank drive configuration on our test chassis. Hoping someone might have some ideas for us. Thx.

I once had a similar problem with rotating swerve modules with PID.
The problem ended up being that the loop time was really long, like 300 ms.
Since it took so long to update, it repeatedly overshot the target and shook back and forth.
In my case, it turned out that this was being caused by an error, because I didn't configure something correctly in the drive encoders. So the code seemed to be quietly throwing errors which drastically slowed down the iteration time.

[jojoguy10]

Not sure about anyone else, but the NavXMXPUI program isn't working for our team. When I try to run the .bat file, it says it can't find a file.

Is there a KNOWN working version somewhere?

Thanks!