You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be excellent to have a simple simulator so that we can test the software without needing to download it to the rover. To do the we put simulate a motor controller that takes a duty cycle and then we must use this duty cycle to simulate the encoder counts such that the motor 'spins' proportional to the duty cycle. We also need to have rover configuration values that are currently in the c++ firmware to make this work; wheel diameter, axle length, ticks-per-revolution, etc. We also need to simulate the stall value and min and max speeds for the motors. Ideally the simulator configuration would be in a web ui that is shown only if the simulator is running; although we could start by compiling it into the simulator.
Simulated rover configuration
wheel diameter
axle length
ticks-per-revolution for wheel encoders
stall value for duty cycle (value below which encoder produces zero)
motor speed (revolutions/sec) at stall value
maximum motor speed (revolutions/sec) at full duty cycle.
The simulator will be a version of the c++ application compiled to web assembly and executed in the browser. The simulator version of the code will replace real motor drivers and encoders with simulations.
simulated motor and encoder
input is duty cycle
duty cycle is applied first against stall value; it is is below stall value that revolutions are zero.
if it is not below stall duty cycle is used to scale between min and max motor revolutions
motor revolutions and the time delta are used to produce a tick count for that motor's encoder.
When in simulator mode we won't actually open a web socket to the rover; so how do we simulator this communication? That is TBD. We may simulate the web socket as well.
If we can simulator the motors/encoders/websocket commands then all of the web application should work as it does with the physical esp32cam. So we can see the motor and pose telemetry, we can enter the calibration values, etc.
The text was updated successfully, but these errors were encountered:
To simulate the websocket api we need to implement two public interfaces, one in the javascript code and one in the c++ code.
Javascript implements the command processor in command_socket.js. It returns a CommandSocketType object that is used to communicate over the command socket. That is constructed by the CommandSocket() function. We want to a version of the CommandSocket() function that implements a simulated socket over a bridge between the WASM simulator and the JavaScript.
The c++ firmware implements the command socket interface defined in command_socket.h. We want to use an implementation that talks over a WASM bridge to the JavaScript.
We can implement the c++ WASM as a web worker so it will run on its own thread and not block the JavaScript. We can then just use window.PostMessage() to send data between the web worker and the web page to simulate the web socket.
It would be excellent to have a simple simulator so that we can test the software without needing to download it to the rover. To do the we put simulate a motor controller that takes a duty cycle and then we must use this duty cycle to simulate the encoder counts such that the motor 'spins' proportional to the duty cycle. We also need to have rover configuration values that are currently in the c++ firmware to make this work; wheel diameter, axle length, ticks-per-revolution, etc. We also need to simulate the stall value and min and max speeds for the motors. Ideally the simulator configuration would be in a web ui that is shown only if the simulator is running; although we could start by compiling it into the simulator.
The simulator will be a version of the c++ application compiled to web assembly and executed in the browser. The simulator version of the code will replace real motor drivers and encoders with simulations.
When in simulator mode we won't actually open a web socket to the rover; so how do we simulator this communication? That is TBD. We may simulate the web socket as well.
If we can simulator the motors/encoders/websocket commands then all of the web application should work as it does with the physical esp32cam. So we can see the motor and pose telemetry, we can enter the calibration values, etc.
The text was updated successfully, but these errors were encountered: