Page 1 of 1

Needs ready to roll firmware package that includes MPU9250 fusion driver.

Posted: Sun Feb 03, 2019 8:03 pm
by tiensz
I'm a DOS plodder from way back to the PC's birth.
Before then, I did my thing with Apple Basic on an Apple II. I did some serious test control software with the Apple II clones.
Then life happened, and jobs changed, and design and coding became a bucket list thing. But now I'm retired, and it's time for the bucket list.
Now, I've got a nice project that I want to do. It involves reading and recording data from several IMU's. It started off with Arduino Nano's and early on realized the importance of utilizing the fusion processor inside the IMU. But I needed a high data bandwidth (min 100 Hz, but hell, the IMU can do 1kHz accelerometer readings)
So I started looking at the Py Zero running Python. But nope, it's not a RTOS, so the recording will 'stutter'.
My quest then was for a micro that's easy to program, real time, tiny, powerfull and frugal. And the ESP8266 running MicroPython seems to be what I need. (Yes, I realize that garbage collection will still cause a stutter, but way more controllable than an underlying OS will).
And yes, there's https://github.com/tuupola/micropython-mpu9250 or https://pypi.org/project/micropython-mpu9250/ which appears to be right stuff.
And here's the crunch:
For two weeks now I've been mired in Linux (Greek to me) trying to figure out how to get those modules added to the firmware. I went through installing virtual boxes and vagrants and dead ends and Linux warnings and errors and threats and failures............
I really tried to research and do this on my own, but the time has arrived to ask for help.
What I ask for is this: Firmware (the .bin file) that's based on the latest stable release of MicroPython for ESP8266 but with the MPU9250 module included. @pythoncoder mentions that he used 'frozen bytecode' but not how he did it.
Step by specific step instructions with correct URL's also works, thats how I installed the 'stable' firmware originally.
I'm here to program in MicroPython, not learn Linux.

Re: Needs ready to roll firmware package that includes MPU9250 fusion driver.

Posted: Sun Feb 03, 2019 8:24 pm
by Roberthh
It may sound hard, but you have to set up your Linux environment to compile and build the firmware yourself. That's not complicated. It is documented in the README.md files in two major leaps:
1. Download amd set-up the Micropython repository. You can use the ZIP package or the good old brain cracker git.
2. Set up the compile image for the ESP8266 port. That is documented in the README of the ESP8266 port subdirectory of the Micropython package.
That is not overly complicated. Since you grew up with DOS, the command line is familiar to you. You could only fail if you do not follow the instructions carefully. Do not skip steps!
Once yo manage that, adding Python modules into frozen bytecode consist of copying that file into the directory esp8266/modules, and rebuild the micropython firmware.

P.S.: I know what I am talking about. @pythoncoder and me are both silversurfers.

Re: Needs ready to roll firmware package that includes MPU9250 fusion driver.

Posted: Sun Feb 03, 2019 9:17 pm
by OutoftheBOTS_
You might be super interested in this little IMU/fusion board. It has a EM7180 SENtral sensor fusion hub combined with an MPU9250 9 DoF motion sensor. https://www.tindie.com/products/onehors ... n-mpu9250/

The guy that created it has a PHD in robotics and has spent a lot of time testing every different IMU and fusion algorithm on the market and ended up creating his own complete hardware

Re: Needs ready to roll firmware package that includes MPU9250 fusion driver.

Posted: Wed Feb 06, 2019 1:15 pm
by tiensz
@OutoftheBOTS Thank you very much, but with postage etc, this module is 10 times the price of a MPU-92/65.
For now my mission is to get the host processor going. (See below)

@Roberhh After calling it quits to roll my own package, your reply changed my mind.
It took a long time, but I've actually got the firmware loaded, and a working serial REPL. In fact, I've tried two different packages for the MPU stuff. They are:
https://github.com/micropython-IMU/micropython-mpu9x50 (Containing: imu.py, mpu9150.py, mpu9250.py and vector3d.py)
and
https://github.com/tuupola/micropython-mpu9250 (Containing: ak8963.py, mpu6500.py, mpu9250.py and setup.py {is this setup.py part of the modules, or is to be run before package inst. ? idk})
But, I have serious suspicions about the integrity of my home-brew firmware. I'll elaborate:
The current firmware contains micropython-IMU/micropython-mpu9x50 modules.
I'm reading the README.md from this repository and runs into trouble straight away:
The software was apparently written for the pyboard, and the wiring instructions only says that SCL on pyboard must connect to SCL on MPU9250, and SDA on the pyboard to SDA on MPU9250. (No pinout or gpio number.) . The pin diagram here: ttps://escapequotes.net/esp8266-wemos-d1-mini-pins-and-diagram shows a pink diamond <SCL> at [GPIO5 ESP_Pin20 D1] and <SDA> at [GPIO4 ESP_Pin19 D2].

ESP8266 MPU9250
5V to 5V
GND to GND
D1 to SCL
D2 to SDA
So, the assumption is: SCL on Pin20 and SDA on Pin19 right?

>>>from machine import I2C, Pin
>>>i2c = I2C(scl=Pin(20), sda=Pin(19), freq=100000)
Traceback (most recent call last):
ValueError: invalid pin

https://docs.micropython.org/en/latest/ ... hine%20pin tells me that I should use the GPIO pin numbers. Silly me.

>>>i2c = I2C(scl=Pin(5), sda=Pin(4), freq=100000)
>>> #ah that worked.
>>>i2c.scan()
[104] #right, we're seeing the IMU
>>>

Ok, we're connected to the IMU. Now let's run the first Usage example from the README.md

>>>import utime
>>>from machine import I2C, Pin
>>>from mpu9250 import MPU9250
>>>i2c = I2C(scl=Pin(22), sda=Pin(21)) #see where I got that Pin(20) and Pin(19) from earlier on?
Traceback (most recent call last):
ValueError: invalid pin

try other way:
>>>i2c = I2C(scl=Pin(5), sda=Pin(4)) #swapped numbers to their GPIO values.
>>>sensor = MPU9250(i2c)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "mpu9250.py" line 47, in ___init___
File "imu.py", line 105, in ___init___
File "imu.py", line 161, in chip_id
ValueError: Bad chip ID retrieved: MPU communication failure

And this is where I am at the moment.
I suspect that I might have a 'Baudrate' problem here. This would be what I'll investigate now.
I will also see what data was received, and expected (chip_id)

What bothers me most is that the example obviously worked with Pin(22) and Pin(21). Is there a inconsistency between MicroPython flavours?
The following paragraph extracted from https://docs.micropython.org/en/latest/ ... hine%20pin :

"Available pins are: 0, 1, 2, 3, 4, 5, 12, 13, 14, 15, 16, which correspond to the actual GPIO pin numbers of ESP8266 chip. Note that many end-user boards use their own adhoc pin numbering (marked e.g. D0, D1, ...). As MicroPython supports different boards and modules, physical pin numbering was chosen as the lowest common denominator. For mapping between board logical pins and physical chip pins, consult your board documentation."

I guess that answers my question: I will have to compare the diagrams between the esp8266 and pyboard to find the correct Pin(value).

Re: Needs ready to roll firmware package that includes MPU9250 fusion driver.

Posted: Wed Feb 06, 2019 6:09 pm
by pythoncoder
The IMU and sensor fusion modules were written when the only platform capable of running MicroPython was the Pyboard, although we subsequently updated them to make them cross-platform. But the docs refer only to the Pyboard. There are now so many boards supporting MicroPython that people do need to establish appropriate pin references for their hardware.

Note that I2C can be implemented as software I2C or hardware if the platform supports it. The baudrate defines the maximum clock rate. So long as it is no greater than the datasheet maximum of the device it will work. It's not critical in the way that UART baudrates are since there is only one clock, generated by the MicroPython host. A low baudrate won't stop the interface from working.

If you need high update rates you might want to benchmark the speed of the Madgwick fusion code. There is a significant amount of maths involved.

Re: Needs ready to roll firmware package that includes MPU9250 fusion driver.

Posted: Wed Feb 06, 2019 6:20 pm
by tiensz
After more digging I realized that I will need to 'augment' the pull-up resistors. I've added 5k1 between scl and +3.3V as well as sda and +3.3V. I used the 3.3v Pin(8) on the ESP8266 for this.
But, still no joy. Except that the traceback message ends with: MPUException: No MPU's detected.
I believe that I've gone off topic way back already.
I will open a new topic a bit later on.