Our hope is to use the digital gyro on board using I2C directly to the digital sidecar to aid in autonomous turning. To implement any code (we use Java), we will need to find or build native libraries and bridges to Java. So far here are the resources I have found: https://blogs.oracle.com/acaicedo/entry/beyond_beauty_javafx_i2c_parallax
Does anyone have experience working with this type of device that could offer insight to setting it up for use with an FRC robot using Java? Or just some tips even if you don’t have experience?
I’m confused. The board you linked seems to be an a flight control board that contains an MPU6050 and an Arduino microcontroller. I’ve been looking at the MultiWii website and have not been able to find a description of the I2C interface. You’ll need to find out what the I2c device address is, as well as the map of registers it supports. You may need to modify the Arduino firmware to get access to the data you want. I assume that there is some processing the Arduino is doing which is why you picked it, rather then using the MPU6050 directly?
Then you talk about pi4j, which implies you want to run java on a Raspberry PI. Does this mean that you want to connect the Arduino to a Raspberry PI and then the Raspberry PI to the I2C bus on the Digital Sidecar?
On the robot side, you’d use the I2C class in WPILibJ. The FPGA only supports being an I2C master, which isn’t a problem if you are interfacing to the MPU6050 directly, but may be a problem if you are connecting to another controller that also is designed to be the master. There are several other gotchas to using I2C on the cRIO, so you should spend some time reading related threads on chiefdelphi.
The I2C interface is on the MPU itself and is visible in the picture on the hobbyking website I linked on the top of the green chip. We are hoping that it is possible to go directly from this MPU to the digital sidecar through this I2C port. I do not want to use a Raspberry PI, but I was wondering if that resource would at all be applicable to trying to interface the MPU directly to the sidecar.
So I know nothing about this board beyond what I’ve quickly googled.
If I understand correctly the Multiwii project (on the hardware side) started out basically marrying wii COTS components with an arduino. The software side, flashes a flight controller application onto the arduino which then can talk to RC components to control motors and servos, all with the intention of controlling a multi-rotor copter.
The board you linked to directly appears to be an arduino with a gyro/accelerometer on board, specifically the MPU6050. So you should treat it as such. Forget about the Multiwii software, it’s not likely to be of much help beyond possibly showing you how they interfaced to the specific sensors on the board.
To learn how to use the I2C interface on the DSC, I would suggest searching the CD forums for “I2C”. There have been quite a few good discussions on the topic within the last year. There are even some posts on specifically talking to arduinos through I2C.
Then I think you’re going to have to basically replace the stock firmaware on the board you bought. You should be able to use the arduino IDE to reflash the board with your custom code.
Your going to have to write your own code to interface to the sensors. Or, since the multiwii code is open source, you may be able to take a look at how they interface with the sensors, and just gut all their flight controller logic.
Once you can talk to the sensors through the arduino, then it should be pretty easy to take the data and push it out of the i2c interface.
You should be able to find examples of how to use the i2c libraries on the arduino website.Here’s one there may be better ones. It looks like you need to use the Wirelibrary. Note, you might need to modify the library to match the pins that your i2c interface is actually physically wired to. Your board is running on an Atmega 328p. This pagemay or may not be helpful.
This is all a guess on my part. Should be a fun little hack. I’d be interested in how it turns out. If we end up at the same regional next year, I’ll try to come over and find out how things went. Hopefully districts don’t mess that up too much.
Hah, districts will ruin any chance of that, unless you’re willing to come to Tech Valley Regional in Upstate NY!
Thanks for the tips, at this point I’m mostly looking for gathering a pool of resources to see what else people have done before us and where the best place to start is.
I’ve never used I2c, but I would watch out because the I2C port on the digital sidecar is 5v and the mpu 6050 runs at 3.3 v (I couldn’t tell if that Hobbyking chip converts the i2c to 5v)
This board has the same MPU as the sparkfun board, but takes an input voltage of 5V and drops it to 3.3V for the MPU, so we don’t have to worry about the voltage. This is why we chose this board over the sparkfun one (also it’s cheaper).
We did not have any luck using the KOP gyro. Whether it is a bad piece of equipment or we were not using properly I am not sure, but we fail time and time again to achieve desirable results with the KOP gyro. Too much drift.
The MPU-6050 can be used 2 ways. The raw gyro and accel values can be read from the chip over I2C. The MPU-6050 has a computing engine on the chip. It can give a quaternion output of the fused accel an gyro. The computing engine mused be started up by loading many registers and memory locations. Allot of code. We have used an Arduino Uno to talk to the chip. Look at The Sparkfun break out board to get links to both forms of code. The Mpu-6050 so far seams to be a very stable gyro. There is also the Mpu- 9050 that includes a magnetometer and can give 9 DOF fused quaternion. How ever the mag part is not done on the chip. That has to be done by code on a processor. Many different algorithms to do this. Question? what is the best way to put a 6 byte packet into the C-rio from an Arduino?
This is why I had suggested trying to gut the useful code from the multiwii project. It is open source.
They already have a library for talking to gyros and accelerometers, with code that looks to be for initializing the MPU.
I would spend some time understanding this project and stealing what you can. It likely has 80% of the code you need to get the job done.
Hah, districts will ruin any chance of that, unless you’re willing to come to Tech Valley Regional in Upstate NY!
We will see what the future holds, but I suspect we will want to get in a few matches at a normal regional in addition to districts. I was rading about the Tech Valley Regional in another thread, it’s location could draw some really good teams from the north and east. It could be a nice replacement for CT.
And south and west; don’t forget about NYC, MAR, and FLR teams! We’re in a not entirely inconvenient place for lots of teams to travel to with some easy travel options from any direction.
It seems like the barrier to getting the MPU6050 to behave as a sensor like we want is the device driver software to allow us to even grab values from gyro. We have found some scattered resources throughout the web that have bits and pieces of what we will need, but we will need to figure out what is necessary and what is missing along with how to put it all together.
To be clear the criteria we used when ordering the gyro:
-Cheap (less than $50 a pop; this one is $27)
-Digital output gyro
-Common FRC power supply voltage (in this case 5V)
-Way to directly interface with FRC control system (in this case I2C through the DSC)
-At least 500 dps (This one is configurable to 250, 500, 1000 or 2000 dps…another one of those register things we need to configure)
On top of that this particular MPU had some positive reviews for its motion sensing and there were some projects that had been done out there. I also have heard that some FRC teams have used the exact board that we purchased, I was hoping to maybe hear from some of them here.
I’m not a programmer but as someone who is familiar with multiwii I would probably avoid it and talk directly to the MPU 6050. There are boards like this that can handle a 5v input. I would probably start by looking at the ADXL_345 i2c class and modify that to read the MPU 6050. There communication protocol is similar.