EDTracker2
EDTracker2 copied to clipboard
brumster
Cannot connect to device after flashing
So, I have tried several things, nothing seems to work... I am using Windows 10, I have an Arduino Pro Micro (16MHz) built on a protoboard with a MPU-9250, following the guide and wired all pins as described...
Then here's what I did:
- Downloaded the EDTracker UI 4.0.4.0 and run it as administrator
- Chose EDTracker2_9250 4.0.5 from first drop down
- Chose port where "Arduino Leonardo" was detected
- Click "Flash"
A popup window comes up with a bunch of messages and a progress bar at the bottom, process appears to finish fine, however, there's no way to actually "connect to tracker"...
There's the big "NOT CONNECTED" at the top, and clicking the "CONNECT TO TRACKER" button below, will change the words at the top of the head below from "DISCONNECTED" to "CONNECTED", but nothing else happens... no movement of the head, nothing...
I also tried using the Arduino IDE (1.8.12). I downloaded the hardware from https://github.com/brumster/EDTracker2_ArduinoHardware and placed it where it belongs. Chose the board "EDTracker 9250" and was able to flash the latest from master from this repo, which appears as 4.1.1
After trying to use EDTracker UI for calibration... same thing as before... port is detected, but cannot connect...
Also, tried uncommenting the //#define DEBUG line in the Arduino .ino file and flashing that, but for some reason, there's no debug information anywhere... nor the Arduino Serial monitor, nor the EdTracker UI... Tried showing the "Log", nothing is printed in there ever... Also tried the "About" -> "Mode" -> "DEV"... still nothing...
The only thing I was able to see, was that after enabling this "DEV" mode in EDTracker, there's a "debug" you can flash, and I was able to see a "Hello World" in the Arduino Serial Monitor and dots being printed every second... but that's it...
I am a bit stuck at this point, not sure how to diagnose where the problem might be...
I built my own EDTracker just a few days ago, and have encountered the very same problem. It's like the Arduino side of things is working fine, but the MPU-9250 isn't working, or at least is not communicating with the Arduino.
My conclusion was that maybe I messed something up somehow, or that possibly the solid-core hookup wire I used might have fractured somewhere (I had a couple break off during construction, leading to a bit of last-minute jerry-rigging). So, I've decided to dismantle it and rebuild, once some new soldering equipment (and multi-strand hookup wire) I've ordered has arrived.
Having read this, before rebuilding, I'm going to breadboard the whole thing and test it before assembly. I'll let you know how it turns out. And if you manage to find out what's going on, please post it here.
@Garryck So, I have tried the "MPU9250BasicAHRS_I2C" example that comes with the Sparkfun library. I am able to get values from the sensor properly, so I am guessing Arduino and the MPU are properly wired... Below is the serial output when the program begins:
11:21:06.720 -> MPU9250 I AM 0x71 I should be 0x71
11:21:06.720 -> MPU9250 is online...
11:21:07.052 -> x-axis self test: acceleration trim within : 0.8% of factory value
11:21:07.052 -> y-axis self test: acceleration trim within : -1.3% of factory value
11:21:07.052 -> z-axis self test: acceleration trim within : 3.4% of factory value
11:21:07.052 -> x-axis self test: gyration trim within : -4.2% of factory value
11:21:07.052 -> y-axis self test: gyration trim within : -0.5% of factory value
11:21:07.052 -> z-axis self test: gyration trim within : -0.5% of factory value
11:21:07.849 -> MPU9250 initialized for active data mode....
11:21:07.849 -> AK8963 I AM 0x48 I should be 0x48
11:21:07.882 -> AK8963 initialized for active data mode....
11:21:07.882 -> X-Axis factory sensitivity adjustment value 1.17
11:21:07.882 -> Y-Axis factory sensitivity adjustment value 1.18
11:21:07.882 -> Z-Axis factory sensitivity adjustment value 1.13
11:21:07.882 -> AK8963 mag biases (mG)
11:21:07.882 -> 0.00
11:21:07.882 -> 0.00
11:21:07.882 -> 0.00
11:21:07.882 -> AK8963 mag scale (mG)
11:21:07.882 -> 0.00
11:21:07.882 -> 0.00
11:21:07.882 -> 0.00
11:21:07.882 -> Magnetometer:
11:21:07.882 -> X-Axis sensitivity adjustment value 1.17
11:21:07.882 -> Y-Axis sensitivity adjustment value 1.18
11:21:07.882 -> Z-Axis sensitivity adjustment value 1.13
11:21:07.882 -> X-acceleration: 0.31 mg Y-acceleration: -33.81 mg Z-acceleration: 1000.98 mg
11:21:07.882 -> X-gyro rate: 0.076 degrees/sec Y-gyro rate: 0.046 degrees/sec Z-gyro rate: -0.099 degrees/sec
11:21:07.882 -> X-mag field: 620.26 mG Y-mag field: 262.68 mG Z-mag field: -263.27 mG
11:21:07.882 -> Temperature is 24.2 degrees C
11:21:08.379 -> X-acceleration: -0.06 mg Y-acceleration: -33.51 mg Z-acceleration: 1002.32 mg
11:21:08.379 -> X-gyro rate: -0.015 degrees/sec Y-gyro rate: 0.053 degrees/sec Z-gyro rate: -0.023 degrees/sec
11:21:08.379 -> X-mag field: 616.74 mG Y-mag field: 276.78 mG Z-mag field: -242.89 mG
11:21:08.379 -> Temperature is 24.2 degrees C
11:21:08.911 -> X-acceleration: -0.79 mg Y-acceleration: -34.18 mg Z-acceleration: 998.47 mg
11:21:08.911 -> X-gyro rate: -0.053 degrees/sec Y-gyro rate: 0.015 degrees/sec Z-gyro rate: 0.076 degrees/sec
11:21:08.911 -> X-mag field: 622.01 mG Y-mag field: 267.97 mG Z-mag field: -258.18 mG
11:21:08.911 -> Temperature is 24.2 degrees C
And if I rotate it over one axis you get different values, as expected:
11:22:59.881 -> X-acceleration: -995.67 mg Y-acceleration: -37.23 mg Z-acceleration: 102.66 mg
11:22:59.881 -> X-gyro rate: -0.053 degrees/sec Y-gyro rate: 0.038 degrees/sec Z-gyro rate: 0.244 degrees/sec
11:22:59.881 -> X-mag field: 518.34 mG Y-mag field: 220.37 mG Z-mag field: 25.48 mG
11:22:59.881 -> Temperature is 24.4 degrees C
Now, when trying to burn the EDTracker2_9250, I get no output at all... So, the first thing I had to do, was to add a wait right after calling Serial.begin() in https://github.com/brumster/EDTracker2/blob/1dd8971a579668df5c496a5a796f5a17d0f51ecc/EDTracker2_9250/EDTracker2_9250/EDTracker2_9250.ino#L221-L224
And have it as follows:
Serial.begin(115200);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
After this change, I've been able to add prints around the code, and I have figured the following:
- The setup() does run and finish.
- The main loop() does run, but it seems it is not able to get the values from the sensor...
Right on line 274 https://github.com/brumster/EDTracker2/blob/1dd8971a579668df5c496a5a796f5a17d0f51ecc/EDTracker2_9250/EDTracker2_9250/EDTracker2_9250.ino#L272-L275
I print the values for sensor_data, sensors and more. Almost always, their values are
sensor_data -> 1
sensors -> 0
more -> 1
At one point, after trying over and over and over, I was able to see values coming, which appear to be what's expected to happen... First what I think it is the calibration period:
11:37:52.896 -> 0
11:37:52.896 -> Q 68 14 -25
11:37:52.896 -> 0
11:37:52.896 -> Q 68 14 -25
11:37:52.930 -> 0
11:37:52.930 -> Q 68 13 -26
11:37:52.930 -> 0
11:37:52.930 -> Q 68 13 -26
And then more data
11:37:53.693 -> Q 70 66 -53
11:37:53.693 -> -6474 -32768 -32768 15153 -4489 -3220 229 5941 -1126 22510 6346 16164
11:37:53.693 -> T 2733853
11:37:53.693 -> 0
11:37:53.693 -> Q 72 62 -54
11:37:53.693 -> -7572 -30824 -32767 14788 -4159 -2990 383 6036 -1145 22738 6573 16164
11:37:53.693 -> 0
11:37:53.693 -> Q 72 62 -55
11:37:54.191 -> -7864 -28758 -32767 14299 -3553 -2331 563 6170 -1173 22962 6798 16164
11:37:54.257 -> 0
11:37:54.257 -> Q 73 17 -38
11:37:54.755 -> -6246 -32768 6059 1837 2828 15043 168 -541 522 25668 9504 16164
11:37:54.755 -> T 2733275
11:37:54.821 -> 0
11:37:54.821 -> Q 73 22 -38
11:37:55.323 -> -9980 -32767 605 1045 2075 14313 -166 216 -50 25783 9619 16164
11:37:55.323 -> T 2733853
11:37:55.389 -> 0
11:37:55.389 -> Q 86 27 -37
11:37:55.887 -> -32767 -32767 -32768 3779 9565 6097 1156 825 -308 31377 15213 16164
11:37:55.887 -> T 2732311
When this happens, the sensors value is always 120...
This is not consistent, though... It seems it will work ok right after burning the firmware... as soon as I unplug the USB and plug it back I go back to always get sensor_data to be 1 which, as far as I understand, it means the sensor didn't cause an interrupt to inform it has new values measured...
I suspect there's something wrong with the sensor initializing, although I cannot imagine why it would work after burning but not after unplugging, and plugging back in...
@brumster Have you seen this behavior before? do you have any suggestion on what to try?
Hi guys,
The return of sensor data used to be a problem on certain MPU9250 devices - up until commit c3a10b5405aca318084c2eadf2412fd6747b46db when I merged the 6.12 motion driver in. Up until that point there was a small number of reports of fails to call the motion driver functions, which would error with "no sensor data". But it was very hard to pin down, the most we could ever deduce was that some chips were a bit 'marginal' and/or i2c noise was a contributing factor.
But, with that last motion driver update, it fixed the issue for a few people.
What is the hardware of your build - the MCU, the 9250 board and what is sandwiching them together (if anything)?
@brumster First of all, thank you very much for your time... On my side, I have built everything in a breadboard, using a pro micro, a button and an MPU 9250 You can see photos in https://photos.app.goo.gl/fLsStpEGrXCbJNw4A
After failing to make it work with the build instructions provided in http://www.edtracker.org.uk/index.php/diy/build-it/breadboard I have changed the following:
- According to MPU9250 documentation, FSYNC pin should go to GND if not used (You can see in pic above that I put this pin to GND)
- The "Reset" button, is not wired to pin 10 but instead to the actual RST pin in Arduino.
Let me know if you need further details on these...
On the commit you mentioned https://github.com/brumster/EDTracker2/commit/c3a10b5405aca318084c2eadf2412fd6747b46db I fail to see a sensible change in code... it appears to only be a rename of the PI and TWOPI variables... am I missing something?
Again, thank you for your time !
Apologies, I meant to reference to corresponding commit in the EDTracker2_ArduinoHardware project - 056feda287b27fb154f771754a35d9055b1f279d - the one I linked was simply a version uplift in the sketch to distinguish it for our builds (and yes, I renamed some of the vars while I was at it, just to add to the confusion :) )...
Your wiring differences shouldn't be an issue. You've just decided to restart the device rather than recalibrate on button press, which is fine, and the FSYNC grounding won't hurt.
I suppose one thing to try (although it is clutching at straws a bit!) is running the i2c lines direct from MCU to MPU, without relying on the breadboard. Short of getting an oscilloscope onto the i2c lines to look for noise...? Doesn't explain why other sketches work OK but maybe it's related to the settings we use on the MPU versus other sketches... worth a try?
@brumster Ahhh ! that makes sense now :) I found the commit...
As you say, I don't think the wiring between the MCU and the MPU is the issue, since the Sparkfun example works as expected every time... I will build a PCB over the weekend and give it a try anyway, you never know...
Unfortunately, I do not have access to an oscilloscope (Neither I would know how to use it... I'm just a hobbyist :P )
So, here's another thing... when you compile the .INO do you get a lot of warnings? I get the following:
Warning: platform.txt from core 'EDTracker AVR Boards' contains deprecated compiler.path={runtime.ide.path}/hardware/tools/avr/bin/, automatically converted to compiler.path={runtime.tools.avr-gcc.path}/bin/. Consider upgrading this core.
Warning: platform.txt from core 'EDTracker AVR Boards' contains deprecated tools.avrdude.cmd.path={runtime.ide.path}/hardware/tools/avr/bin/avrdude, automatically converted to tools.avrdude.cmd.path={path}/bin/avrdude. Consider upgrading this core.
Warning: platform.txt from core 'EDTracker AVR Boards' contains deprecated tools.avrdude.config.path={runtime.ide.path}/hardware/tools/avr/etc/avrdude.conf, automatically converted to tools.avrdude.config.path={path}/etc/avrdude.conf. Consider upgrading this core.
Warning: platform.txt from core 'EDTracker AVR Boards' contains deprecated recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}", automatically converted to recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}". Consider upgrading this core.
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
/trabajo/Arduino/EDTracker2/EDTracker2_9250/EDTracker2_9250/EDTracker2_9250.ino:52:17: note: #pragma message: Sketch is EDTracker2_9250...
#pragma message "Sketch is EDTracker2_9250..."
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
/home/frapell/Arduino/hardware/edtracker/avr/libraries/InvensenseMotionDriver/inv_mpu_dmp_motion_driver.c: In function 'dmp_set_fifo_rate':
/home/frapell/Arduino/hardware/edtracker/avr/libraries/InvensenseMotionDriver/inv_mpu_dmp_motion_driver.c:688:16: warning: 'return' with a value, in function returning void
return -1;
^
/home/frapell/Arduino/hardware/edtracker/avr/libraries/InvensenseMotionDriver/inv_mpu_dmp_motion_driver.c:680:7: note: declared here
void dmp_set_fifo_rate(unsigned short rate)
^~~~~~~~~~~~~~~~~
/home/frapell/Arduino/hardware/edtracker/avr/libraries/InvensenseMotionDriver/inv_mpu_dmp_motion_driver.c: In function 'dmp_read_fifo':
/home/frapell/Arduino/hardware/edtracker/avr/libraries/InvensenseMotionDriver/inv_mpu_dmp_motion_driver.c:1201:29: warning: 'return' with a value, in function returning void
if ( success != 0 ) return success;
^~~~~~~
/home/frapell/Arduino/hardware/edtracker/avr/libraries/InvensenseMotionDriver/inv_mpu_dmp_motion_driver.c:1187:7: note: declared here
void dmp_read_fifo(short *gyro, short *accel, long *quat,
^~~~~~~~~~~~~
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
/home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/wiring.c: In function 'init':
/home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/wiring.c:265:3: warning: #warning Timer 2 not finished (may not be present on this CPU) [-Wcpp]
#warning Timer 2 not finished (may not be present on this CPU)
^~~~~~~
/home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/wiring.c:274:3: warning: #warning Timer 2 not finished (may not be present on this CPU) [-Wcpp]
#warning Timer 2 not finished (may not be present on this CPU)
^~~~~~~
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C99 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
/home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/Tone.cpp:210:12: warning: #warning this may not be correct [-Wcpp]
#warning this may not be correct
^~~~~~~
In file included from /home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/USBAPI.h:38:0,
from /home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/USBCore.cpp:19:
/home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/USBCore.cpp: In function 'bool SendConfiguration(int)':
/home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/USBCore.h:285:91: warning: narrowing conversion of 'interfaces' from 'int' to 'u8 {aka unsigned char}' inside { } [-Wnarrowing]
{ 9, 2, _totalLength,_interfaces, 1, 0, USB_CONFIG_BUS_POWERED, USB_CONFIG_POWER_MA(500) }
^
/home/frapell/Arduino/hardware/edtracker/avr/cores/edtracker/USBCore.cpp:471:28: note: in expansion of macro 'D_CONFIG'
ConfigDescriptor config = D_CONFIG(_cmark + sizeof(ConfigDescriptor),interfaces);
^~~~~~~~
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
<command-line>:0:23: warning: ISO C++11 requires whitespace after the macro name
Sketch uses 27842 bytes (97%) of program storage space. Maximum is 28672 bytes.
Global variables use 832 bytes (32%) of dynamic memory, leaving 1728 bytes for local variables. Maximum is 2560 bytes.
Do you think some of these warnings could be the root cause?
One thing I wanted to try is maybe getting a newer version of the Invesense library ? I registered in their site, but couldn't find where to download it from...
I get pretty much 99% the same warnings on 1.8.11, don't worry ;)
I'd be very careful about trying a new library from Invensense. Every time we've merged in a new version it's taken a lot of remedial work on the code to make it compatible, and performance of the device has sometimes changed. By all means try it, but the old adage "YMMV" applies ;) !!
@brumster hahaha... well, the only reason I was considering it is because pretty much the whole functionality depends on that dmp_read_fifo call, which almost never detects movement in the sensor...
I suspect the ones I have are some cheap chinese builds, and they are not being properly initialized or something like that...
I'll keep grinding, will post updates here if I manage to figure something out...
Thanks again for your help !
I have the same problem, but I used a GY-91 module instead. Checked the wiring many times and seems it doesn't want to work. Maybe there's an I2C adress conflict......
I'm having the same issues as the previous poster. Hardware is a clone Pro Micro (16Mhz/5v) and MPU9250/6500 board from eBay. Looking at the chip markings it shows MP92 which indicates it indeed an MP9250.
I don't think this is a hardware / build problem. Whilst I couldn't get the Sparkfun example to compile, (missing defines) I tried a different example here:
https://raw.githubusercontent.com/SeeedDocument/Grove-IMU_9DOF_v2.0/master/res/Grove_IMU_9DOF_9250.zip
sourced from this page:
https://www.seeedstudio.com/blog/2019/12/09/getting-started-with-mpu-9250-arduino-guide/
This seems to work fine with the default build from the EDTrack DIY site. It uses AD0 low and seems to poll rather than use interrupts to sample the readings. In this example the serial monitor shows data from the Accelerometer, Gyro and Magnetometer in all three axes changing consistently as the device is rotated around each axis. Thus I'm reasonably confident the hardware build is OK.
Next I tried a bit of debugging of the EDTrack 9250 sketch from here. Observations:
a) The interrupt definitely fires, ISR() fires continuously and new_gyro is set to 1. So again it's not a wiring/hardware problem with the interrupt line, and the 9250 seems to have initialised to the point where it is sending interrupts.
b) In the main loop dmp_read_fifo() fires as soon as new_gyro is set to 1 by the interrupt, again so far so good.
c) I haven't dug far enough in to the API and logic of this sketch, but as far as I can see during the call to dmp_read_fifo, the sketch sets sensor_data (long_int) to 1 and then passed by reference to dmp_read_fifo as the 4th parameter.
According to the API spec I think this should return a timestamp (don't know how or what it is calculated)? The the sketch checks to see if sensor_data == 0 before entering the code to process the sensor data. That doesn't make sense to me as if it is a timestamp, sensor_data is unlikely to be 0, so perhaps I've misunderstood what is happening here.
d) In fact sensor_data always contains 1 upon return from dmp_read_fifo, maybe it is never modified? Regardless it is always 1 so the logic at the start of the data processing block means it is never entered.
e) Bypassing the check on sensor_data and forcibly entering the block and with DEBUG defined, some readings are displayed in the serial monitor but these don't change as the device is rotated, and after maybe 10 or 20 lines the sketch appears to hang with no more output.
Further testing, using the EDTrackUI to program the device, I get the same issue with the 9250 sketch (4.1.0, 4.0.5 AND 4.0.3 old tried) - it uploads and says 'connected' or 'disconnected' in the box next to the head and I click the connect/disconnect button, but the device name is never shown just 'NOT CONNECTED' in the main box and no data is returned, presumably because it is stuck somewhere in the sketch due to the issues described above.
Oddly if I try the 6050 calibration sketch (2.5.3) and then then main 6050 sketch (2.20.9) I can get data from two of the three Axes only (and obviously it doesn't try to use the magnetometer as not applicable to 6050). The calibration process and tracking for two of the Axes that work seems about right and can be sort of used in the tracker.
Again this suggests that the device is functioning but not properly initialised or queried by 6050 sketch (as you might expect) and along with the test sketch from the other site above which works fine as far as I can see, suggests that the 9250 sketch is not initialising or something is going wrong when reading the data?
I might look at trying the library direct from the manufacturer in case there is a new hardware config recently but it's a bit of a shot in the dark.
I'm having the exact same issue. Has anyone found anything?
This is with a 9250. As previous posters (and in the other thread which I think is the same issue), 9250 seems to be working okay, but doesn't connect to EDTracker UI.
The device is showing up as a USB controller in Windows -- just no data.
I tried everything in this and the other thread to try to narrow down the issue.
I didn't get any further and it's been sat on my desk as a very small paperweight. The fact that the SeedStudio example seems to work fine but EDTracker doesn't suggests there is something in the different library used that isn't intialising the device properly. Maybe some subtle change or tolerance issue in the current boards needs accommodating but I'm at a loss and not willing to spend the time needed to dig right in to the low-level stuff needed.
You could try fiddling with the various delay/delay_ms() calls embedded within the Invensense drivers, basically just do a search for anything with a wait in it underneath
Thanks for the suggestion, I've experienced those kind of timing/delay issues with other types of board and I appreciate how hard it is to debug them. I think the serial comms are initialising but something else probably isn't.