pioneers / piecentral Goto Github PK

As title. Was implemented (I think) last year.

Disconnecting Dawn from Runtime crashes the TCP send thread in the TCP process as it throws an error due to the now broken pipe.

We previously had student API documentation autogenerated from docstrings using sphinx, and hosted on readthedocs. It would be nice to do something similar this year.

I am one of several admins for our readthedocs account/subdomain, and can help if you want to reuse that website.

The code in #113 doesn't support these.

Will need to create a UI for handling game features. Experiment whether it can be done through tabs, windows, or a separate app.

Needs:

• Communication Signals
  • Figure out with networking what we need to send to robots
  • (Basically boils down to coordinating game mode changes)
• Student Locks
  • If student’s Dawn is still open, prevent their version of Dawn from making changes to the robots
• Competition Display
  • Fancy bar mechanism to show timings
  • Show robot-related information to debug/check status

New ansible in main/ folder is being written, we should remove the old Ansible.js in the renderer/utils folder. There may still be files importing the older Ansible file, they should be fixed first so nothing breaks when you remove it.

Theoretically, the Peripherals bar could load many peripherals, making it hard to visually read Gamepad data while editing code at the same time. Allow Peripherals to be hidden may help, though it does require some form of sorting.

Overall UI concerns also go in this ticket.

Although fake runtime does send data to the correct place, It doesn't send data that is correctly formatted according to the runtime protos. We should make it actually work.

https://github.com/pioneers/PieCentral/blob/master/runtime/testy/runtime.py#L75

Currently, Ansible.js dispatches a number of actions:

RendererBridge.reduxDispatch(ansibleConnect());
RendererBridge.reduxDispatch(updateStatus());
try {
  const data = RuntimeData.decode(msg);
  RendererBridge.reduxDispatch(updateRobotState(data.robot_state));
  for (const sensor of data.sensor_data) {
    RendererBridge.reduxDispatch(updatePeripheral(sensor));
  }
  RendererBridge.reduxDispatch(updateAllPeripherals(data.sensor_data));

} catch (e) {
  console.log(`Error decoding: ${e}`);
}

This should be reduced to just two actions: one to update the Info state, and one to update the Peripheral state.

In particular, the for loop must be moved into the reducer.

Some nice editor features that shouldn't be too hard to implement

• Have automatic re-opening of last file, e.g. having it saved in persistent local memory
• Have configuration (persistent setting) if students don't necessarily want to see their last file they were working on when they last closed dawn for some reason
• Have menu bar show recently opened files (and easy clicking)
• Have configuration (persistent setting) if for some reason students don't want to be prompted when they close editor without saving that they didn't save

Currently runtime updates are formed by copying the runtime folder into a zip archive. Then the installation will unzip that folder. The previous runtime folder is deleted in the process now.

As it stands, this will probably delete any student code and replace it with the testing file that's in the repo. Some more sensible behavior should happen instead

If you look through the various setup scripts in DevOps/frankfurter, you'll notice that some of the path variables are set incorrectly

As a example, see DevOps/frankfurter/scripts/install/master_frank_setup.sh. The variable FRANKFURTER_DIR is set to PiECentral/frankfurter/, which is a nonexistent directory. It should be set to PiECentral/DevOps/frankfurter/.

These errors happened as a result of the move to the monolithic PiECentral repo. Similar errors are likely sprinkled throughout the DevOps directory, so they should be hunted down and fixed.

NameEdit (Renaming Peripherals) needs a revamp.

Old method was to use a library called React Inline Edit Kit. However, this system did not update values correctly, and the main bug was that "editing" once broke the Name-Edit functionality for the rest of the time. Perhaps we were using the library wrong.

Alternatives that may be explored include Draft.js.

Dawn needs to modify its Runtime API communication to be able to allow for console output to be displayed.

Could try to differentiate errors from non-error through color scheme.

Could try to keep logs of console output for remote debugging.

If the student code has an error such that the entire file can't be parsed (e.g. missing parentheses, bad indentation, etc.), I'm not sure that a meaningful error message is reported to Dawn.

One team had this issue, and I believe all Dawn did was switch back into the idle state.

Might want to find some way to notify user that there is a new version of Dawn or Runtime pushed out.

May expand to actually installing/downloading onto host computer, though this seems very OS dependent.

Currently students can only view and edit one file. In addition, new file erases the current code, so could create a new tab instead.

UI could utilize bootstrap navs

Or, use electron-windows but considering gamepads and peripherals this could be clunky. Maybe main window will show peripherals/gamepads and other windows just the code editor.

Implement keyboard shortcuts for anything useful or that students may want quick access to. Most likely the following features (with rough suggestions for key bindings)
Note: Super refers to Cmd on Mac, Control on Windows

Robot

• Change IP (Super I)
• Upload (Super U)
• Run (Super Y) (Super+R is used to refresh app, maybe change to be Super Shift R)
• Stop (Super W)
• E-Stop (Super E)

Editor

• Increase font size (Super +)
• Decrease font size (Super -)

Misc

• Open Preferences/Config (Super ,)
• Open API (Super P)

We should test all action creators, located in dawn/renderer/actions/

Going to need to create some form of documentation for both student users and staff developers to be able to learn how to use the system. Probably going to be done with the GitHub wiki or with a Google Doc.

In dawn/package.json, a start script is defined which currently only works on Mac, by calling the Electron.app binary on our build/main.js script. We should make it work at least on linux also, where the command should be very similar (without the .app). In general, we just need a way to change the start script being run depending on the platform.

Currently we have actions and reducers for changing editor settings but no UI for the actual user to change those settings. We should make one.

Currently the way hibike finds ports to use is the following:

ports = glob.glob("/dev/ttyACM*") + glob.glob("/dev/ttyUSB*")

This has the side effect of possibly catching non-hibike devices, if they're currently plugged in to the computer. @dHutchings brought up this issue.

I think we can use the serial.tools.list_ports module to find devices while matching for vendor/product ids of the hardware we actually use. This should cut down on the possibility of interfering with random devices.

cc: @karthik-shanmugam

Currently hibike_uid_t UID is defined in example_device.h, and other device headers.

If such a device.h header is included from multiple *.cpp files, the resulting duplicate UID definitions will break the linker.

In practice this is only a problem for more complicated devices (like YogiBear), but the example device (and maybe real devices) should also be changed to avoid this pitfall.

I just started Dawn while not connected to wifi, and got an error:

Uncaught Exception:
Error: send ENETUNREACH 192.168.0.200:1236
    at Object.exports._errnoException (util.js:1022:11)
    at exports._exceptionWithHostPort (util.js:1045:20)
    at SendWrap.afterSend [as oncomplete] (dgram.js:404:11)

I'm running the latest pre-release Dawn.

React-Joyride, the interactive tours mechanism, still has issues loading in Dawn.

Also think of new information to show to students.

within PieCentral/Dawn/readme.md: the link to our stable release is pioneers.github.io/daemon (which doesn't work). The appropriate link to the stable release should be pioneers.github.io/dawn, right?

In the instructions for "Adding new code to master", the git push command should read: $ git push origin {project_name/feature_name} instead of $ git push {project_name/feature_name}

We've noticed that time taken to write to a hibike serial port can spike as high as 3 seconds. Close examination has shown that this is because the read queue for that port fills up, which prevents new operations for being executed against the device.

This means that hibike_message.py::blocking_read cannot effectively keep up with bytes coming in. A hacky fix is

diff --git a/hibike/hibike_message.py b/hibike/hibike_message.py
index 7825bdb..f5e25e4 100755
--- a/hibike/hibike_message.py
+++ b/hibike/hibike_message.py
@@ -332,6 +332,10 @@ def parse_bytes(bytes):
 def blocking_read(serial_conn):
   buffer = bytearray()
   while not parse_bytes(buffer):
+    if serial_conn.in_waiting > 500:
+        buffer = bytearray()
+        serial_conn.reset_input_buffer()
+        print('reset input buffer!!!!!!!!')
     curr = serial_conn.read()
     if struct.unpack('<B', curr)[0] == 0:
       buffer = bytearray(curr)

However, this is just a hack. There needs to be a real fix implemented.

I tried and received a "permission denied."

Uncaught Exception:
TypeError: Cannot read property 'kill' of undefined
    at BrowserWindow.<anonymous> (/private/var/folders/kx/1dxccvcx5bvcbs426mjjjyymbm5qnj/T/AppTranslocation/1F8B67D6-CEE7-4818-8AA3-F453F0315027/d/dawn.app/Contents/Resources/app.asar/build/main.js:1:680)
    at emitOne (events.js:96:13)
    at BrowserWindow.emit (events.js:188:7)

@kevinmasd said he thinks he knows why this is happening.

We should test all reducers, located in dawn/renderer/reducers/.

This is unnecessary for productions, it is only used in development. See this for ideas: https://github.com/gaearon/redux-devtools/blob/master/docs/Walkthrough.md#exclude-devtools-from-production-builds. We already have a process.env.NODE_ENV, so you can check if that variable is equal to 'development'.

Since this project is open source, adding a LICENSE would be beneficial. GPLv3 and MIT are fairly common.

Currently different settings are handled in different ways, some persistent (saved even after you close Dawn), others are not. We should centralize this all into one reducer (the settings reducer) and save that so no settings are lost after closing Dawn.

When I try to flash, it cannot find SPI.h, even though it is a default library. Aside from that, all the code should work.

runtime.py should update studentCode state in SM when studentCode crashes
Ansible needs to constantly pull from SM for currently student Code state.

Last season showed the need for a simulate competition button to be able to test Autonomous. It may also act as the last ditch mechanism if Field Control goes awry.

Need to find a timing mechanism more stable/precise than just setTimeouts.

As of Dawn 0.5.1, when going through the tour, the "Updates" help text reads:

Occasionally we may release updates to the robot's software. When this happens, you will download two files, an update package and its signature, and click on this button to upload those updates to the robot.

This information is outdated--updates are no longer signed, and only require a zipped tarball. This text should be changed to avoid confusion.

[In dawn/renderer/actions/EditorActions, the functions:

{ changeTheme, increaseFontsize, decreaseFontsize }

are duplicates in dawn/renderer/actions/SettingsActions.

As a result, my tests in branch dawn/actiontests may have to be changed as well to remove duplicates.

See here: https://github.com/pioneers/PieCentral/blob/master/hibike/virtual_device.py#L54

I'm pretty sure the set of params here is not at all correct.

The readme should be updated to the PieCentral workflow

We currently are committing compiled protobufs into the main repo. These should be instead placed in the gitignore, once we are able to compile the files on the beaglebone.

Debugging robots requires running through the entire stack (laptop running dawn, wifi routers, etc.). Being able to plug an xbox controller directly into the robot would make debugging far easier.

All sagas are currently located in a single file, dawn/renderer/utils/sagas.js (subject to change if refactored).

May want to look at https://github.com/stoeffel/redux-saga-test.