Linux sensor data, A STAR 32U4 Prime SV w/accel/gyro/magnetometer board

Compile/upload OK, blink works OK. When running the sensor sketch, no results appear. Scope shows no activity on the SCL/SDA pins (both are at 5V). What do I need to do to read the sensor results?


I am sorry you are having trouble getting your system working. From your email, it sounds like you are having trouble detecting your MinIMU-9 v5. How are you supplying power to the MinIMU? You mentioned you tested your A-Star with the Blink sketch, but which example sketch are you trying to run to test the sensors on the MinIMU? Can you post pictures that show your connections?


Jon: Sketch is MiniMU9AHRS, Arduino 1.8.1. Power is supplied from the A STAR board +5V to the MiniMU board’s Vin pin. Both Vdd and SA0 are left open on the MiniMU board. GND connection is good, with +5V confirmed appearing at the Minimu board. As mentioned, I detected no SCL or SDA activity, but possibly could have missed it. These are both pulled high as measured on the Minimu board and are connected from the A STAR board’s pins 2 & 3, marked SDA and SCL. Verify/upload both work OK, but the serial monitor shows no activity. I notice that some initial register configuration is said to be necessary for the sensors to turn on, but don’t know how to do this, which could be the problem, despite having studied the referenced documents.

The sketch should take care of register configuration if it is set up properly. Have you uncommented line 32 (// #define IMU_V5) of the MinIMU9AHRS.ino sketch? Our comments above that line instruct users to uncomment that line if they are using the AltIMU-10 v5 or MinIMU-9 v5. If you have already done that, or uncommenting it does not help, can you post pictures that show your connections?


Jon: These are the best photos I could manage. FYI, I’ve tried everything I could find about proper setup of Linux tty with no results. The appropriate uncommented line has been done since the beginning, as well as adding my name to the dialout group per the instructions.
Just discovered past Linux reported problems with serial port, presumably long since fixed. Will try a Windows PC next to see if the problem occurs there or not.
Any help appreciated.



It looks like your pictures were not successfully uploaded, though it looks like you pasted the path to them from your computer. The forum allows for dragging and dropping files into the body of a reply, which you might find more convenient for uploading images.

I do not suspect that the problem is between your computer and the A-Star, since you can upload sketches to the A-Star just fine. However, if you want to verify, you can try running a different sketch that does stuff over serial.


Jon: Switched to Windows with identical results. I suspect either a bad connection to the sensor board or possibly a bad sensor board or even a main board’s I2C capability. Serial link between the PC and the main Pololu board is OK. No need to bother with the pictures just yet. I’ll recheck connections with a meter/scope (dynamically). If I still find no activity on the SCL/SDA pins, I’ll get back to you. I think we have a unique situation here.

Jon: Have now confirmed that the connections are good from the Atmega processor to the SCL/SDA pins at the board edge and that there is no activity on these pins at any time. Both are pulled up to 5V. As mentioned previously, the symptoms are identical regardless of whether I’m using Linux or Windows. There is no attempt on the part of the processor to launch I2C. I’m still investigating, but not sure I’ll be able to resolve the problem. Just discovered others with the same problem, per the following link:
I’ll pursue this direction for now.

We have not encountered the problem described in that Arduino forum thread (we use USB and I2C at the same time on the A-Stars regularly), nor is it common for the pins to stop working (though it’s possible something like ESD could have damaged them). Can you try running the Serial example sketches from the LSM6 and LIS3MDL Arduino libraries, and see if you get any output? Also, if you have different Arduinos, can you try running those sketches on them to see if the MinIMU is working with them? If you have other I2C devices, can you try to get the A-Star to communicate with them?


Jon: Tried the LSM6 and LIS3MDL, same results. Sorry, I have no other boards or I2C devices at this time. What do you suggest at this point? FYI, I was very careful about ESD, but I guess that’s always a possibility.

Can you try uploading again the pictures that show how you have your A-Star connected to your MinIMU? I want to double-check that the soldering joints look fine, and generally be on the lookout for anything obvious we might be missing.


Jon: Unfortunately, my photos are not good enough to show you what you need to know. FYI, I have 38 years experience as a EE in all phases of design: analog, digital,RF, PCB layout, simulation, circuit design etc. In this case, I have a bad board. I will simply order another one and retest. This will answer the question of just where the problem is. I will eat the cost in this case, since we really don’t know why the board failed. If you prefer, I’ll send it back to you for analysis. Let’s move on from here; thanks for your help.

I understand if you just want to try again with a new unit at this point, and we can probably at least help you out with a discount on a new unit (I just sent you an email about that), but we would also still be happy to continue troubleshooting this old unit in case the problem is something that is easily fixable.


Jon: This sounds like a good plan. The discount is appreciated and I will advise you re the results of testing the new board. This time ordered it with the headers installed to minimize the possibility of ESD damage from excessive handling.

Jon: OK, success! The new board works as advertised! I need to focus on the new one for now, but will entertain any suggestions you may have for troubleshooting the old one, as long as it isn’t too time consuming. I’ll be happy to send it back to you if you prefer as well. I do, however, have a “non-critical” question:
Just how do I get pytest going? I assume that I need to run the data collection as usual, then tell it to begin the pytest. No luck so far, but not really important.
This is not critical to my project, but I wanted to bring it to your attention.
General test results so far:
roll/pitch: Directions appear reversed from those indicated in the code and they “limit” at about 27 deg or so, otherwise Ok.
yaw: Ran the calibrate sketch, followed by the gyro/acce/heading program. After about 5-10 minutes, the yaw output is drifting slowly, maybe 1 deg/min or so. If I then rotate the board in the yaw direction 90 deg, it increases about 45 deg from the current starting value. I’m a lifelong aviator as well as an engineer (avionics included) and am curious why the yaw value drifts when there is no motion around this axis, since the magnetic heading is constant. I’ve verified that the earth’s magnetic field is visible and essentially undisturbed for this test.
Maybe you can shed some light here.
Thanks for your help,

I am glad the new board is working well.

What do you mean by “pytest”? (What is the specific name of the code or software you are trying to run?)

If roll/pitch are reversed, can you double-check that your SENSOR_SIGN[] axis definition inside MinIMU9AHRS.ino matches the orientation you are using your MinIMU in?

There should generally be no drift if you are incorporating the magnetometer to estimate heading like the AHRS code does, so it sounds like suboptimal magnetometer calibration. The calibration routine requires that the compass be rotated in all directions while the sketch is running. For me, it helps to imagine I have to paint the entire inside of a basketball with the tip of the MinIMU-10. Can you try calibrating again, keeping that in mind, to see if it helps?


Jon: Pytest is being used for the visual representation of the output of the Minimu-9AHRS, as explained in he documentation. I haven’t been able to locate/figure out how to launch this.
The SENSOR_SIGN[] axis definition does match the orientation I’m using. The roll/pitch directions of rotation are opposite those described in the definition, but the magnetometer direction looks OK. It’s not important, but I’ll revisit it in any case.
I’ll try the calibration routine again. Is there any documentation that describes this? Otherwise I’ll assume that I’ll just slowly rotate the board while this routine is running, followed by running the Minimu-9AHRS sketch. Let me know if this isn’t correct.
Finally, is there any way to remove the apparent “limiting” of the pitch/roll outputs so I can reach, say, 70deg of travel?

It sounds like you are asking about how to run “”. (I don’t think we call it pytest in any of our documentation; if we do, could you please point it out so we can correct it?)

Make sure you have Python and all the required libraries installed, as described on the GitHub page, and edit the file to change the definition of ser to match the COM port your Arduino is using. Note that the Python program will not be able to connect to the A-Star if the COM port is already in use, which will be the case if the Arduino’s serial monitor is running. Then, to visualize the output of the AHRS, you can run (e.g. double-click the file) while your A-Star is connected to your computer and running the MinIMU9AHRS sketch.

Neither the flipped directions nor the limited pitch/roll angles you are getting sound normal (pitch should cover +/-90 degrees and roll should cover +/-180 degrees). If those continue to be issues, we can work on figuring out what’s causing them.

-Jon” is correct. Pytest was just a reference to this type of test mentioned in another blog, not important.
Flipped directions: Changed the uncomment to the 2nd one shown in the file, which matches my intended application.
Results: No more limiting, directions as follows:
Pitch: Nose up produces increasing positive numbers (code says it should be nose down)
Roll: OK
Yaw: Also OK, except that a change of about 90 deg physical movement produces a reported change of ~55 deg.
Can’t quite get the test function to run correctly. I get the initial pictorial showing the colored horizontal lines for pitch/roll and the yaw compass layout, but these all become “greyed out” after a few seconds. Also, they don’t respond to any physical movement during the short time they’re visible. Running Ubuntu 16.04/Python 2.7. Any t-shooting suggestions would help. FYI, I did notice that, when running the file, I saw an error message stating that it was unable to make the conversion between “str” and “float” at this line in the file : L1.text = str(float(words[0])).
I just found a previous link where you suggested that replacing VPython 6 with version 5 should fix this problem; I may try this next. Note that all the IDLE examples work OK; only the MinIMU-9 test file has a problem.
Finally found another blog suggestion to just add “rate(100)” into the main while loop. This now works! Problem solved!

Hi, Steve.

I looked over the comments in the AHRS program, and I think the comment that says that nose down should produce positive pitch is wrong (and so is the one that says counterclockwise yaw is positive). After all, the point of the different SENSOR_SIGN definitions is to make the program report consistent angles regardless of the way the board is mounted. So in all cases, it should be:

// Positive pitch : nose up
// Positive roll : right wing down
// Positive yaw : clockwise

and at this point, I think the directions you see are correct. (Thanks for noticing this; I’ll fix the comments in the code.)

Your yaw problems are probably due to the magnetometer still not being calibrated well. You might try running our calibration program again to see if you can improve your results, although it sounds like you’ve already tried a few times.

In general, calibrating a magnetometer can be tricky, and the method that we use in our examples does not always work well. We would like to eventually provide a better tool for magnetometer calibration and make it easier to use the calibration data in an AHRS program, but we don’t have any specific plans for those right now.

If you are interested in trying to work out a better calibration method, you might want to take a look at the ongoing discussion in this thread.