Closed podhrmic closed 2 years ago
On the libusb side, something like the script at http://billauer.co.il/blog/2013/02/usb-reset-ehci-uhci-linux/ might work to kick the USB devices, but the tool would have to be updated to do that in the event that it loses a device and then re-identify all the USB devices once they're (hopefully) back as the USB TTYs might (OK, probably will) change.
I have attempted to group the above tasks by priority (where "priority" here is more like "impact on demonstrator usage").
@EthanJamesLew a short sketch how the infotainment should work:
@podhrmic
From the issue #1243
a short sketch how the infotainment should work:
- Infotainment client / UI
- listens to port 5013
- sends CAN_ID_BUTTON_PRESSED to port 5002
- listens for CAN_ID_X/Y/Z/R on port 5013 and displays the update on the map
- Infotainment Server (3x)
- listens for CAN_ID_BUTTON_PRESSED on port 5002
- sends CAN_ID_INFOTAINMENT_STATE to port 5002
- Ignition
- selects which server to listen to based on the active scenario
- listens for CAN_ID_INFOTAINMENT_STATE on port 5002 from the whitelisted server
- updates volume/music based on the CAN_ID_INFOTAINMENT_STATE message
- when it receives position update from BeamNG it sends CAN_ID_X/Y/Z/R message to port 5013
background.js
infotainment_defs.h
can.py
infotainment.py
can_out.py
The infotainment server (on the SSITH processors) currently forwards the X, Y, Z, R messages (and keeps track of the car's position, so that duplicative ones - if the car sits in the same place for a long time - don't go to the thin client and cause GPS jitter). Only those messages should go to 5013. That's what I think is described above in infotainment.py
right now (it only forwards GPS messages from the active infotainment server, not from BeamNG, to the thin client).
Known issues as of 8/3:
High Priority:
Fewer BeamNG restarts(known issue with beamngpy, wont fix)Review activity monitor and avoid spurious switching between manual/self-drive(seems to work fine)Should we be switching out of self-drive if a hack is active?(we are right now, given how the monitors work)Medium Priority:
Low Priority:
Transition times between Hacker UI screens are relatively fast - make them slower, so the FPGAs have time to reset.(faster component reset seems to fix this issue)CAN display is not showing the messages@lolsborn (a reset fixed it)music on/off
state in INFOTAINMENT_STATE messageBacklog
Libusb sometimes errors withUsing two NUCs instead of one.LIBUSB_ERROR_NO_DEVICE
and the tool exits - what do we do about it? (reset/swap cables/pray)Add a state for the initial reset (so we are starting from a known good state)I updated the state description to capture this.Spurious resets of ignition. This is very likely caused by BeamNG freezing, and us resetting the ignition <-> BeamNg connection. Not much we can do here IMHO. @EthanJamesLew what do you think?Force feedback seem to stop working after LKAS hack is initiated (the wheel jerks once or twice, then is silent). The car is still being moved around, but without the haptic feeling. @lolsborn will follow up on this.(needs more testing)