Post Reply 
 
Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ESP32 Port of B-Robot_EVO2 Code
06-13-2019, 12:18 AM
Post: #81
RE: ESP32 Port of B-Robot_EVO2 Code
(05-24-2019 06:22 AM)ghmartin77 Wrote:  All problems gone after adding the capacitors?

Looks good now most of the time. Not sure if it is because the capacitor or now. Once in a while, I will need to restart the Android apps to make it works again.
Find all posts by this user
Quote this message in a reply
11-10-2019, 11:18 AM
Post: #82
RE: ESP32 Port of B-Robot_EVO2 Code
I am experiencing some strange intermittent false starts. On power-up the robot will sometimes prematurely enable the motors and try to start moving. When this happens it usually lasts about a second , then the robot seems to realize the actual angle is not more than the ready angle and it shuts off the motors and waits as expected to be raised up either by hand or servo.
Has anyone else noticed this ?
Find all posts by this user
Quote this message in a reply
11-10-2019, 12:01 PM
Post: #83
RE: ESP32 Port of B-Robot_EVO2 Code
Never seen this before. Can you explain more precisely when this happens? Immediately when powered on? After the initialization phase (when the wheels and arm have stopped wiggling)?
What Arduino-ESP32 SDK version is it?
Find all posts by this user
Quote this message in a reply
11-10-2019, 01:12 PM (This post was last modified: 11-11-2019 05:54 PM by justjason.)
Post: #84
RE: ESP32 Port of B-Robot_EVO2 Code
It happens after power up and after the gyro calibration and servo arm has stopped wiggling. I am using 1.0.2. I have noticed that i have to flip a few things in the code as it seems like my gyro is 180’ flipped to yours in the mounting, so i have flipped servo max and min pulse so that the arm is in the right direction when using the standup routine. Everything else is standard.i was almost thinking that the angle filter could be still processing the info and calculating the average value
Find all posts by this user
Quote this message in a reply
11-10-2019, 01:51 PM
Post: #85
RE: ESP32 Port of B-Robot_EVO2 Code
Sounds quite reasonable even if I couldn't find any variables that shouldn't be initialized on a first glance.
However, this is something you could give a try. If this situation happens often enough, you could #define DEBUG as 1 and check the logging output transferred via UART, comparing output of a good run and a bad run...
Additionally you could initialize some of the variables looking suspicious explicitly and see if it does any good.
Find all posts by this user
Quote this message in a reply
11-11-2019, 05:52 PM (This post was last modified: 11-11-2019 05:56 PM by justjason.)
Post: #86
RE: ESP32 Port of B-Robot_EVO2 Code
So like most intermittent issues, this one is hiding when you are looking for it...
But I did notice a few things watching the serial on Debug.
On power up and after the servo wiggle (laying steady on the table), the gryo is definitely still stabilizing.
Here are the first few readings:

Wifi AP set up successfully
WHO_AM_I : 68, error = 0
Gyro calibration... DONT MOVE!
offset: -429 stddev: 8.13
4.71 -1.00 76.60,0.00
0.01 -1.00 76.65,0.00
0.01 -1.00 76.77,0.00
0.01 -1.00 76.95,0.00
0.01 -1.00 77.13,0.00
0.01 -1.00 77.28,0.00
0.01 -1.00 77.38,0.00
0.01 -1.00 77.40,0.00
0.01 -1.00 77.38,0.00
0.01 -1.00 77.35,0.00
0.01 -1.00 77.30,0.00
0.01 -1.00 77.27,0.00
0.01 -1.00 77.28,0.00
0.01 -1.00 77.33,0.00
0.01 -1.00 77.42,0.00
0.01 -1.00 77.54,0.00
0.01 -1.00 77.69,0.00
0.01 -1.00 77.83,0.00
0.01 -1.00 77.95,0.00
0.01 -1.00 78.03,0.00
0.01 -1.00 78.06,0.00


and after two seconds they look more like this

0.01 -1.00 83.18,0.00
0.01 -1.00 83.19,0.00
0.01 -1.00 83.20,0.00
0.01 -1.00 83.20,0.00
0.01 -1.00 83.20,0.00
0.01 -1.00 83.20,0.00
0.01 -1.00 83.20,0.00
0.01 -1.00 83.20,0.00
0.01 -1.00 83.20,0.00
0.01 -1.00 83.19,0.00
0.01 -1.00 83.19,0.00

there seems to be a +- 6 deg change in this case until stabilized and on average between 6 - 10 deg in the other tests.

The other thing that seems odd is the offset value of -429. I can not imagine how this could be possible. I am guessing that it is adding 360 deg to the actual value.

Considering that my gyro is flipped compared to yours I would expect + 180, but not 360.
I am confused.
Find all posts by this user
Quote this message in a reply
11-11-2019, 09:51 PM
Post: #87
RE: ESP32 Port of B-Robot_EVO2 Code
Not sure about the offset value and can't test and compare right now. But I saw something suspicious in the code that could match your descriptions (ESP32SelfbalancingBot.cpp, 281ff):
Code:
        if (OSCpush[0])     // If we press the SERVO button we start to move
            angle_ready = 82;
        else
            angle_ready = 74;  // Default angle

The OSCpush array is defined in globals.cpp and since it is an array its fields are not initialized by the compiler and might contain any garbage. This might set the angle_ready, which is used to decide whether the motors shall be activated, to 82. This is greater than your initial readings for about 2 secs, triggering the motors.

Please try if a line like
Code:
OSCpush[0]=OSCpush[1]=OSCpush[2]=OSCpush[3]=0;
in setup() will make your issue go away.
If it helps, I'll add the change to the Github codebase. Whatever the outcome, using the array uninitialized is definitely a bug...

Best regards,
ghmartin77
Find all posts by this user
Quote this message in a reply
11-13-2019, 08:42 AM (This post was last modified: 11-13-2019 08:49 AM by justjason.)
Post: #88
RE: ESP32 Port of B-Robot_EVO2 Code
I added OSCpush[0]=OSCpush[1]=OSCpush[2]=OSCpush[3]=0; into setup and there is definitely a change . The gryo starts off with a reading of around 100' now before stabalizing at the actual 85 - 86'. I am trying to figure out where these values are coming from. I can understand your idea if I look at the output before the change, ( I should mention that my ready angle is set at 75 else 70 not the original 82 else 74.) the first values were close enough to the 75 that it could have been that the array was adding that into the output and then the complimentary filter was fed that as a start value to process which would then stabilize to the actual value after a second or so. BUT if it is now feeding a 0 in to the filter, why would my values start at around 100 and then stabilize.
Wifi AP set up successfully
WHO_AM_I : 68, error = 0
Gyro calibration... DONT MOVE!
offset: -441 stddev: 1.64
4.71 -1.00 99.21,0.00
0.01 -1.00 99.11,0.00
0.01 -1.00 99.07,0.00
0.01 -1.00 99.03,0.00
0.01 -1.00 98.92,0.00
0.01 -1.00 98.76,0.00
0.01 -1.00 98.56,0.00
0.01 -1.00 98.34,0.00
0.01 -1.00 98.13,0.00
0.01 -1.00 97.94,0.00
0.01 -1.00 97.78,0.00
0.01 -1.00 97.66,0.00
0.01 -1.00 97.57,0.00
0.01 -1.00 97.51,0.00
0.01 -1.00 97.46,0.00
0.01 -1.00 97.40,0.00
0.01 -1.00 97.31,0.00
0.01 -1.00 97.17,0.00
Find all posts by this user
Quote this message in a reply
11-13-2019, 07:54 PM
Post: #89
RE: ESP32 Port of B-Robot_EVO2 Code
Wait, wait, wait... Too fast for me. Can't follow...
First of all there is only one place where the motors are activated after initialization (Esp32SelfbalancingBot.cpp, 285ff):
Code:
        if ((angle_adjusted < angle_ready) && (angle_adjusted > -angle_ready)) // Is robot ready (upright?)
                {
            // NORMAL MODE
            digitalWrite(PIN_ENABLE_MOTORS, LOW);  // Motors enable
The condition is only based on a comparison of angle_adjusted and angle_ready.
I checked how/where angle_ready is set and came across the OSCpush comparison quoted above. The OSCpush array members are used as kind of booleans even if defined as uint8_t's. I haven't found any place where their value is added somewhere, especially not for OSCpush[0]. However, an unititialized OSCpush[0] might contain any value which might have an impact of changing angle_ready to a different value, which in turn could activate the motors at a steeper angle. OSCpush[0] is considered, if the servo arm is used for standing up. In that case it makes sense to activate the motor already at a steeper angle to help standing up completly.
The proposed change initializing the OSCpush array fields should have no impact on the angle measured, though.
So I don't understand why your measured angle changes from ~76 as a start value without the change to ~99 in the second run. Maybe your gyro just needs way longer to initialize and deliver correct data? Or it can't just be used reliably 180° flipped?!
Find all posts by this user
Quote this message in a reply
11-15-2019, 12:43 PM
Post: #90
RE: ESP32 Port of B-Robot_EVO2 Code
Sorry, I did not explain that very well.

Yes, i was taliking about those activation angles (Esp32SelfbalancingBot.cpp, 285ff)
I have changed those from 82/74 to 75/70.


However I think I have made a mistake with my observations.
I tried the code with and without OSCpush[0]=OSCpush[1]=OSCpush[2]=OSCpush[3]=0;
I first I thought I had noticed a difference, but after trying a few more cycles with and without modified code, I now think that it has not changed the angle instability issue, ie it DOES vary between a start angle reading value of 76 and 110 deg ,but I this is NOT dependant on whether I am using the modified code or not. At first I had thought the changed code was changing the start value reading from the gyo. I was wrong, it seems to be a random variation.
I would think that you are right about the longer than usual stabilisation time of my gyro , but I am also wondering if about the offset value of more than 420 deg. This is no doubt a result of my 180 flipped gyro, but I would prefer not to have to remount the gyro if possible, so if I can find a way around this issue in the code I would be much happier.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


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