Hi there! Finally you can pre-order the ArduIMU V3 here.. You can find more info abut it in my last post here.
The final version of the board for full production is here, I'm expecting to start shipping them this Friday or Monday.
We are still working on documentation and giving the final cosmetic touches to the example code to have it ready before you have one in your hands and at the same time we are shipping samples to developers to do a full DCM integration.
From now on our new color will purple! All our new products will feature a Lilypad style look!
(Note: this is a stand-alone IMU, and is not designed to be a replacement for the "Oilpan" IMU shield of ArduPilot Mega.)
Comments
I got a MKII and uploaded the bootloader again. The board works nows. For some reason the lockbits were set such that the boatloader could be overwritten. So be carefull...I changed now the lockbits to protect the bootloader.
No need to tweak it, that #$%^ works.
I just ran the module for a longer period of time and the angles that come out are very consistent and consistently move when I move the board around. I consider it resolved for my board by using this other breakout, but will remember to pay attention to it anyway when I hook this up to a HUD with lines (makes it easier to detect these).
Ok thanks.
For me, when the external sensor is attached, the false dips in the messages from the MPU6000 happen very regularly..more than half the time. The values from the external sensor always get through to the 2560 properly.
Looking quickly at the svn mentioned by Chris above, doesn't look like there are libraries and example sketches like there are for the ArduCopter and ArduPlane code so you can't just fire up the MPU6000 example sketch to see what values it returns. Anyway, when you get to that point we will see!
By the way, on the APM2 there's actually a 2nd SPI port used for the dataFlash that I can fall back on worst case (but the wiring is messier). I wonder if the ArduIMU has the same thing...
Hi Randy,
Ok, I understand. I don't have oscilloscope here, so can't check at that level. Prior to this, neither the MPU6000 or the ethernet initialized even. Right now, the initialization does take place consistently and the data stream through ethernet is also stable. I haven't yet verified that the values I do get make sense, so I still need to do that to be sure.
Do these false dips happen all the time for every SPI transfer? If it is consistently dipping, then I'd expect some spurious values to come out at times without the board having moved. That'll help me limit it down.
@Gerard,
Yes, I'm using the APM2 but it's quite similar to the ArduIMU v3. They both use the MPU6000, same level converter, etc. We also both have the same issue.
Have you checked the values coming from the MPU6000 are now not-garbled when your ethernet board is attached?
@Randy: Your device is an APM v2.0 though right? not the ardu imu v3?
Guys, Jose has ported the ArduIMU 2 code to support the ArduIMU 3 (just DCM, not using the internal DMP yet). It's not ready for public release yet, but if you want to try it, it's in the SVN repository now.
Gerard,
Really? I'm surprised. And you're no longer seeing garbled messages from the MPU6000? My 2nd SPI device (optical flow) is actually a 3.3v sensor...
Just received the new Sparkfun WIZ811MJ ethernet breakout and it's now working with the SPI_En pin coupled to the /CS line (check version there too). So SPI now initializes ok, ethernet works to send packets. Haven't run this for a very long amount of time yet, but it appears to work ok now.
@Randy: Your picture appears to be the APM 2.0. Chips are probably the same, but I'm not sure if the circumstances are. The WIZ811MJ is powered through 3.3V, so perhaps the only important difference is whether the 2nd SPI device is powered by 5 or 3.3V.
-
1
-
2
-
3
-
4
-
5
of 19 Next