Comment before pushing the 2.5 software to the GitHub Master branch


#1

Hey folks,

Normally we would capture this type of feedback in the pull request in github itself, but to get the widest audience possible I am opening the readiness of the 2.5 software vs. the existing Master branch to a general forum topic:

The code that is currently in the contorollerboard25 is ready in my opinion to be promoted to master. I don't think I will get any additional feedback from the 2.4 and 2.3 kit users, and the code works for the 2.5 boards. On the flip side, the act of using the git commands to update to the branch is proving a bit tougher to get right while getting it master gets everyone back on the same code path.
There are only two items that I know of that we might want to wait on but I'm not sure they are worth it. Please review and let me know your thoughts:
1) We have seen on the beagle bone white the ability to run out of memory. It resulted in the system basically being unable to complete firmware updates and not allowing anyone to SSH on to the system. I have added a script to create a swap file on disk to extend the available memory. This would potentially affect a bbwhite user that pulls the latest ubuntu disk image from us. The preventive fix:
1a) would be to create a swap file on the disk image before people download it (https://github.com/OpenROV/openrov-image/issues/30) -or-
1b) do the research to figure out where we added to the memory usage and try and reduce it.
2) The current system requires the user of the image to update the Aconfig.h file on disk before they go back to the UI to update the frimware on the Arduino. If they skip this step the system will fail to update firmware (breaks at compile) till they do so, without clear indications of what the problem really is. The fixes we have talked about make it easy enough for cape/controller board users but make things harder for DIY types that have a custom cape/board system (anyone out there that would be affected?). We can fix this if we:
2a) add a UI to the firmware upload to let the user select all of the options that they want to compile in to the firmware with instructions that re-emphasis that the board/cape are normally required.
2b) auto detect the board/cape and set the value on the arduino code before every upload

#2

Quick update. We did run the latest 2.5 image on a 2.4 kit with the beagle bone white and confirmed we are running with about 70MB of ram left on the device so the issue #1 does not seem to be a immediate problem.

For the 2nd issue, added an explicit compiler error that clearly shows that a config is missing in Aconfig.h.


#3

If it works for 2.5 users I say publish it as a disk image and post it as a stable release. Then worry about fiddly bits in the next release. As it is the 2.4 people already have a stable release to fall back on.

It would really help noobs like me to have a known stable release to refer to. If I download a beta and it doesn't work, I don't know if its because its a beta or because I missed something. So then I download one of the other betas etc....

Also the comments attached to the 2.5.1 beta image were quite nice for people new to all of this like me. Thank You