Reading is broken with the latest firmware

[alex-makarov]

After updating to the latest firmware (the one with 'Breaking change for serial protocol') the API (and therefore protocol) only works in the direction "TO hoverboard". The data is being read FROM the hoverboard, but callbacks are never triggered -- looks like something is wrong with the parser.

[alex-makarov]

Some more details: I've made sure that both the firmware and API use the latest commit of the protocol. Hoverboard control works fine, both from my code and from debugMachineProtocol.py, e.g.

37> BipropellantPacket(raw=bytearray(b'\x00w(\x03R\r\x01'), rawDecoded=bytearray(b'\x00w(\x03\r\x01R'), ACK=0, CMD='w', CI=40, LEN=3, code='0d', CS='52')
ACK 0 CMD w CI 40 LEN 3 code 0d bytearray(b'\x00w(\x03\r\x01R')

I assume the ACKs are read correctly. However, no hall sensor data and no electrical measurements are being received. Other than that, periodically it seems to get the response for ASCII protocol unlock when not actually being asked to:

BipropellantPacket(raw=bytearray(b'\x00\xceB\x01\xf0 W\x99\n- \x07\x08W\xff\xff\xff\xa9\x01\x01\x99 W\x99\r\nLocked. Enter unlockASCII to enable ASCII input mode.\r\n>Locked. Enter unlockASCII to enable ASCII input mode.\r\n>\x07\x08\x91'), rawDecoded=bytearray(b'\x00\xceB\x01\xf0'), ACK=1, CMD='N', CI=66, LEN=1, code='f0', CS='f0')
ACK 1 CMD N CI 66 LEN 1 code f0 bytearray(b'\x00\xceB\x01\xf0')

[alex-makarov]

Fixed with https://github.com/bipropellant/bipropellant-hoverboard-api/pull/18

[DDennis1]

I used your Code from #18 but the reading still does not work for me. I tried the readSpeed example to make sure it's not a fault on my site but I'm just getting random or zero values. Any Idea?

[alex-makarov]

In my case the fix from #18 definitely helped, as there's clearly a bug in there. Try updating the protocol submodule to the latest commit.

[Cirromulus]

With everything in master and with the fix #18, at least active polling works. ScheduleRead does not, however.

[bwees]

I used your Code from #18 but the reading still does not work for me. I tried the readSpeed example to make sure it's not a fault on my site but I'm just getting random or zero values. Any Idea?

Did you ever get this working? I have the exact same issue, even having cases where my arduino just completely crashes :/

[bwees]

I've narrowed it down to not getting any replies from the hoverboard. I am able to successfully send data with the arduino (ie control motors, beeper, etc), when I connect it to my serial adapter I can use the ASCII API perfectly fine but reading does not work on every Arduino I have tried (Mega, ESP32, Uno, Nano). I don't thing the correct commands are getting sent from the library if I am not getting any response. I am checking the response directly from where I do Serial.read() so reading has nothing to do with the library.

[bwees]

I am actively polling instead of scheduleRead so that is also not the issue. This is one of the packets that is being set by the library. I am on @alex-makarov fork on the ctor-fix branch. I have the latest hbprotocol module as well (commit 6ed1d7a)

0x00 0x52 0xF8 0x02 0xAE 0x08

[Cirromulus]

I am able to successfully send data with the arduino (ie control motors, beeper, etc), when I connect it to my serial adapter I can use the ASCII API perfectly fine but reading does not work on every Arduino I have tried (Mega, ESP32, Uno, Nano).

This might have something to do how you open the serial. At least under Unix (probably Windows as well), you might want to open it raw and disable the Kernel's Flow control.

If this helps, this is a snippet of my C-Code that interacts with the Hoverboard (https://github.com/pilsbot/pilsbot_hw_ros/blob/foxy-devel/pilsbot_driver/src/pilsbot_driver.cpp#L460-L473):

    // HB specific
    struct termios options;
    tcgetattr(*fd, &options);
    options.c_cflag = B115200 | CS8 | CLOCAL | CREAD;  //<Set baud rate
    options.c_iflag = IGNPAR;
    options.c_oflag = 0;
    options.c_lflag = 0;
    tcflush(*fd, TCIFLUSH);
    if(tcsetattr(*fd, TCSANOW, &options) < 0) {
      RCLCPP_ERROR(rclcpp::get_logger("PilsbotDriver"),
          "hoverboard: Could not set terminal attributes!");
      perror("tcsetattr");
    }

    api = new HoverboardAPI(serialWrite);

[bwees]

I am running this on arduino not Unix.

Brandon Wees On Nov 26, 2023 at 2:41 AM -0600, Pascal @.***>, wrote:

I am able to successfully send data with the arduino (ie control motors, beeper, etc), when I connect it to my serial adapter I can use the ASCII API perfectly fine but reading does not work on every Arduino I have tried (Mega, ESP32, Uno, Nano). This might have something to do how you open the serial. At least under Unix (probably Windows as well), you might want to open it raw and disable the Kernel's Flow control. If this helps, this is a snippet of my C-Code that interacts with the Hoverboard (https://github.com/pilsbot/pilsbot_hw_ros/blob/foxy-devel/pilsbot_driver/src/pilsbot_driver.cpp#L460-L473): // HB specific struct termios options; tcgetattr(fd, &options); options.c_cflag = B115200 | CS8 | CLOCAL | CREAD; //<Set baud rate options.c_iflag = IGNPAR; options.c_oflag = 0; options.c_lflag = 0; tcflush(fd, TCIFLUSH); if(tcsetattr(*fd, TCSANOW, &options) < 0) { RCLCPP_ERROR(rclcpp::get_logger("PilsbotDriver"), "hoverboard: Could not set terminal attributes!"); perror("tcsetattr"); }

api = new HoverboardAPI(serialWrite); — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[Cirromulus]

Ah sorry, misread that comment