Unhashable type for Systec interface errors

未关闭 适合新手
#2,077 1 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
1/5
预计耗时
1 小时以内
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
python
领域
embedded-iot

调研方向

从 can/interfaces/systec/exceptions.py 中的 UcanError.init 开始,跟踪 can/interfaces/systec/ucan.py 中由 check_result 传递的结果。报告指出了一个 ctypes.c_ubyte 错误代码以及一次特定的失败查找。请验证构造该异常时会暴露原始 CAN 错误,而不是引发 TypeError;在有 Systec 硬件可用时,所提供的 DroneCAN 脚本可作为集成检查。

由索引模型根据 Issue 内容生成。

描述

bug
Describe the bug

When running DroneCAN on top of the systec interface, error messages that appear raise TypeError: unhashable type exceptions. This swallows the actual error messages and prevents troubleshooting.

The cause of error messages is likely a config/hardware issue, so it is probably irrelevant. What matters is that the CAN error messages disappear and are not relayed to the user.

To Reproduce

Below is a script to monitor messages coming through DroneCAN. Error messages do not always happen, but they tend to be triggered by sending commands through DroneCAN.

The actual mechanism triggering error messages is more likely a config/hardware issue than anything.

Expected behavior

The error message raised during operation should be exposed to the user.

Additional context

OS and version: Windows 11
Python version: 3.10
python-can version:
python-can interface/s (if applicable): systec

Traceback and logs

Traceback:

Traceback (most recent call last):
  File "c:\Users\thoma\OneDrive\Documents\Tyto\Python scripts\test.py", line 51, in <module>
    dc_node.spin(timeout=0.001)
  File "C:\Python310\lib\site-packages\dronecan\node.py", line 439, in spin
    execute_once()
  File "C:\Python310\lib\site-packages\dronecan\node.py", line 431, in execute_once
    frame = self._can_driver.receive(read_timeout)
  File "C:\Python310\lib\site-packages\dronecan\driver\python_can.py", line 137, in receive
    self._check_write_feedback()
  File "C:\Python310\lib\site-packages\dronecan\driver\python_can.py", line 124, in _check_write_feedback
    raise item
  File "C:\Python310\lib\site-packages\dronecan\driver\python_can.py", line 101, in _writer_thread_loop
    self._bus.send(msg)
  File "C:\Python310\lib\site-packages\can\interfaces\systec\ucanbus.py", line 212, in send
    self._ucan.write_can_msg(self.channel, [message])
  File "C:\Python310\lib\site-packages\can\interfaces\systec\ucan.py", line 488, in write_can_msg
    UcanWriteCanMsgEx(self._handle, channel, c_can_msg, c_count)
  File "C:\Python310\lib\site-packages\can\interfaces\systec\ucan.py", line 109, in check_result
    raise UcanError(result, func, arguments)
  File "C:\Python310\lib\site-packages\can\interfaces\systec\exceptions.py", line 16, in __init__
    message = self._error_message_mapping.get(result, "unknown")
TypeError: unhashable type

Script to recreate the bug:

import can
import dronecan
from dronecan.driver import python_can as pycan_driver
from dronecan.app.node_monitor import NodeMonitor
import time

can_bus = pycan_driver.PythonCAN(channel=0, interface="systec", bustype="systec", bitrate=1000000)

node_id = 45

dc_node = dronecan.node.Node(can_bus, node_id=node_id, bitrate=1000000)

print("=== Local Node ===")
print(f"  node_id : {dc_node.node_id}")
print(f"  mode    : {dc_node.mode}")
print(f"  health  : {dc_node.health}")
print()

# Print every NodeStatus as it is received:

def on_node_status(event):

    print(
        f"[NodeStatus] from node {event.transfer.source_node_id}: "
        f"uptime={event.message.uptime_sec}s "
        f"health={event.message.health} "
        f"mode={event.message.mode}"
    )
 
dc_node.add_handler(dronecan.uavcan.protocol.NodeStatus, on_node_status)

LISTEN_SECONDS = 10

monitor = NodeMonitor(dc_node)

print(f"Listening for {LISTEN_SECONDS} seconds...\n")
deadline = time.monotonic() + LISTEN_SECONDS
while time.monotonic() < deadline:
    try:
        dc_node.spin(timeout=0.001)
        msg = dronecan.uavcan.equipment.esc.RPMCommand()
        msg.cmd = int(0)
        dc_node.broadcast(msg)
    except dronecan.transport.TransferError as ex:
        print(f"  (transfer error, continuing: {ex})")

dc_node.close()

With Claude, I tracked down the error to interfaces/systec/exceptions.py. A ctypes.c_ubyte error code is passed to the Python interface, and the systec backend fails to interpret it. By changing Line 16 in exceptions.py, I can see the underlying exception and original error message:

message = self._error_message_mapping.get(result, "unknown")

should become

message = self._error_message_mapping.get(result.value, "unknown")

This seems to have solved the issue, and now I can troubleshoot my hardware problems better. I cannot make a PR for this at the moment, but I might later.

主要语言
Python
星标
1.6k
派生
697
PR 合并指标
30 天内没有已合并 PR

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

hardbyte/python-can 的其他 Issue

查看 hardbyte/python-can 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。