EN CN
Weird behavior and undocumented commands
  • jcobreros
    We are controlling a SimpleBGC Extended using a Tinkerboard through the USB Serial port. The BGC works fine most of the time. We issue position commands and request RTD_4 at a high frequency.

    However, there are two cases that I don't know how to manage.

    If during operation I disconnect the battery from the BGC (The BGC logic is still powered over USB), the BGC enters a state where System Error = 0, and system sub error = 3 (As opposed to, for instance, System Error Battery Low 1). If I then plug the battery again, the gimbal goes quiet. I cannot recover from this error. The BGC ignores CMD_RESET (114) and CMD_EXECUTE_MENU (69) and CMD_ID = 7 (Reset). (By the way, which command should I normally use if I want to reset the gimbal? It seems like CMD_RESET (114) is always ignored)

    The only solution is to close the program on the Tinkerboard and open it again. There are no serial port errors or anything, but the gimbal goes quiet. It's interesting that restarting my app is enough, and I don't have to fully reboot the BGC.

    The second issue I have is when I force the motors to stall for the predetermined ammount of time to force an Emergency Stop, I get System Error = 2048, and System Sub Error = 18, which is not docummented. It seems like the GUI interprets this sub error correctly, and I've implemented it as well, but is there a more up to date Serial Protocol Specification? I'm using v2.6.

    Thanks!!
  • alexmosalexmos
    Hello.

    To reset gmbal controller, send CMD_RESET=114. It should always work, unless you have frozen serial communication. Example: http://ybex.com/d/m3jn0ps7p54ojzs566svl8r4tk4ae8gp3rc3beev.html

    If restarting app helps, it may mean that problem in app rather then gimbal controller. Maybe USB-to-serial driver of serial periphery of Tinkerboard need to re-initialize after some failure, may be you have an error in your command parser which hangs in some state. Note that requesting realtime data at high rates may overflow input serial buffer.

    Serial protocol may miss some recently added codes, structures and so on. we try to keep it up to date. The 2.6x is the most recent version.

    I advise always to use latest firmware (now is 2.68b8) to be sure it's not old bugs.

    Regards, Aleksey
  • jcobreros
    Hello. Thanks for your reply.

    I will look into possible serial driver failure or buffer mismanagement, although the problem is easy to reproduce and as far as I can see, there's nothing strange in the buffer. I will check with a protocol analyzer to see if commands are still being sent correctly.

    Do you see any issues with unplugging the battery while the USB cable is connected? I mean from a power management point of view.

    I think we are on 2.68b7, so I will upgrade as well.

    Thanks!
Add a Comment