Unhashable type for Systec interface errors
まだ誰も着手していません。
評価
- 難易度
- 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 のエラーコードと、特定の失敗する lookup が示されています。例外を構築したときに TypeError を発生させるのではなく、元の CAN エラーが公開されることを確認してください。Systec ハードウェアが利用可能な場合は、提供された DroneCAN スクリプトが統合チェックになります。
索引モデルが issue の本文から書いたものです。
説明
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 はありません
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
hardbyte/python-can のほかの issue
-
bug
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
hardbyte/python-can#1922 · リアクション 1 件 ·
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
hardbyte/python-can#2102 ·
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
hardbyte/python-can#2092 ·
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
hardbyte/python-can#2091 ·
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
hardbyte/python-can#2083 ·
hardbyte/python-can の issue をすべて見る
似ている issue
-
documentation help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
simonw/sqlite-utils#872 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100