Demonstator laundry list

[podhrmic]

Known issues as of 8/3:

High Priority:

• [x] #1064
• [x] Infotainment servers don't work - not possible to change music/station @dmzimmerman / @EthanJamesLew
• [x] Re-implement infotainment backend in Python @podhrmic
• [x] Touch display input is rotated 90 degrees from screen on startup because configuration script is not being run on startup.
• [x] Implement #1246 and the corresponding state machines @podhrmic
• [x] Update hacker-kiosk state machine docs
• [x] Implement heartbeat functionality (in-out) @EthanJamesLew
• [x] #1202
• [x] Kiosk UI without the debug monitor
• [x] (check before shipping) CAN-UI starts reliably (as far as we can tell)
• [ ] 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)
• [x] Robustify hacker kiosk
• [x] Truncate GPS coordinate decimal points
• [x] Fix "Station changed to XXX" message on hacker kiosk

Medium Priority:

• [x] Improve the state machine so the reset happens more gradually - ideally reset FPGA1 once we are out of the baseline scenario, the same for the infotainment servers. That way there is no interruption at the end of the scenario. @podhrmic
• [x] Fix subprocess calls to hacks in kiosk.py in "test" mode (bug) @podhrmic
• [x] #1249

Low Priority:

• [x] Cameras are not switching in the UI for different hacks @lolsborn
• [ ] 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)
• [x] CAN display is not showing the messages @lolsborn (a reset fixed it)
• [x] #1234
• [x] #1071
• [x] #1062
• [ ] Set local time to East Coast for better debugging/logging
• [ ] Disable Wifi on all components
• [ ] Make music always play? No music on/off state in INFOTAINMENT_STATE message

Backlog

• [ ] Libusb sometimes errors with LIBUSB_ERROR_NO_DEVICE and the tool exits - what do we do about it? (reset/swap cables/pray) Using two NUCs instead of one.
• [ ] 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)

[dmzimmerman]

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.

[dmzimmerman]

I have attempted to group the above tasks by priority (where "priority" here is more like "impact on demonstrator usage").

[podhrmic]

@EthanJamesLew 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

[EthanJamesLew]

@podhrmic

Infotainment Notes

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

Thin Client Implementation

• background.js
  • Can network is setup for port 5013 -- strictly listens
  • dport is set to 5002 -- strictly sends

Ignition UI / Player Handler Implementation

• infotainment_defs.h
  • SEND_PORT and RECEIVE_PORT are 5002
• sends CAN_ID_INFOTAINMENT_STATE, CAN_ID_CAR_X, CAN_ID_CAR_Y, CAN_ID_CAR_Z, CAN_ID_CAR_R

Infotainment Server

• can.py
  • defines three networks and can be toggled
  • both networks listen in on 5002
• infotainment.py
  • InfotainmentPlayer listens on 5002 to the CAN_ID_INFOTAINMENT_STATE
    • updates channel and volume inside of this callback
  • InfotainmentPlayer listen on 5002 of position (x, y, z, r) and forwards it to 5013
• can_out.py
  • sends position (x, y, z, r) on 5002

[dmzimmerman]

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).