i. That the hardware is running correctly,
ii. What kinds of things the entry-level participant can look forward to, and
iii. Perhaps a tutorial for getting started.
There may be other applications that I didn't think of, but which make sense in our broader context.
The team involved in doing this would expect to code up one or more
of these apps, possibly building on code developed in the main project.
iv. Build the Java glue code for new hardware as it becomes desirable to incorporate it in the project, and/or
v. Transition the development environment into C++.
My experience is that working in Java offers productivity far exceeding the cost of extra glue code, but I seem to be in a minority in this opinion. There is opportunity for a team or subgroup to explore this option, perhaps by translating the Java code at some (working) stage of the main team's development into C++ to see how hard it is to work in that environment.
vi. Rewrite Firmata code so it does exactly what we need (and thus eliminate package dependency), and/or
vii. Translate some of the hardware currently being added on into Arduino code -- for example, the deadman switch -- into additional Arduino code, probably added onto or replacing the Firmata package.
Either or both of these would require the team so tasked to learn how to program the Arduino (there are rumors that its compiler is actually for Java ;-) and develop procedures for installing our custom code in place of the existing Firmata code.
viii. A subgroup or small team could be tasked to investigate how to do this effectively, and to determine what kinds of computations can be usefully off-loaded to the GPU.
ix. A subgroup or two could spin off to study the software requirements to implement a MIPI interfaced camera.One possibility is to use a MIPI camera with a USB interface added, which is still somewhat cheaper than what we have. The cameras Steve looked at recently mostly had (uncompressed) YUV coding, for which you can find simple conversions to/from RGB here, and byte ordering here. You still need to develop the necessary Java driver glue -- see item (iv) above to rebuild the drivers.
x. Port our development environment and Java code over to Linux on Pi using (iv) above to rebuild the drivers, or else
xi. Use (v) above to port our development environment and code over to C++ on Linux on Pi.
xii. Design an interactive website to attract prospective group mentors and participants,
xiii. Design and implement a startup procedure for bringing another group up to speed understanding the technology, and then adding to it in their own geographical region, and
xiv. Come up with a competition to which the various groups can bring their creations to both compete and share for the benefit of all participants.
I consider all of these options to be significantly harder than developing autonomous car software in Java on Win10, so there is a substantial risk that you may not succeed in completing your efforts in the four weeks of our summer program, but these are all useful things to do for the long term success of the High School Autonomous Car Project (or whatever you-all decide to call it), and if you are suitably motivated, you could continue working on them after the main program ends August 10. Almost certainly you would have something to show on August 10, and a statement of why it is useful, and what is left to finish -- sort of the way the Neural Nets group did last year, except presumably you would actually finish and your work would become part of the group project next year.
Any questions or comments? This is your project.
Tom Pittman -- Starting July 13 through the end of the 4-week workshop, use the email given on July 16 to reach me.
Back to Part 8
Back to Part 7
Rev. 2018 July 9