RoboDurden / Hoverboard-Firmware-Hack-Gen2.x

with different defines_2-x.h for different board layouts :-) Compiles with Keil version 6
GNU General Public License v3.0
73 stars 24 forks source link

Unable to control board using TestSpeed program (question) #9

Open Derkades opened 1 year ago

Derkades commented 1 year ago

Hi, first of all thanks for providing precompiled binaries, I can stop spending my time trying to get it to work with PlatformIO!

I have flashed hoverboard 2.0 slave.bin to the slave board. When I flash hoverboard 2.0 master test.bin to the master board, the wheels spin like they should! But when I flash the normal master firmware hoverboard 2.0 master.bin, I can't get the wheels to spin.

I have flashed your TestSpeed Arduino program to an ESP32-S2.

It receives the data from the hoverboard just fine: image (I have added SendSpeed and SendSteer to confirm the values of iSpeed and iSteer were as expected)

Is this perhaps a known pitfall, or do you have any tips to resolve this issue? Thank you

RoboDurden commented 1 year ago

Perhaps your tx line is broken. The test firmware is just a one Liner that overwrites speed command. As you receive iVolt, the serial connection is established. If you have a pocket oscilloscope, check that some binary data is getting to the Rx pin of the hoverboard board.

Derkades commented 1 year ago

Thanks for the reply, unfortunately I don't have access to an oscilloscope or logic analyzer to inspect the serial lines. A simple continuity test does show the TX pin on the ESP32 is connected to the RX pin on the hoverboard.

I have tried both the hardware serial port (Serial1, pins 17/18) and software serial on various pins

RoboDurden commented 1 year ago

I have added a gen2.0 repo to my online compiler: https://pionierland.de/hoverhack/?p=gen2 I outputs a warning but compiles the binary. Should work. However it has the old serial protocol which is not compatible to my advance feedback. I guess you find arduino code here: https://github.com/gaucho1978/CHEAP-LAWNMOWER-ROBOT-FROM-HOVERBOARD

Just mention it here because it might work for you .

Otherwise i fear you need to install Keil to compile my firmware. Then you could overwrite SerialHover2Server.iAmL and SerialHover2Server.iAmpR with the speed and steer parameters to see if the serial data gets received. You would add a extern int32_t speed to commsSteering.c to have access to the speed variable in SendSteerDevice

But if the master_test bin is working and also sending the SerialHover2Server struct to your ESP32 than i do not know why the SerialServer2Hover data gets not received from the esp32.

test the master_test bin again to see that you receive the SerialHover2Server data iVolt, iAmpL

good night and good luck

Derkades commented 1 year ago

Thanks again, I will experiment with sending the parameters back tomorrow. Good night to you too.

Andyzug commented 10 months ago

I have the same problem on 2.0 board, it's working with test firmware but when trying TestSpeed Arduino program, it's not spinning, also I get some erronated value for iOdomL in the serial monitor

14 00 14 00 95 B1 CD AB -> iOdomL: -1412603709 iOdomR: 0 iSpeedL: 0.00 iSpeedR: 0.00 iAmpL: 0.00 iAmpR: 0.20 iVolt: 37.77 EC1 != 65F9 :-(

@Derkades did/how you solved your issue?

RoboDurden commented 10 months ago

Sorry, i have not tested my code for a long time now.

The last EC1 != 65F9 :-(suggests that you have uncommented line 9 of TestSpeed.ino

//#define DEBUG_RX // additional hoverboard-rx debug output

But is iVolt: 37.77 correct ? Will it increase when you plug in the charger ? Then serial communication pins are okay and maybe i have changed the protocol..

Andyzug commented 10 months ago

Sorry, i have not tested my code for a long time now.

The last EC1 != 65F9 :-(suggests that you have uncommented line 9 of TestSpeed.ino

//#define DEBUG_RX // additional hoverboard-rx debug output

But is iVolt: 37.77 correct ? Will it increase when you plug in the charger ? Then serial communication pins are okay and maybe i have changed the protocol..

Yes, when I plug in the charger, it slowly increases the iVolt value.

RoboDurden commented 10 months ago

Then at least the communication from tx hoverboard to Rx Arduino is working. But if the data structs of the Arduino side and the hoverboard side do not match, the CRC check will discard any data.

Do you flashed my ready to download binaries ?

Will take a look at my source code in about two hours.

Derkades commented 10 months ago

I have the same problem on 2.0 board, it's working with test firmware but when trying TestSpeed Arduino program, it's not spinning, also I get some erronated value for iOdomL in the serial monitor

14 00 14 00 95 B1 CD AB -> iOdomL: -1412603709 iOdomR: 0 iSpeedL: 0.00 iSpeedR: 0.00 iAmpL: 0.00 iAmpR: 0.20 iVolt: 37.77 EC1 != 65F9 :-(

@Derkades did/how you solved your issue?

I never ended up trying anything after my previous comment, I got distracted by other projects :P

RoboDurden commented 10 months ago

I am on the road and will need 7 days to return home where i can test on a 2.0 hardware :-/

But the structs seem to match:

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Src/commsSteering.c#L34

typedef struct {            // ´#pragma pack(1)´ needed to get correct sizeof()
   uint8_t cStart;      //  = '/';
   //uint16_t cStart;       //  = #define START_FRAME         0xABCD
   int16_t  iSpeed;
   int16_t  iSteer;
   uint16_t checksum;
} SerialServer2Hover;

...

#define START_FRAME         0xABCD       // [-] Start frme definition for reliable serial communication
typedef struct{             // ´#pragma pack(1)´ needed to get correct sizeof()
   uint16_t cStart;
   int16_t iSpeedL;     // 100* km/h
   int16_t iSpeedR;     // 100* km/h
   uint16_t iVolt;      // 100* V
   int16_t iAmpL;           // 100* A
   int16_t iAmpR;           // 100* A
   int32_t iOdomL;      // hall steps
   int32_t iOdomR;      // hall steps
   uint16_t checksum;
} SerialHover2Server;

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/Arduino%20Examples/TestSpeed/hoverserial.h#L15

#define START_FRAME         0xABCD       // [-] Start frme definition for reliable serial communication

typedef struct __attribute__((packed, aligned(1))) {
   uint16_t cStart = START_FRAME;    //  = '/';
   int16_t iSpeedL;   // 100* km/h
   int16_t iSpeedR;   // 100* km/h
   uint16_t iVolt;    // 100* V
   int16_t iAmpL;   // 100* A
   int16_t iAmpR;   // 100* A
   int32_t iOdomL;    // hall steps
   int32_t iOdomR;    // hall steps
   uint16_t checksum;
} SerialHover2Server;

typedef struct __attribute__((packed, aligned(1))) {  // old version
   uint8_t cStart = '/';                              // old version
//typedef struct{   // new version
//   uint16_t cStart = START_FRAME;   // new version

   int16_t  iSpeed = 0;
   int16_t  iSteer = 0;
   uint16_t checksum;
} SerialServer2Hover;

As you can see from my commented alternatives, i was already experimenting with a new serial protocol :-/ But then we started to port SimpleFOC for these Gen2 boards: https://github.com/Candas1/Split_Hoverboard_SimpleFOC/issues/6#issuecomment-1694702246

Please check that you have the same structs in your hoverserial.h and commsSteering.c

You also need that #pragma pack(1) in https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Src/commsSteering.c#L14

If you have not installed Keil and only downloaded my readytoflash binaries, try the 2.0 master 10s bin file i attach here. I just compiled it with my latest code. hoverboard.zip

Andyzug commented 10 months ago

Safe travels @RoboDurden, I tried the .bin file you provided in .zip folder, also I compiled a new one with Keil, but same result - no spinning wheels but getting feedback through serial monitor. I tested continuity of the board's RX line with a multimeter right from mcu to arduino, and it looks fine. CD AB -> iOdomL: -1 iOdomR: 1 iSpeedL: 0.00 iSpeedR: 0.00 iAmpL: 0.00 iAmpR: 0.00 iVolt: 37.49 :-))))))))))

I tried Adruino Nano and esp32.

RoboDurden commented 10 months ago

Am still In bed but I think the :-)))))))))) shows that at least the CRC check from hoverboard to Arduino succeeded !!! That is a big improvement. Try to overwrite a parameter like iOdomL with the speed command In Keil. You could also set iOdomR with 42 when the CRC check fails in Keil.

Andyzug commented 10 months ago

I overwritten iOdomR and iSpeedR in commsSteering.c with: oData.iOdomR = 42; oData.iSpeedR = (int16_t) sizeof(SerialServer2Hover); // speed

and getting its output: CD AB -> iOdomL: 0 iOdomR: 42 iSpeedL: 0.00 iSpeedR: 0.07 iAmpL: 0.40 iAmpR: 0.20 iVolt: 36.82 :-)))))))))) millis: 110 iOdomL: 0 iOdomR: 42 iSpeedL: 0.00 iSpeedR: 0.07 iAmpL: 0.40 iAmpR: 0.20 iVolt: 36.82

I don't know what 0.07 is, it did not change over time.

I was probing the RX pin on the board and looks like it received data

logic_analyzer1 logic_analyzer2

RoboDurden commented 10 months ago

the integer sizeof is converted to 0.07 in the arduino hoverserial.h: DEBUGT(" iSpeedR",(float)oData.iSpeedR/100.0); and sizeof(SerialServer2Hover) = 7 is correct, so i wonder why the crc check should fail. Some compiler platforms convert a byte to 16 bit and then sizeof() gives a wrong number. But #pragma pack(1) in commsSteering.c did resolve that problem.

Please search and uncomment all aDebug in commsSteering.c. And in TestSpeed.ino replace HoverLog(oHoverFeedback); with HoverDebug(oHoverFeedback);

Post the arduino log output here.

Then in a next step at line 127 you could insert else aDebug[3] = 42; to check if the if (pData->checksum == CalcCRC(aReceiveBuffer, sizeof(SerialServer2Hover) - 2)) failed

You could also activate the //if (1) in line 115 to simply skip the crc and test if the motors start spinning.

Also read my answer of #14

Andyzug commented 10 months ago
  1. Uncomenting aDebug in commsSteering.c and replacing HoverLog(oHoverFeedback); with HoverDebug(oHoverFeedback); Result: CD AB -> iOdomL: 0 iOdomR: 0 iSpeedL: 0.00 iSpeedR: 0.07 iAmpL: 0.00 iAmpR: 0.00 iVolt: 0.00 :-)))))))))) millis: 109 0: 0 1: 0 2: 0 3: 0 4: 7

  2. Adding else { aDebug[3] = 42; } Same result: CD AB -> iOdomL: 0 iOdomR: 0 iSpeedL: 0.00 iSpeedR: 0.07 iAmpL: 0.00 iAmpR: 0.00 iVolt: 0.00 :-)))))))))) millis: 109 0: 0 1: 0 2: 0 3: 0 4: 7

Uncommenting if (1) did not help either :(

RoboDurden commented 10 months ago

Sorry for the troubles. I will he home on Monday.

Only zeros means that the uncommented line 113 is never reached.

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Src/commsSteering.c#L113

Try adding aDebug[2] = 17 earlier like at the very beginning of

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Src/commsSteering.c#L99

To see if that function gets called at all.

RoboDurden commented 10 months ago

Sorry, my code is working for me. Have just udated the repo here. Did test with Lolin32 S2 Mini: HoverSetupEsp32(oSerialHover,19200,39,37); // baud, rx, tx I burned my gen2.0 master board earlier this year so i only have a slave board in my test setup. But that should not effect the commsSteering.c (i added //#define CHECK_BUTTON // disable = add '//' if you use a slave board as master to disable the onOff button behavior for the slave board)

First i let the #define TEST_SPEED in action to already see serial data on my ESP32, then i removed that line and the ESP32 code took over to spin the one motor forward and backward :-)

Please try my latest code.

Andyzug commented 10 months ago

With Salve board is working, one wheel is spinning from esp32 commands. Maybe my master board has a defect or something, It's strange that test firmware is working fine, I guess rx line is the problem, I'll measure it again with a multimeter to compare with slave. Thank you for your help!

RoboDurden commented 10 months ago

Arduino only sends command after successfully receiving data!

Activate the test_led in defines_2-0.h And learn from main.c how to use it. Quickest way to led a led turn on when a certain code point has been reached. Apply this to the rx code..

pacraf commented 9 months ago

Loaded mater test precompiled binaries to my 2.0 board (both sides master and slave) and wheels are rotating nice both directions. Now trying to connect Lolin S2 mini to communicate with loaded Test speed porgram. Unfortunatelly here problem appears, no data in console. I have a question regarding connection speed to skateboard. should it be 19200 or 115200 ? In comment of .ino is written that Arduino is to slow for 115200. But the same speed is declared for ESP32. - so here my doubts. I suppose it is OK as in your published example (just copy paste , compile and should work for Lolin S2) but right now no idea where is the problem When I connect just serial dongle and monitor skateboard serial TX - I see it communicates data, but no idea what is the speed. Could anyone who played with ESP32 share working code with some changes - so I could learn, maybe you have working example for other ESP32 board... I see that this Lolin S2 with build in USB, is not so easy to debug like ESP32 with external USB chip...

RoboDurden commented 9 months ago

Only Arduino Mini needs SoftwareSerial with 19200 baud. Esp32 can do 115200. I normally use nice and cheap Lolin S2 Mini for controlling the hoverboard. If you succeed with usb dongle and 115200 then ESP32 S2 Mini with same baud rate should also receive the feedback data. Make sure you use the correct rx and tx pins.

Maybe i will have time tomorrow to finish my 2.3 test setup. I again will use the S2 Mini.

RoboDurden commented 9 months ago

the Feedback data is binary no readable ascii data. uncomment this line in the .ino to see more info on the bytes received:

//#define DEBUG_RX // additional hoverboard-rx debug output Try both 19200 and 115200 in

HoverSetupEsp32(oSerialHover,19200,39,37); // baud, rx, tx

I am no longer sure which baud rate i had set for the precompiled binaries :-/ But i think it was 19200 baud. By now it is defined in remoteUart.h

#define USART_STEER_COM_BAUD 19200

pacraf commented 9 months ago

Will try as you suggest. Apart from hooverboard hack, I noticed for the first time strange communication behaviour for ESP32 S2 (Lolin S2 Mini cheap clone). After loosing faith with above described communication topic, I just loaded to Lolin example program which just prints to serial. And here I realised that it is not important what settings in serial monitor of arduino you choose, (I mean connection speed) , it clearly shows proper serial data. you can select 9600, 115200 whatever - it shows plain messages. Also tried other serial monitor software (putty) and the same behaviour. Only when change speed to 1200 bps - it stop working (with unplug and plugin sound USB) Really strange, but I suppose it is consequence of making USB hardware inside ESP32 chip, not like other I used to work with - always external dedicated USB serial com chip onboard...
Or I have some config wrong.. as i said - first time with ESP32 S2. do you have similar behaviour of serial connection?

And another observation. if your test program is loaded (with DEBUG_RX uncommented) , I never see message "Hello Hoverbaord V2.x :-)"

if I introduced delay before, message appears. I suppose this is timing/starting, USB initialization issue (message is sent before USB comm is set up and running), but again - maybe it is only me having this behaviour - so means rather my problem somewhere... so do you see this message without delay introduced?

for clarity and for others, introduced delay is as below. Now there is time to see "Hello Hoverbaord V2.x :-)" message. at evening will try again with hooverboard connected...

void setup()
{
  delay(2000);
  #ifdef _DEBUG
pacraf commented 9 months ago

EXpotential success since yesterday. one by one. Lolin s2 recives frames. For your information - when binaries from precompiled folder set are loaded , there is situation exactly like in post od Derkades

 00 00 28 00 FD 2F CD AB -> iOdomL: -1412571768     iOdomR: 0       iSpeedL: 0.00    iSpeedR: 0.00      iAmpL: 0.40  iAmpR: 0.20        iVolt: 33.44
D10 != 2602 :-(

then i uploaded firmware fro zip file (from this thread above link) to hooverboard (I also have 2.0) and it communicates and spins according ESP communications example frame:

 CD AB -> iOdomL: -88       iOdomR: 0       iSpeedL: 0.89    iSpeedR: 0.00      iAmpL: 0.20  iAmpR: 0.00        iVolt: 33.76
 :-))))))))))

Now I have to think what next... but certainly there is some protocol mismatch in precompiled binaries and arduino test firmware now. my goal is to have it controlled by remote RC link.

I didn't asked before, but hooverboard always makes twice bep, longer break , repeat, And all the time like this. that means something?

pacraf commented 9 months ago

To other like me (making stupid mistakes) - why had trouble with receiving data... took wrong pinout for board. first result was this one (which is Wemos s2 - not lolin S2 - and somewhere I read they are compatible.. ) maybe compatible but pinout is different image and below is Lolin S2 mini image location of 37,39 pins ... thanks god GND is the same so no magic smoke appeared. So that was my mistake.

pacraf commented 9 months ago

Dear Robo Durden. After trial and error I have conclusion, that:

I still have to manage connection between PPM RC reciever <> Arduino <> hooverboard. right now if PPM receiver is connected, only one wheel is driving with some mid speed. no reaction for PPM changes. But I just started... of course I commented option to overwrite PPM signal. with uncommented, Arduino nicely drives board. good to know that it works. but after commented - no reaction. I have FRsky receiver (D2RII - 4 channel).

Does anyone have working PPM code for ESP32 ? that would be perfect to have debug view during PPM debugging... I think maybe it will be better to start a new "Issue" here it is already out of topic... a bit.

RoboDurden commented 9 months ago

Oh yes, the ppmdevice Arduino example is outdated. Copy the hoverserial.h from the working TestSpeed folder..

RoboDurden commented 9 months ago

The PPMDevice is a leftover from the original creator of this firmware. I only forked it.. I have no rc-remote and have never tested the PPM-code of that Arduino-example.

pacraf commented 9 months ago

Thanks for clarifying. Unfortunately hoverboard is dead for week(hopefully not longer), as I fried two mosfets. Playing with PPMdevice is dangerous, as it tends to rapidly set full speed, if for example RC receiver suddenly is switch off. This made my board to spin rapidly and then became dead, and not possible to switch back. Manually trying to rotate wheels, and one wheel was like braking. Clear message from mosfets. Good they are cheap and easy to get. Hope it’s only this.

btw , how do you secure board power during development? External power source with limited current? I only have 30v max bench regulated power supply…

and what means beeps? Twice beep, long break , repeat . I have always this sound.

RoboDurden commented 9 months ago

Search all places where BuzzerSet is used. Strg+Shift+F in the Keil ide.

pacraf commented 8 months ago

Transistors arrived - board is back alive! hooray no other damages except 2 mosfets.

today I tested your newest version (uploaded binary hoverboard 2.0 single UartBus) with Lolin and works great. THANK YOU.

below is my modified but working testspeed sketch with remote RC link on Lolin S2mini (in case someone looks for simillar things) it is dirty test from today, but WORKS!

//    Tested with Lolin S2 mini + FrSky receiver D4RII in CPPM mode 
//  
//    
//
//    please share feedback to https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x

#define ESP32
#define _DEBUG      // debug output to first hardware serial port
//#define DEBUG_RX    // additional hoverboard-rx debug output
#define REMOTE_UARTBUS

#include "util.h"
#include "hoverserial.h"

#include <PPMReader.h>
byte interruptPin = 3;
byte channelAmount = 4;
PPMReader ppm(interruptPin, channelAmount);
const float a = 0.6; //this is to convert results from channel values (1000lowest-2000max) to -300 to +300 to test
const int b = -900; //this is to convert results from channel values (1000lowest-2000max) to -300 to +300 to test
int result = 0;

#ifdef ESP32
  #define oSerialHover Serial1    // ESP32
#else
  #include <SoftwareSerial.h>    // not compatible with RCReceiver because of interrupt conflicts.
  SoftwareSerial oSerialHover(9,8); // RX, TX 
  #define oSerialHover Serial    // Arduino
#endif
SerialHover2Server oHoverFeedback;

void setup()
{
  #ifdef _DEBUG
    Serial.begin(115200);
    delay(2000); // wait some time after reset - to see below message
    Serial.println("Hello Hoverbaord V2.x :-)");
  #endif

  #ifdef ESP32
    HoverSetupEsp32(oSerialHover,19200,39,37);      // baud, rx, tx
  #else
    HoverSetupArduino(oSerialHover,19200);    //  8 Mhz Arduino Mini too slow for 115200 !!!
  #endif

  pinMode(LED_BUILTIN, OUTPUT);
}

unsigned long iLast = 0;
unsigned long iNext = 0;
void loop()
{
  unsigned long iNow = millis();
  digitalWrite(LED_BUILTIN, (iNow%2000) < 500);

  //int iSpeed = 3 * (ABS( (int)((iNow/20+100) % 400) - 200) - 100);   // repeats from +300 to -300 to +300 :-)
  //int iSteer = 1 * (ABS( (int)((iNow/400+100) % 400) - 200) - 100);   // repeats from +100 to -100 to +100 :-)
  int iSteer = -100;
  int iSpeed = 0;
//if belo uncommented then you can see all channels and values - this code is from example sketch from library PPMReader  
// for (byte channel = 1; channel <= channelAmount; ++channel) {
//        unsigned value = ppm.latestValidChannelValue(channel, 0);
//        Serial.print(value);
//        if(channel < channelAmount) Serial.print('\t');
//  }
//  Serial.println(); 
result = ppm.latestValidChannelValue(3, 0);  //my channel with speed stick on remote is no.3
// beware this is testing only - if RC link is down - result is 0 so it needs to be secured
if (result > 995) {
iSpeed = (result * a) + b;
} else {
iSpeed = 0;
Serial.println("dead RClink"); 
}
//Serial.println("iSpeed="+iSpeed); 
  boolean bReceived = Receive(oSerialHover,oHoverFeedback);   
  if (bReceived)
  {
    DEBUGT("millis",iNow-iLast);
    DEBUGT("iSpeed",iSpeed);
    DEBUGT("iSteer",iSteer);
    HoverLog(oHoverFeedback);
    iLast = iNow;
   }

  #ifdef REMOTE_UARTBUS
    if (iNow > iNext)
    {
      iNext = iNow + 100;
      //DEBUGLN("time",iNow)
      int iSpeedL = CLAMP(iSpeed + iSteer,-1000,1000);
      int iSpeedR = -CLAMP(iSpeed - iSteer,-1000,1000);

      HoverSend(oSerialHover,1,iSpeedL);  // hoverboard will answer immediatly on having received this message ...
      delay(10);
      HoverSend(oSerialHover,2,iSpeedR);  // but wait 10 ms for the RX line to be clear again
    }
  #else
    if (bReceived)  // Reply only when you receive data
      HoverSend(oSerialHover,iSteer,iSpeed);
  #endif

}
RoboDurden commented 8 months ago

great to hear that you succeedd with hoverboard reapir.

Which library do i need to download: #include ?

Would be nice if you add the steering channel to your code. I think a rc-remote can do this.

And as i stated in my latest youtube video, would be great if someone with a 2.0 setup could test my latest master-slave binaries. Good to see that my single binary does work for you. But if you add the steer channel to your code, you would need to test my master-slave binaries as well :-))

Will be happy to add your code to the Arduino_Examples/ folder.

RoboDurden commented 8 months ago

Have uploaded your code to https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/Arduino%20Examples/Esp32_PPM/Esp32_PPM.ino

I guess you do not have a speed/steer rc remote but only a skateboard speed remote. So someone else will need to complete your code example

pacraf commented 8 months ago

I see that you found lib - yes this is exactly the one you pointed out. magic of community. regarding steering - this is my goal, I have proper RC , but I just started and when it started to rotate - I had to write this post with results :) of course I will try all mentioned by you configurations and come back with feedback.

iSteer - what value should be to both wheels go together the same speed? I realized that for this single board precompiled uart controlled, I have to set i to -50 to have reasonable reaction for iSpeed. zero and positive - no rotation

RoboDurden commented 8 months ago

iSteer should be 0 for both wheels rotating at same speed. my

      int iSpeedL = CLAMP(iSpeed + iSteer,-1000,1000);
      int iSpeedR = -CLAMP(iSpeed - iSteer,-1000,1000);

was just written by me on the fly and might not be a good solution.

If you continue with the master-slave binaries, then this will be done by the master firmware with that strange conversion table in main.c

const float lookUpTableAngle[181] =  
{
  -1,
  -0.937202577,
  -0.878193767,
  -0.822607884,
        // Map to an angle of 180 degress to 0 degrees for array access (means angle -90 to 90 degrees)
        steerAngle = MAP((float)scaledSteer, -1000, 1000, 180, 0);
        xScale = lookUpTableAngle[(uint16_t)steerAngle];
RoboDurden commented 8 months ago

Concerning your -50, maybe this is the reason in main.c

    // Calculate inactivity timeout (Except, when charger is active -> keep device running)
    if (ABS(pwmMaster) > 50 || ABS(pwmSlave) > 50 || !chargeStateLowActive)
    {
        inactivity_timeout_counter = 0;
    }
    else
    {
        inactivity_timeout_counter++;
    }
pacraf commented 8 months ago

loaded both boards with corresponding bin files: hoverboard 2.0 master Uart.bin hoverboard 2.0 slave.bin and testspeed sketch with setup:

#define _DEBUG      // debug output to first hardware serial port
#define DEBUG_RX    // additional hoverboard-rx debug output
//#define REMOTE_UARTBUS

But hardware respone is very sloppy, look here: https://youtu.be/frPZTAOgM8E https://youtu.be/CxJg5ny1UF4 single "uartbus" board behaves smoothly I am doing something wrong?

terminal messages from this "choppy" moments look like:

 CD AB -> iOdomL: -262      iOdomR: 261     iSpeedL: -0.63   iSpeedR: 0.64      iAmpL: 0.20  iAmpR: 0.40        iVolt: 34.99
 :-))))))))))
millis: 109 iSpeed: -201    iSteer: -26 iOdomL: -262        iOdomR: 261     iSpeedL: -0.63   iSpeedR: 0.64      iAmpL: 0.20  iAmpR: 0.40        iVolt: 34.99
pacraf commented 8 months ago

hmmm if it helps with above, when loaded my sketch with cppm (rc control) , then master-slave behaves well - as expected, the same smothness like i got with "single uartbus"

added steering , it works ok https://youtu.be/CxJg5ny1UF4

when I commented all debug/print to console, it works smooth... when debug to console enabled - choppy

RoboDurden commented 8 months ago

I do not understand what you mean with: when loaded my sketch with cppm (rc control) Do you get smooth spinning with hoverboard 2.0 master Dummy.bin + hoverboard 2.0 slave.bin ? It looks like only one direction is stuttering. Do both master and slave stutter in one direction or only the master ?

I have uploaded new binaries for you. have changed the uartBus ids from 1+2 to 0+1

RoboDurden commented 8 months ago

Ah you updated your comment.

when debug to console enabled

So this causes the stuttering:

#define _DEBUG // debug output to first hardware serial port

pacraf commented 8 months ago

I am writing chaotic messages. sorry for confusing. let's sort it out. for a time beeing we can forget my scenario with rclink;. only master - slave binary , and your testspeed sketch. the problem is (it was not like that before) that with enabled debug motors work "choppy" like on my short videos above when disabled debug - work smoth it was not like that before... do you have also this behaviour?

RoboDurden commented 8 months ago

Please be exatct an copy the code lines so i can see what you mean with "disabled debug". Also name the complete bin files and not "testspeed sketch".

I do not have a master-slave test setupup. So i can not test master+slave binaries.

pacraf commented 8 months ago

loaded to hooverboard files hoverboard 2.0 master Uart.bin hoverboard 2.0 slave.bin

loaded to lolin your example TestSpeed sketch : https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/Arduino%20Examples/TestSpeed/TestSpeed.ino

with ONLY modified part (commentd RemoteUart - because with that it not works with master-slave):

#define _DEBUG      // debug output to first hardware serial port
#define DEBUG_RX    // additional hoverboard-rx debug output
//#define REMOTE_UARTBUS

with this as above - debug enabled - choppy as on videos

when like below (commented debug_rx) it work not choppy

#define _DEBUG      // debug output to first hardware serial port
//#define DEBUG_RX    // additional hoverboard-rx debug output
//#define REMOTE_UARTBUS

But if you do not really have this master-slave hardware - then hard to see you what is the problem.

RoboDurden commented 8 months ago

Okay, the DEBUG_RX define is realy only for debugging the serial protocol when CRC is not working. This is only for developers and has no use when adding functionality to the esp32. So yes, maybe this DEBUG_RX output can delay the serial communication and cause the stuttering/choppy.

But with hoverboard 2.0 master Dummy.bin or hoverboard 2.0 single UartBus id0/1.bin you do not get that choppy behavior ?

The choppy spinning might also be because you do not fasten your hoverboard and it can swing forward and backwards.

It might be that this simple firmware is a bit choppy in one direction..

pacraf commented 8 months ago

hoverboard 2.0 master Dummy.bin + hoverboard 2.0 slave.bin = goes very nice.

for hoverboard 2.0 single UartBus id0/1.bin I have to mace hardware connections. to ensure before will do something stupid. Master -slave original connection shuld be removed (phisically disconnect cable) ? with uartbus it should be like here below? what about starting on the slave board, it need to be "button started" separately? right? image

RoboDurden commented 8 months ago

Yes, thanks for the nice image. I will use it in the main readme to illustrate the UartBus :-) The slave board should get on by itself when the master board gets on - i think.

You do not need to test the uartBus if you are already happy with hoverboard 2.0 master Uart.bin + hoverboard 2.0 slave.bin That was the configuartion that i can not test. So if that works nicely with //#define DEBUG_RX , everything is fine.

Would be nice if you publish your final PPM speed+steer .ino file here :-)

pacraf commented 8 months ago

Image please do not use it, I will add gnd to picture. Some noobs may connect only Rxtx. Will send better pic. I will test it tommorow I think. Please explain me what is max range for send values of iSpeed and iSteer ?

In your opinion, if aim of this would be rccontrolled lawnmower, you would go with master-slave , or uartbus ? I think both are good for that, but maybe I am missing something?

pacraf commented 8 months ago

ok, here is pic as promised. image

pacraf commented 8 months ago

and limits for iSpeed and iSteer are the same -1000 to 1000 , right?

RoboDurden commented 8 months ago

Yes, +-1000 for both speed and steer. But I have never used steer.

One guy once asked for a 180° turn for his lawn mower.

I would not use master slave for lawn mower, I guess. With uartBus you can control left and right separately and with iOdom in the Feedback you can calculate a 180° turn.

There is also an advanced gps that gives you mm-cm precision. There are some hacks for that with esp32..

My idea was to first travel the border of the area manually via WiFi or rc remote and then the lawn mower is cutting the inside.

You might easily find a closed loop algorithm based on iOdom where you do command via rc Controller not a speed or steer but something like 108cm forward and then turn 37° left..