Index

MicroWorks 30B4 board

  1. Datasheets 30B4
    1. STM32F103
      1. ADC
      2. STM32 EEPROM
    2. MPU6050
      1. DMA
      2. Issue communications
        1. 01
    3. MPU6050 freq
  2. firmware motor control
  3. Implementations with MicroWorks 30B4 board
  4. Links to sellers

MicroWorks 500W 30km/h motor

  1. BEMF measurements

Flash and Debug STM32

  1. Eclipse IDE and JTAG
  2. Unlock STM32F103 with JTAG
  3. Flash firmware using Bluetooth
    1. STM32F103C6T8 bootloader
    2. ZS-040 Bluetooth module
      1. HC-06 hc01.comV2.0
  4. Serial Port Bluetooth
  5. Serial Port Plot
  6. SM32F103C8T6 use 128kbytes flash

FOC

  1. Observer
  2. Shane Colton documentation and firmware
    1. Firmware
    2. Part 1: Field-Oriented
    3. Part 2: Field-Oriented
    4. Sensorless Pneu Scooter - part 1
    5. Sensorless Pneu Scooter - part 2
    6. Sensorless Pneu Scooter - part 3
  3. Texas Instruments videos
  4. Chinese controllers code

Balance controller

  1. Chinese balance group reference design
  2. Kerry D. Wong -- A Self-Balancing Robot
    1. A Self-Balancing Robot – I
    2. A Self-Balancing Robot – II
    3. A Self-Balancing Robot – III
  3. Self balance bicycle
  4. PID
  5. LQR
    1. Stages of development of the robot-balancer
  6. PID and LQR, MATLAB
  7. Steve Brunton videos

Mechanical parts

  1. Pedals

Various

  1. C language for critical systems
  2. Hall effect sensor placement
  3. The brilliant idea of slow rotating motors
    1. Why does the Torquemax rotate so slowly and so forcefully
  4. Finding Motor Phase-Sensor Combinations

Clipping

  1. Hackaday - 2017.05.07 - opensource firmware for hoverboards

MPU6050 freq


---

I think you will have to change your I2C frequency to 400KHz (max is 500KHz), only read accelerometers, configure the MPU sample rate to 350 Hz or higher, configure the MPU low pass filter to 175Hz or higher and check the accelerometer range so that it does not saturate.

Yes, the MPU6050 can have a sample rate of 1 KHz if you are able to read values out at that speed. It will be difficult if you are reading every gyro and accel every time and you are using I2C.

Your MPU allows a sample rate of 8kHz only for the gyrometer, the accelerometer allows only 1kHz.

Given you use 400kHz I2C speed, the highest data rate to read all values is theoretically 2.61kHz, 2.96kHz if you omit the temperature reading (15 bytes must be transmitted, needing 9 clocks each). That's a theoretical maximum that is practically never reached.
If you read only the gyro values (as the accelerometer values aren't that fast anyway) you may reach about 7kHz.

---


I am looking to use the MPU6050 on a self balancing bicycle. I am using a PIC micro so can't take the code directly from i2Cdevlib.

I am only interested in the angle in one axis (I'm only interested in roll). I have some questions I was hoping someone could help with:

1. If I'm interested in only one axis and only small angles (+/- 10deg), is it OK to just grab the accelerometer and gyro data for that one axis; or should I still get all 3 and combine for some reason?

I have seen posts for other IMUs suggesting that you should combine readings to get the required angle. For example, assume I am interested in only the X angle, then it suggests something like this:
//Convert Accelerometer values to degrees
    AccXangle = (float) (atan2(*(acc_raw_y),*(acc_raw_z))+M_PI)*RAD_TO_DEG;

But what is incorrect with doing:

AccXangle = (float) ((acc_raw_x / 9.81) * RAD_TO_DEG); // For small angles where sin(theta)
is approx equal to theta

Since I am not interested in full 360deg locus but just small angles, will the second method not work?


I guess I can use the first method but I was curious; and want to know if I really need the overhead of the more complex atan2 function.

2. What is the method to 'zero' the gyro? Since the gyro measures angular velocity, the ang_vel*dt will give change in angle, hence needs summing from a known point. So, do I need to put my bike into a 'zero' position and then start the gyro measurements or is there a cleverer way to do it?

If I'm using a complimentary filter in the form:
X_angle = 0.98 * (angle + gyroX_vel * dt) + 0.02 * accXAngle
then if I set X_angle = accXangle for the first loop iteration will that be OK?