Arduino on Cloud

Do NOT attempt this task. It has already been implemented

The current buzzer is programmed only to give output (a) 'high' i.e. 'sound is on' or (b) 'low' i.e. 'sound is off' and at a specific frequency. The tone() function of the Arduino generates a square wave of the specified frequency (and 50% duty cycle) on a pin. The syntax for using tone is tone(pin, frequency, duration). Based on the frequency and duration set in the tone(), songs can be played using Arduino. Since, the current system does not support tone(), the songs are not playable. In this screening task you need to add this functionality by modifying 'ArduinoFrontend/src/app/Libs/outputs/Buzzer.ts' and such other files.

Reference:

https://www.arduino.cc/reference/en/language/functions/advanced-io/tone/

https://github.com/robsoncouto/arduino-songs

In the Arduino on Cloud platform, the majority of the components are already available, like Arduino Uno, Breadboard, Buzzer, Seven-Segment-Display, LCD, etc. In this screening task, we propose to add the following components: 

1. DHT-11 Sensor

2. L293D Motor Driver IC  (Do not attempt it)

3. LDR (Photoresistor)  (Do not attempt it)

4. Thermistor  (Do not attempt it)

5. 7447 decoder IC

6. ESP8266 wifi module with a logic level convertor from 5v to 3.3v

Please refer to the following Spoken Tutorials to understand the interfacing of the above components to Arduino Uno and the way sketch files (.ino) are written.  

https://spoken-tutorial.org/watch/Arduino/Pulse+Width+Modulation/English/

https://spoken-tutorial.org/watch/Arduino/Analog+to+Digital+Conversion/English

https://spoken-tutorial.org/watch/Arduino/Wireless+Connectivity+to+Arduino/English/

https://spoken-tutorial.org/watch/Arduino/Digital+Logic+Design+with+Arduino/English

You are free to choose any two components from the above list, build and integrate in our system, such that it does not break the existing code.

(Do not attempt this task)

In this task, you are required to have versioning support for code files and the circuit schematic. You would need to design and implement the required functionality so that the circuit history is maintained. One of the uses is that the creator of the circuit can view different versions in time and revert to a particular version. Another use is in maintaining the history that can then later be used by experts to analyze the way people build circuits. 

The following are the possible improvements and bug fixes:

1. Ability to undo and redo the actions done by the user (placing and moving of components, changing colors of wires, connecting components, etc.) (Do not attempt it)

2. Rotate components on the schematic. While attempting this task use 'arduinoRotateComponent' branch as it has been attempted partially. https://github.com/frg-fossee/eSim-Cloud/tree/arduinoRotateComponent Also refer to the link given for more information on existing code and bugs. https://github.com/frg-fossee/eSim-Cloud/pull/199

3. Ability to resize individual components with respect to breadboard

4. When an item is placed, i.e., soldered, over a breadboard, and if you move the board, the item should also move with the board). https://github.com/frg-fossee/eSim-Cloud/issues/421 (Do not attempt it)

5. Ability to change the duty cycle for all PWM pins on the Arduino (Do not attempt it)

6. Deleting a breadboard and adding it again causes the circuit to freeze (Do not attempt it)

7. Deleting a wire on a breadboard, deleted other wires too (Do not attempt it)

8. Deeply nested circuits on breadboard (Do not attempt it)

9. Collision of wires (Do not attempt it)

10. Support for Input pull-up (Do not attempt it)

11. Login in the dev enivronment (Do not attempt it)

12. Two/Multiple pins/legs of different components should be soldered into the same point/hole of the breadboard.

13. Incompatible size of components w.r.t. breadboard. Refer the GitHub issue link for more information: https://github.com/frg-fossee/eSim-Cloud/issues/183 (Do not attempt it)

14. Placing components on the first two lines or the last two lines of the breadboard will lead to short circuit on the physical breadboard. Currently, this is not the case in our system. In fact, the circuit gets simulated. We should handle this by either showing a popup to the user while the component is being dropped or when the simulate button is clicked.

15. LED/Buzzer issue: If the 'negative' of LED/Buzzer is connected to pin 13 of Arduino using breadboard and positive pin of LED is not connected (basically 0) connected anywhere on breadboard, even then the LED glows. This can be checked by connecting using wires (one leg at 0 and another at 5V). Ideally, the LED should not glow. This is true for buzzer too. (Do not attempt it)

16. After zooming in, one cannot connect components or draw wires on the breadboard. The issue is not at the source/starting point, but at the destination/end point. 

17. When navigating to Home, Gallery, etc. from the editor, it displays a pop up for saving a circuit even if the circuit is already saved. It should display only if the circuit is not saved.

18. Disable dragging components on the schematic while the circuit is being simulated (Do not attempt it)

19. Disable adding new components on the schematic while the circuit is being simulated (Do not attempt it)

20. Disable deleting components from the schematic while the circuit is being simulated (Do not attempt it)

21. When the potentiometer is not connected properly (none of the pins are connected or only certain pins are connected), on simulating it shows a message 'Potentiometer is not connected properly'. However, when one stops the simulation, the dial of the potentiometer gets misplaced. Before simulating, move the potentiometer one or two times to a different place on the editor.

22. On clicking the Home button in the navigation toolbar, it shows a popup of whether you would like to save the circuit or not. Even if 'Save' is clicked, the circuit does not get saved. The circuit gets saved if other items in the toolbar are clicked, i.e. Dashboard, Gallery, etc.

23. Deleting a breadboard if any component is present on it, causes an error and the components which were present on the breadboard still remain connected to a virtual breadboard. Ideally, on deleting the breadboard, all components present on it should also be deleted. Check the browser console for the error message.  (Do not attempt it)

24. Auto scroll the text in the black console/terminal window when simulating circuits that print out something on the console repeatedly.  (Do not attempt it)

25. When one loads the circuit from the gallery or uploads the circuit using json, immediately i.e without the user making any change an undo operation should not be allowed. The undo stack should be clear.

26. The resistence value set for the resistor should be saved when the circuit is (a) exported using a json, (b) saved on cloud, and (c) saved temporarily.  (Do not attempt it)

27. If the no .ino code is written then while simulating, there should be a popup stating that no code is written and no call should go to the backend for compilation. This activity should happen in the frontend only.

28. If the user has already connected certain pins on Arduino but the .ino code does not reflect such pin numbers or vice versa, then on simulation, an error message should be displayed in the frontend without making a call to the backend.

29. Currently, for writing .ino code, it is required for the Arduino board to be present on the schematic. This limitation should be removed. One should be able to write code irrespective of the Arduino board being present or not. Similarly, if the Arduino board is deleted the code should not be deleted.  

30. One should be able to change the font size of the ino code. Display a dropdown with font sizes and as the user chooses the size, the font size of the code should change

31. One should be able to re-size the code window horizontally.

Consider a Temperature sensor, an analog device having 3 pins, i.e., VCC, GND, and analog output. When the user drags-and-drops on the schematic, the system should automatically suggest connecting to appropriate pins of Arduino, i.e., to VCC, GND, and one of the analog pins of Arduino, respectively. Design and implement such functionality such that the user experience is enhanced while designing. This can be implemented as a rule-driven mechanism.

When the user connects/interfaces components to the Arduino board, there should be a real-time mechanism to automatically generate the .ino code files. Much of the components have a standard code which can be auto-generated. 

(Do not attempt this task)

Presently, only sketch .ino files (c code) are supported, as the backend arduino code compiler  does not have the ability to compile. Your task is to add support for compiling assembly language. Please look at the GitHub issue which mentions the problem and possible approach in solving it: https://github.com/frg-fossee/eSim-Cloud/issues/164 

Please do not attempt this task. It is currently being addressed.

Learning Tools Interoperability, also called as LTI, is a way in which an LMS (learning management system like edX, Moodle, Canvas, Blackboard, etc. addressed as LTI Consumer) communicates with external tools/systems/utilities, addressed as LTI Producer (Arduino on Cloud). To a normal user, it appears as if the external tool is embedded into the LMS in a frame. 

LTI Consumer: The instructor adds the LTI tool (resource, in our case a circuit) into the LMS using the LMS tool and enters information like secret, key, and URL. When the students view the resource, i.e., a circuit, the LMS uses the secret, key, and URL to activate the resource such that the resource can be viewed by the students in a remote tool/iframe. 

LTI Producer: The external tool, in this case Arduino on Cloud, receives the request containing information like secret, key, URL, user identity, course information, etc. This is communicated via HTTP using OAuth to ensure security of the data that is sent. The external tool then renders the resource to the requested user.

In this task, you need to add LTI support to the existing Arduino on Cloud application in the manner described above. 

Links for Reference

http://www.imsglobal.org/activity/learning-tools-interoperability 

https://github.com/rohitjose/django-lti-auth

https://github.com/Harvard-ATG/django-app-lti

Please do not attempt this task. It is of low priority at present. It will be addressed in the future. 

The users in the existing system do not have any roles assigned to them. They are allowed to create a circuit and share the link. Hence, the circuit is visible only to the user or to only those who have the link. There is no facility to collate circuits at one place for everyone to see. The task is to do the following:

• Role management system: Provide a facility to configure roles in the system. Some example roles are contributor, reviewer, etc.. Each user should be associated with a particular role. The roles and the association with the user should be configurable by the system admin, i.e. there should be a facility to add, edit, and delete roles. 

• Circuit state management: Provide a configurable workflow such that a circuit moves from state 1 to state N; where State 1 denotes that the circuit is visible only to the user while State N denotes that the circuit is visible to everyone. Consider an example where the states are: Draft, Ready for review, and Published and roles are contributor and reviewer. A contributor, when creating a circuit, it goes in the Draft state initially. To convey/notify the reviewers that he/she would like to publish, the contributor can change the state to ‘Ready for review’. At this state, the reviewer reviews the circuit and changes the state to either ‘Draft’ i.e. the reviewer does not approve the circuit or ‘Published’ depending on the quality. So, there should be a facility to add, edit, delete states and define the transitions i.e. to configure which state is accessible by which user. 

Given below is just a sample. To reiterate, the roles, states, and the workflow, all should be configurable. Also note that, when the reviewer creates a circuit, he is considered as a Contributor and thus, the reviewer for that circuit must be some other reviewer other than the one who created it.

In the draft mode above, the circuits are not visible or published in the public domain. There could also be a mechanism to view all the circuits in various states i.e. all states visible to the public. Such a switch could be set by an authorized user of the system, say admin. The users should then be able to search based on the state and then copy, re-use, modify the circuitry. The number of draft and inactive circuitry (not used for long) can be further hidden by authorized users (admin) to improve the overall search experience.

Please do not attempt this task. It has already been addressed.

Currently, an authenticated user can save the circuit on the cloud. However, there should be a facility for a user to export the circuit in some format (say json) and import the circuit into the system as and when needed.