-
Notifications
You must be signed in to change notification settings - Fork 6
Development Process
This is an overview of our development process. In order to avoid integrating testing issues, much of the code process is done within ESW before reaching out to the rest of the team.
Given a new hardware device to create the interface for, begin by reading through the data sheet and taking note of relevant registers and what communication protocol should be used. If you are unfamiliar with the protocol, or there are new elements introduced, do some more research on that as well. Google and older MRover members are great places to look.
Determine what the interfacing subteam wants from this hardware. For example, 'the ISH subteam wants temperature readings from the thermistor for each of the three sciences.' Structure your code around this.
The first step should be to get the program to run without error-ing out. This can be done without the hardware initially. At the point where you need the hardware to test further, continue debugging the code until you are able to get reasonable data/outcomes.
Create a README.md following the README guide on the embedded-testbench wiki page. Add the appropriate TODOs
Contact the embedded software lead for a quick code review. Make sure that the code is readable and reasonably commented.
Create some sort of physical tests with the hardware and record the data you are receiving. If it's something that is harder to eyeball, like an accelerometer or a gyroscope, write the data to a text file and analyze it either in excel or matlab. If the results of the analysis don't make sense, go back to the datasheet and make sure the you have all the correct settings, and are reading/scaling data in the correct way.
At this point, you are ready to build the code using the MRover build system - jarvis. Either on the hardware, or in your virtual machine, ./jarivs build your program, and make the appropriate bug fixes until it is able to be built. If it is using python smbus, you will eventually get an IOError while building unless you have the hardware.
Once the program builds and you have all the hardware, you are ready to ./jarivs exec the code. If this is successful you can move on to creating the LCM interface.
Now you should take a look at the LCM guide on the embedded-testbench wiki if you are not familiar with LCM or need a refresher. Additionally, you should take a look at the relevant LCM ICD for this project, and create a .lcm struct as specified by that. Add the appropriate subscribe/publishing commands, and once again attempt to build and exec this program using jarvis.
Test that the LCM interface works, either by lcm_tools/echo-ing the channel that data is being published to and/or lcm_tools/sending commands to the subscriber channel and verifying that the hardware is responding appropriately.
Contact the embedded software lead again for a code review. During this you must have neat well-commented code, a README that follows the guide exactly, and can demonstrate that the hardware works as expected in a robust fashion. Once this code review is finished, make the required fixes if necessary.
The code at this point has been verified to work off rover. At this point it will be tested onboard connected to the Jetson, and any arising problems will be debugged. An electrical team member must be present along with the embedded software lead.
At the point you will test the code with the relevant interfacing subteam to make sure it does everything that is specified by them. If any code changes are made, update the README.
Make a pull request from your branch to the umrover/esw-master branch on github. It will be reviewed by the software lead, and any comments to the pull request must be addressed before it can get approved.