Can someone provide an example of Arduino code for communication about bipropellant-hoverboard-firmware HOT 28 CLOSED

also check out @p-h-a-i-l 's repos. He has an eps32 project ongoing....

from bipropellant-hoverboard-firmware.

@AntumArk

In machine protocoll you dont receive human readable answers. You get an array of byte and you have to parse it. Some Terminals cannot display bytes out of a-z and 0-9 range and display an ? As for that.
You need to view the bytes itself to read it.
If you enabled ascii mode than it is a different storry.
Hope everything is correct :)

from bipropellant-hoverboard-firmware.

yes, i think so, nothing obviously wrong.

from bipropellant-hoverboard-firmware.

@atc1441: I added simple sample code for sending. Not tested yet, so if you or @AntumArk could quickly test ;) See #56

And when receiving, should I expect to receive full structure of electrical_params or just certain parts?

with code 0x08 you will get a full set of electrical params

typedef struct tag_PROTOCOL_ELECTRICAL_PARAMS{
    int bat_raw;
    float batteryVoltage;

    int board_temp_raw;
    float board_temp_filtered;
    float board_temp_deg_c;

    int charging;

    int dcCurLim; // amps*100
    int dc_adc_limit; // limit expressed in terms of ADC units.

    PROTOCOL_MOTOR_ELECTRICAL motors[2];

} PROTOCOL_ELECTRICAL_PARAMS;

from bipropellant-hoverboard-firmware.

Let's try to use it as a chance to improve our documentation ;)

from bipropellant-hoverboard-firmware.

It does not work for me,
It just dont moves, but havent debuged it any further because no time 🗡
here is a typo: 58d1adb#diff-04c6e90faac2675aa89e2176d2eec7d8R62 the M needs to be m

i also tested to change cmd to W but that didnt helped

from bipropellant-hoverboard-firmware.

Sry for answering myself, i got last night a bid further and got the set PWM with the help of the nodered example working.

int cc;
void PrintHex8(uint8_t *data, uint8_t length) // prints 8-bit data in hex with leading zeroes
{
char tmp[16];
for (int i = 0; i < length; i++) {
sprintf(tmp, "0x%.2X", data[i]);
Serial.print(tmp); Serial.print(" ");
}
}

typedef struct MsgToHoverboard_t {
unsigned char SOM;
unsigned char CI;
unsigned char len;
unsigned char cmd;
unsigned char code;
byte base_pwm1;
byte base_pwm2;
byte base_pwm3;
byte base_pwm4;
byte steer1;
byte steer2;
byte steer3;
byte steer4;
unsigned char CS;
};

typedef union UART_Packet_t {
MsgToHoverboard_t msgToHover;
byte UART_Packet[sizeof(MsgToHoverboard_t)];
};

void setHoverboardPWM1( int32_t base_pwm, int32_t steer )
{
UART_Packet_t ups;
cc++;

ups.msgToHover.SOM = 2 ;
ups.msgToHover.CI = cc;
ups.msgToHover.len = 2 + 4 + 4;
ups.msgToHover.cmd = 'W';
ups.msgToHover.code = 0x0d;
ups.msgToHover.base_pwm1 = base_pwm;
ups.msgToHover.base_pwm2 = base_pwm >> 8;
ups.msgToHover.base_pwm3 = base_pwm >> 16;
ups.msgToHover.base_pwm4 = base_pwm >> 24;
ups.msgToHover.steer1 = steer;
ups.msgToHover.steer2 = steer >> 8;
ups.msgToHover.steer3 = steer >> 16;
ups.msgToHover.steer4 = steer >> 24;
ups.msgToHover.CS = 0;

for (int i = 0; i < ups.msgToHover.len; i++) {
ups.msgToHover.CS -= ups.UART_Packet[i + 1];
}
Serial1.write(ups.UART_Packet, sizeof(UART_Packet_t));
PrintHex8(ups.UART_Packet, sizeof(UART_Packet_t));
Serial.println();
}

setHoverboardPWM1(100, 100);

i took the PrintHex8 function to bedder see what the esp32 is sending.

i tried some other functions and it looks quite good. what i still dont understand, wich functions can i use and for example the setPwm wasnt doing anything if i send minus values, so -300 doesnt move the wheels.

also the answers does not seem to match, i get a Nack from the hoverboard, do i have to send an answer everytime the HB sends something ?

from bipropellant-hoverboard-firmware.

Thank for that. I already was aware of that. But after your hint i looked closer and that is what i am searching. I tought it was only for his minimalistic protocoll wich is a bid different.

from bipropellant-hoverboard-firmware.

be aware that the bippropellant-protocol repo has branches where it no longer depends on global variables from the main repo; it's not quite finished yet, but we should be left with something easier to build into the controller. What we are struggling with is how to keep the data structures between controller code and hoverboard code synchronised once we've removed them from the protocol repo :).

from bipropellant-hoverboard-firmware.

Just a stupid question to that, why the hustle of that it no longer depends on global variables?

Isnt it is fine like it is? Or is it easyer if for example someone has a whole different HB and want to include the bippropellant-protocol?

Just so i understand it.

from bipropellant-hoverboard-firmware.

@atc1441
ups.msgToHover.cmd = 'W'; - means Write command?
ups.msgToHover.code = 0x04; -means set PWM?

from bipropellant-hoverboard-firmware.

@AntumArk yes that is how i understand it.

The code is descripte here https://github.com/bipropellant/bipropellant-protocol/blob/b0beb80e2d764529c12eb831e7a035ea88992799/protocol.c#L623

from bipropellant-hoverboard-firmware.

Just a stupid question to that, why the hustle of that it no longer depends on global variables?
e.g. @p-h-a-i-l has a simplified version.
The 'protocol' itself at one level is very generic, and could be used for many other purposes.... not just hoverboard or similar control. When looking for a generic protocol to use, I did not find anything I liked which was simple enough to implement (not that this one is actually any simpler in the end :) ).
The pain we feel is having to update both repos at the same time. Once separated, this should no longer be an issue....

from bipropellant-hoverboard-firmware.

Receiving a. bunch of ???? means that command is not recognized?

from bipropellant-hoverboard-firmware.

Ok, sorry that i have to write again, in the repo https://github.com/p-h-a-i-l/hoverboard-control there is an example of the protocoll but it is either the old one ore the simplified version.

there is no CI so counter handling involved and no NACK or ACK answering, still dont know if i need to answer it everytime i recive a HB message.

I am having problem to changing the code from output.cpp from https://github.com/p-h-a-i-l/hoverboard-control to make use of the CI counter.

here is some code i tested:

typedef struct tag_PROTOCOL_MSG {
unsigned char SOM; // 0x02
unsigned char CI;
unsigned char len; // len is len of ALL bytes to follow, including CS
unsigned char bytes[254]; // variable number of data bytes, with a checksum on the end
// checksum such that sum of bytes len to CS is zero
} PROTOCOL_MSG;

void protocol_send(PROTOCOL_MSG *msg) {
unsigned char CS = 0;
unsigned char *src = &msg->len;
for (int i = 0; i < msg->len; i++) {
CS -= *(src++);
}
msg->bytes[msg->len - 1] = CS;
Serial1.write((const uint8_t *) msg, (size_t) msg->len + 4);
Serial.println();
Serial.println("Sende Jetzt:");
PrintHex8((unsigned char *)msg, (size_t) msg->len + 4);
Serial.println("zu ende");
}

void protocol_send_drive( int32_t base_pwm, int32_t steer ) {
cc++;
char tmp[] = { PROTOCOL_SOM, cc,10, 'W', 0x05, base_pwm, (base_pwm >> 8), (base_pwm >> 16), (base_pwm >> 24), steer, (steer >> 8), (steer >> 16), (steer >> 24), 0 };
protocol_send((PROTOCOL_MSG *)tmp);
}

from bipropellant-hoverboard-firmware.

you should increment CI on send, and expect the ACK/NACK response to have YOUR CI.
Receiving CI (EXCEPT ACK/NAK), you should expect it to increment every message (else its a re-send), and should respond with ACK and the SAME CI to every message - even duplicates.

from bipropellant-hoverboard-firmware.

Thank you for the fast reply.
I think i will try to rebuild the arduino part from scratch and see how far i will get.
The good thing is that the protocoll is rock solid if it runs correctly. The bad thing is to get there :)

Have a good evening.

from bipropellant-hoverboard-firmware.

I have managed to implement speed control with C#. It is quite similar to @atc1441 . But for now I am not using ACK/NACK. I will work on it tomorrow.
@btsimonh I have noticed that if you disconnect from USART, hoverboard keeps on spinning. Shouldn't it stop when it lost connection?

from bipropellant-hoverboard-firmware.

probably. We should implement a formal heartbeat with a timeout to kill motion.

from bipropellant-hoverboard-firmware.

@btsimonh Can I create new issue for it? This would prevent runaway robots.

from bipropellant-hoverboard-firmware.

and a PR? :).

from bipropellant-hoverboard-firmware.

Hi again, so after alot of hours into the protocol and searching i was finaly able to use the hoverboardapi from p-h-a-i-l with the arduino ide and with the current protocol.

It is kind of hidden but here ist a link to his platformio project with the current protocoll: https://github.com/p-h-a-i-l/hoverboard-control/tree/testrun

i got rid of everything i didnt need and put every file in the src folder, this way it is also possible to compile the code directly in the arduino ide.

here is a short video of my current status: https://youtu.be/4yjYoxfnXfc

from bipropellant-hoverboard-firmware.

Sorry for leaving such a messy repo behind :) The GPN and a vacation took their toll..
Thanks @btsimonh for filling in for me! I'm excited to see what you guys did wit sinus. Just started reading through heaps of messages ;)

from bipropellant-hoverboard-firmware.

@atc1441 - very nice :).
@p-h-a-i-l - will be good to see what you think of the new drive in your setup. I think we've wound most of the bugs out now, the final one being the current limit. But I do want to see if we can re-work it again for a very slim interrupt routine, and for slow 'static' drive of the motors. Good to have you back!

from bipropellant-hoverboard-firmware.

Is it correct packet for current measurments?
byte[] b = new byte[6];
b[0] = 2;
b[1] = CI;
b[2] = 2;
b[3] = (byte)MessageRequestType.READ;//'R'
b[4] = (byte)MessageCodes.ELECTRICAL_MEASURMENTS;//0x08
b[5] = (byte)((0 - b[1] - b[2] - b[3]-b[4]) & 0xff);

from bipropellant-hoverboard-firmware.

And when receiving, should I expect to receive full structure of electrical_params or just certain parts?

from bipropellant-hoverboard-firmware.

So it is possible to communicate without ACKs? I wish I knew it before...

from bipropellant-hoverboard-firmware.

Tested and merged the example to the README. Also made a small change to https://github.com/bipropellant/bipropellant-protocol/wiki/Protocol-Defn to indicate the existance of no-ACK capabilities.

from bipropellant-hoverboard-firmware.