Hi all,
I've been lurking here for years getting help for my arduino projects from previous forum posts. I have just created an account to post a question because I seem to be out of options for this project.
I have built a balancing segway robot, featuring the mpu6050 for the angle measurements. I got it to work just fine with just the basic setup (one arduino Uno, a motor shield, and the mpu6050 connected as a slave over i2c). I was using PID control, but recently learned how to use state space and wanted to modify the project. With the inclusion of wheel encoders and an xbee module, I was all out of pins to accomplish what I needed with the Uno, so I added a pro-mini board to the prototype area of the Xbee shield and decided on a new concept to make it all work together.
My idea is to use the pro-mini as just a measurement acquisition device, which will maintain current values for the wheel position from the encoders and the angle/gyro measurements from the mpu6050. Because the mpu6050 is only a slave device, the Pro-mini was set up as the master on the i2c bus. The tricky part is getting the measurement data from the Pro-mini to the Uno. I decided to make the Uno as another i2c slave device and just transfer new measurement data to it each time the values are updated on the pro-mini. I handled all of this with receive events on the Uno, and through some debugging, the system seems to be more or less working as I intended, although some things still are unsettling about it.
The measurements are being updated so frequently that the i2c receive event interrupts are causing some major disruptions in the code execution of the Uno, and sometimes slowing loop times down unacceptably for the control strategy. Although it seemed like the best strategy at the time, since updated values will always be available when calculations are needed, I now wish I could just constantly update the measured values on the Pro-Mini and only transmit to the Uno when the Uno requests the data, as part of its main loop operation. This, however, would require the Uno to also be a master on the bus...and this is where I am left scratching my head...
There is constant activity on the i2c lines from the Pro-Mini getting data from the mpu6050 and I'm not sure if it would be feasible to have a multi-master setup on this project. If the Uno is set up as a master too, would it have to be able to detect the line in use before sending a request? I haven't tried implementing this yet, but I postulated the Uno would have erratic luck sending requests to the Pro-Mini and receiving data, given the frequency of data updates from the mpu6050.
I have decided that a last resort may be adding an interrupt on the Pro-Mini, connected to a digital line of the Uno. When the Uno requests data, it can set the digital line, and the Pro-Mini could then write to the Uno via i2c.
At first, even if just out of curiosity, I would like to flesh out this multi-master idea and see if anyone has advice or experience with such a setup.
Attached is a picture of the little guy I'm working with. I designed the whole thing a few years ago and 3D printed the body, motor mounts, etc.
I took a great controls class last semester, which sparked my interest in resurrecting the project. I'm also almost done writing a python GUI to control the robot wirelessly via the Xbees.
Please let me know any ideas or suggestions for this project.
I can also supply the code I have so far. It is quite long, so that's why I neglected to include it here.
Here is a link to the picture, because I didn't realize you had to download the file to see it.
https://drive.google.com/open?id=0B1X3D227-XxdSUVEekFsTXU0aXM
