[BUG]: Creating a brushed Spark Max aborts in sim
Closed this issue · 8 comments
Problem description
Constructing a CANSparkMax with MotorType.kBrushed in simulation causes the robot code to exit with SIGABRT.
[CAN SPARK] IDs: 2, Parameter type mismatch for parameter id Getting Product ID parameter failed. Unable to account for device-specific behavior differences.
[CAN SPARK] IDs: 2, Error Invalid Cannot set motor type to kBrushed for SPARK without a dock connected.
libc++abi: terminating
fish: Job 1, 'python' terminated by signal SIGABRT (Abort)
Operating System
MacOS
Installed Python Packages
Package Version Editable project location
------------------------ ------------------------------------- ------------------------------------------------------
bcrypt 4.1.2
beartype 0.16.4
black 23.12.1
cffi 1.16.0
click 8.1.7
cryptography 41.0.7
cxxheaderparser 1.3.0
delocate 0.10.7
iniconfig 2.0.0
Jinja2 3.1.2
MarkupSafe 2.1.3
mypy-extensions 1.0.0
overtake 0.4.0
packaging 23.2
paramiko 3.4.0
patch 1.16
pathspec 0.12.1
pcpp 1.30
Pint 0.23
pip 23.3.2
platformdirs 4.1.0
pluggy 1.3.0
pybind11-stubgen 2.3.7
pycparser 2.21
pydantic 1.10.13
pyfrc 2024.0.1
PyNaCl 1.5.0
pynetconsole 2.0.4
pyntcore 2024.1.1.0
pytest 7.4.2
pytest-reraise 2.1.2
PyYAML 6.0.1
robotpy 2024.1.1
robotpy-build 2024.0.0 /Users/davidv/dev/frc/robotpy/robotpy-build
robotpy-cli 2024.0.0
robotpy-commands-v2 2024.0.0b4 /Users/davidv/dev/frc/robotpy/robotpy-commands-v2
robotpy-hal 2024.1.1.0
robotpy-halsim-gui 2024.1.1.0
robotpy-installer 2024.0.2
robotpy-rev 2024.0.0b1.post2.dev1+gba85a5563af7 /Users/davidv/dev/frc/robotpy/robotpy-rev
robotpy-wpilib-utilities 2024.0.1.dev0+g58dc9c8ff091.d20240107 /Users/davidv/dev/frc/robotpy/robotpy-wpilib-utilities
robotpy-wpimath 2024.1.1.0
robotpy-wpinet 2024.1.1.0
robotpy-wpiutil 2024.1.1.0
setuptools 68.1.2
setuptools-scm 7.1.0
sphinxify 0.11 /Users/davidv/dev/frc/robotpy/sphinxify
tomli 2.0.1
tomli_w 1.0.0
toposort 1.10
typing_extensions 4.9.0
wheel 0.42.0
wpilib 2024.1.1.0
Reproducible example code
import rev
sm = rev.CANSparkMax(2, rev.CANSparkLowLevel.MotorType.kBrushed)
This is a bug in the revlib library, here's what I see on Linux under gdb:
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff7aae8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff7a5c8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff7a448ff in __GI_abort () at abort.c:79
#4 0x00007fffe96a4d19 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#5 0x00007fffe96b4f4c in __cxxabiv1::__terminate (handler=<optimized out>)
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#6 0x00007fffe96b4fb7 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
#7 0x00007fffe54362c2 in c_REVLib_FlushErrorsAndTerminate ()
from robotpy-rev/rev/_rev.cpython-38-x86_64-linux-gnu.so
#8 0x00007fffe5434873 in c_SparkMax_Create () from robotpy-rev/rev/_rev.cpython-38-x86_64-linux-gnu.so
#9 0x00007fffe542bfc2 in rev::CANSparkLowLevel::CANSparkLowLevel(int, rev::CANSparkLowLevel::MotorType) ()
from robotpy-rev/rev/_rev.cpython-38-x86_64-linux-gnu.so
#10 0x00007fffe542c53d in rev::CANSparkBase::CANSparkBase(int, rev::CANSparkLowLevel::MotorType) ()
from robotpy-rev/rev/_rev.cpython-38-x86_64-linux-gnu.so
#11 0x00007fffe542b42d in rev::CANSparkMax::CANSparkMax(int, rev::CANSparkLowLevel::MotorType) ()
from robotpy-rev/rev/_rev.cpython-38-x86_64-linux-gnu.so
#12 0x00007fffe536e244 in pybind11::detail::initimpl::construct_or_initialize<rev::CANSparkMax, int, rev::CANSparkLowLevel::MotorType, 0> () at robotpy-build/robotpy_build/pybind11/include/pybind11/detail/init.h:77
I sent an email reporting this to rev and got this response:
Thanks for reaching out to let us know about this! I've forwarded this information to our software team and hopefully, we will be able to improve this in an upcoming REVLib update.
Of note, this is new behaviour in the kickoff release. It worked fine in the beta.
@virtuald, have you heard anything from rev about an update or progress before I reach out?
The more paying customers annoy them the more likely they'll actually fix it.
Having the same issue
We just released REVLib v2024.2.1 which should fix this issue
@jfabellera that fixed it, thanks.
See #59 for a new issue that popped up in this release.