Post Reply 
 
Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ESP32 Port of B-Robot_EVO2 Code
05-20-2018, 09:42 PM
Post: #21
RE: ESP32 Port of B-Robot_EVO2 Code
Watched your video again... The battery pack also looks quite massive (and thus probably heavy) and it's mounted at a very high position. You could try to dismount it and hold it in one hand and see how the robot is behaving then.

What still makes me wonder is one motor stalling, especially at an angle where I would expect both to stop (if the perspective in which you took the video isn't fooling me).

You could also set define DEBUG to 1 in defines.h to get some additional logging output, e.g. the current angle. It should be around 0 when the robot is held upright turning toward +90 and -90 respectively tilting towards the one or other horizontal position. At about +/-74 degrees the motors should turn off. Can you confirm such behavior?

Just to tripplecheck the stepping resolution: You've configured your steppers according to this page https://www.pololu.com/product/1182 and set M1, M2 and M3 to high?

BR,
ghmartin77
Find all posts by this user
Quote this message in a reply
05-29-2018, 09:38 PM
Post: #22
RE: ESP32 Port of B-Robot_EVO2 Code
Hi Beebrain,

Long time no see. Does it work for you now? If so, I'm interested in the root cause of course...

Best,
ghmartin77
Find all posts by this user
Quote this message in a reply
06-07-2018, 05:28 PM (This post was last modified: 07-03-2018 08:14 PM by BurchSung.)
Post: #23
RE: ESP32 Port of B-Robot_EVO2 Code
Hi...I am a new user here. I think the idea with the ballons is simple and sufficiant. Could be changed easily and are always available.With your hint of the wheel noise I will try to print them on my Anet A6.
I will also try with the WiFi ID and even to feed power directly to the ESP32 board.

percentage calculator
Find all posts by this user
Quote this message in a reply
06-23-2018, 01:36 PM (This post was last modified: 06-23-2018 01:44 PM by viocudinti.)
Post: #24
RE: ESP32 Port of B-Robot_EVO2 Code
Hello ghmartin77,

I've built a bot using your code and it works great! I've added some modifications like color LED eyes (see my fork on Github). The problem I'm having now is the crash related to I2C on newer versions of the esp32 platform code.
I'm using the older commit that you recommended in project readme, but that holds back the development as I can't make use of the latest features (e.g. Bluetooth). I didn't understand the root cause so I'm confused about what causes the crash. I've even tried random things like pull-up resistors on SCL/SDA Smile

"Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1)"

Any idea how to fix the issue while using a newer version of espressiv esp32 platform? Did you try other hardware modules (I'm also using the DoIT module, or at least it looks similar)?

Thanks for sharing the code and maybe for your help,
Viorel
Find all posts by this user
Quote this message in a reply
06-23-2018, 02:37 PM (This post was last modified: 06-23-2018 02:38 PM by ghmartin77.)
Post: #25
RE: ESP32 Port of B-Robot_EVO2 Code
Hi Viorel,

Happy to hear you've fun with the ported code Smile
Well, there's a bug in my code as well that did not appear with the old esp32 platform version mentioned so I didn't update my repository, but maybe this one kicks in now, while I2C might(!) work today (haven't tried). I'm messing around with proper locking in Timers.cpp, lines 29 and 46. Returning this way from the methods will not release the locks properly and the code is killed sooner or later by the WDT (Watch Dog Timer). Your error is pointing towards this. You can fix it by changing the code by modifying the condition of the if statement from "== 0" to "!=0", removing the return statement and putting everything but the portExit... lines into {} brackets.

Maybe this helps...

If I've got some more sparetime I will add the fix to Github...

Good luck! Please let me know if it does the trick. Would mean I2C is fixed again in esp32 platform...

Best,
ghmartin77
Find all posts by this user
Quote this message in a reply
06-23-2018, 08:50 PM (This post was last modified: 06-23-2018 09:04 PM by dasMopo.)
Post: #26
RE: ESP32 Port of B-Robot_EVO2 Code
Hello there and thanks for the ESP32 port.

Unfortunately, I suppose to take MIA beebrain's place in this discussion, as I built one myself and am experiencing the exact same issue beebrain had.

I'm using your latest commit from today, my a4988 drivers are set to 1/16 microstepping, motors which are NEMA17 and have 200 full steps per revolution. [edit: I do feed the IMU and the a4988 drivers with 3V3 from the ESP32 board's regulator.]

Also, I do experience the imu readings to freeze now and then. [edit: Mostly, if app connected / motors running -- I'm wondering there are no flyback / freewheel diodes in the schematic.]

Motors stop if I (manually) exceed 70 deg tilt, but they also don't stop if the robot is held straight upright by hand.

Any guesses ?
Find all posts by this user
Quote this message in a reply
06-23-2018, 10:11 PM
Post: #27
RE: ESP32 Port of B-Robot_EVO2 Code
Interesting... I'm really wondering why it's working for some people while it does not for others.
Did you take this into account? (Maybe the recent esp32 platform code fixes I2C issues but introduces some timing issues...)
Important note: At the time of this writing (January 2018) the recent version of arduino-esp32 contains changes that break the I2C communication with the IMU a few seconds after startup. This version is known to work reliably for the purpose of the robot: https://github.com/espressif/arduino-esp...7917e0309c

Turning wheel if the robot is held straight upright is completely normal. There's almost no chance to balance it in a way that exactly no tilting is measured by the IMU.
Regarding the freewhell diodes. Check out the original brain shield here http://forums.jjrobots.com/attachment.php?aid=244.
No diodes either and I suppose they're not needed, because they're contained in the A4988's or they're doing some other tricks that won't harm your components if you don't turn the wheels manually. From the datasheet (not sure if the following passage really refers to freewheel diodes):
"This synchronous rectification feature turns on the appropriate
FETs during current decay, and effectively shorts out the body
diodes with the low FET RDS(ON) This reduces power dissipation
significantly, and can eliminate the need for external Schottky
diodes in many applications."
Find all posts by this user
Quote this message in a reply
06-23-2018, 10:20 PM
Post: #28
RE: ESP32 Port of B-Robot_EVO2 Code
Thanks for your reply.
I wasn't clear about wheels turning when the robot is held up -- they're not just turning a little but rather seem to turn at max speed - always.

Regarding the i2c issue and the mentioned commit id: I tried that, but as at that commit the board I'm using (NodeMCU 32S) wasn't included, I had to use a more recent version.

Also I found out in the meantime that the a4988 drivers actually seem to have flyback diodes included.

Well, tomorrow I'll double check for cold solder joints.
Find all posts by this user
Quote this message in a reply
06-23-2018, 10:32 PM
Post: #29
RE: ESP32 Port of B-Robot_EVO2 Code
(06-23-2018 10:20 PM)dasMopo Wrote:  I wasn't clear about wheels turning when the robot is held up -- they're not just turning a little but rather seem to turn at max speed - always.

Well, that's odd... Turning is expected, but turning full speed always is not normal. If you tilt the robot to one side and then to the other the motors should turn slower and then reverse turning direction.

Is your IMU mounted correctly?

Can you see expected degree measurements on the console with DEBUG set to 1 in defines.h?

My notes on the broken I2C subsystem are to be taken seriously, if you want this stuff to work. Maybe you can take the old version and just move your board definitions stuff from a newer version?
Find all posts by this user
Quote this message in a reply
06-23-2018, 10:40 PM
Post: #30
RE: ESP32 Port of B-Robot_EVO2 Code
I'll try that as well, thanks for the advice.
And yes -- I already used debug set to 1, the angle values seemed reasonable, whereas the wheel movements did not.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)