Category:Software

The Software section of MAST handles everything programming and computer-based.

New? Check out the Software Learning Guide for a list of the most important wiki pages.

This category should include information on Find our exciting google code here! =Code=
 * Polar wind plots (sailing)
 * Reference code for serial communication and PWM control
 * Sailing logic
 * PID control
 * Sailing simulations
 * Linux info
 * XML Wikia Backups <- Do this weekly, dump to dropbox.
 * Version Control of software
 * Compilers and Simulators for Arduino

Recent Code Changes:

http://pipes.yahoo.com/pipes/pipe.run?_id=3763be1c0dd1781e106f787ce43ea713&_render=rss&atom_feed_url=http%3A%2F%2Fcode.google.com%2Ffeeds%2Fp%2Fqmast%2Fupdates%2Fbasic|filterout=changed|date|max=5|short =Timeline 2010/2011=

Tasks
For a list of small useful programs to be written and tested, see the Software Function Development page.


 * Pololu control of motors
 * test Pololu responding to RS232 from the computer
 * serial output from the micro-controller test to run motor -> determine what was causing program to crash


 * Sensor input into body of program
 * ensure data being received is not corrupted (optional; there's a checksum we can enable)
 * setup a program to write to the wind sensor and modify it's default 'send' settings
 * compass is fine as-is


 * revise sailing logic
 * research this
 * look at past years code to see what they've done and why


 * simulation program? (maybe from WRSC contacts?)
 * research sailing info
 * includes: simulating the boat's response to motors being activated, possibly include delays; simulating the boat's response to changes in the wind, including slowing down as a result of having sails set incorrectly; can simulate tacking, which would be very difficult, or just assume all tacks taken above a minimum speed were successful


 * PID control
 * research this
 * look at past years code to see what they've done and why


 * Polar logic for wind sensor data
 * research this; do we have boat speed information from our present sensor setup?
 * look at past years code to see what they've done


 * menu setup for program operation
 * build basic text-response menu setup and test with zigbee
 * make list of "options" that can be selected
 * split code into discrete functions (should be ok), returning all variables necessary

echo "text to send" | > /dev/ttyS0
 * X-CTU workaround to minicom?
 * find out why minicom isn't working via zigbee
 * see if straight-up sending commands to the dev/ttyS0 device works; look into this.. it's something like
 * could this be a Zigbee settings/firmware problem?


 * make a guide for the software setup
 * how to install embedded linux on the micro-controller
 * how to setup linux as it is on the MAST computer (which packages installed, and where?)
 * guide to minicom
 * guide to zigbee setup
 * guide to programming (already written)

Timeline
postponed delayed complete


 * August
 * get Pololu working
 * test autonomous-ness of boat's code
 * get ready to demo for Eng Banquet, sidewalk sale
 * make guides to linux, software


 * Sept
 * intro, email out code to look at, intro to C guides with exercises refer to these as we go: this one for C, up until lesson 14, programming style, and the other 4 linked at the bottom, makefiles, finding segfault bugs, writing secure code (virus-aware)
 * wiki markup, wiki intro
 * explain/teach sail code basic sections
 * test pololu motor control with TS-7260 ; not working? test with arduino
 * water test day
 * teach linux programming basics
 * get team setup with bootable linux discs? (USB to maintain settings?)
 * crash arduino - serial RS232 input is being el terrible, hardware problem? fixed using MAX3232 chip; no wait it's broken again; we need to get static-protection equipment??


 * Oct
 * find arduino emulator to test programs on Sail_Code
 * bench-mark arduino coding; motor change speed on PWM pins vs sending serial to pololu; serial in; serial out; major math functions Tom Benchmarking_Code
 * look up linux RS232 input/output buffers
 * write baby-functions to do RS232-out and in with arduino/ linux, using pre-built libraries Arduino tempermental
 * write menu program, make list of tasks to include in menu Ryan Sail Code
 * read old code to determine what is in it; complete code specification Sail Code on dropbox
 * Research PID
 * Research Sailing Polar Plot
 * write to wind sensor Ryan
 * X-CTU wireless programming How_to_Zigbee dependant on hardware task first and non-critical


 * Nov
 * referendum
 * test pololu with arduino Pololu_Micro_Serial_Servo_Controller
 * test compass Compass and wind sensor Wind Sensor with arduino Arduino Compass
 * test zigbee with arduino (How_to_Zigbee) How_to_Zigbee
 * port old Sailcode to arduino. Main tasks: Compass (--) , Wind (--) & Parser, scanf (Steve) Sail Code Reading and Parsing Data
 * source laptop
 * NMEA parsing with TinyGPS Nate
 * Become a wind sensr manual MASTOR Ryan
 * finish orange tasks from other months
 * Find some good sailing logic/terms explanations Nate Sailing Terms


 * Dec
 * Test all ported code together ->requires functional RS232->TTL converter!! Problems with serial data corruption; also needs error checking
 * revise code, land test/water test if lake not frozen (shouldn't be?)
 * Use menu to test RC/autonomous switch-overs with multiplexer old MUX working with LEDs, not tested properly with motors (believe that while testing, arduino wasnt properly connected to Pololu)
 * Alpha test sail code before lake freezes Problems with serial data; wont be able to water test until March/April/When the lake melts/We get a swimming pool
 * if alpha successful, start working on Polar and PID logic
 * Change parser to accept $xxxx,256,,N,135,N,...*FF type of data which will still clear the checksum Reading and Parsing Data Steve
 * Move to version-controlled code Version Control
 * Find a way to test code from home - arduino-specific would be great, if it doesn't exist just C is fine Compilers and Simulators


 * Jan
 * revise code, land test
 * Write/find code to check the "checksum" on the NMEA data (*hh) needs testing on arduino, & include more rigorous data checking of NMEA sequences based on their status codes inside parser; also look for any errors which occur if the data checking fails -> perhaps check the length of the data string before parsing to save time if fields are guaranteed blank, or check for NULLs returned during parsing Jan 17th Jan 21 Val
 * Complete a FULL systems test including multiplexer - Jan 31; Pololu broke so this is delayed until Pololu is replaced
 * Use benchmarking code on a full sailing loop to determine main delays in code Benchmarking
 * Integrate menu into alpha code
 * Obtain sailing systems prototype to use in parking lot - Jan 24th?? depends on Pololu
 * Start to optimize compass and wind data packet frequency; trouble with compass writing
 * Look into interrupt-driven serial data, learning about interrupts
 * Improve basics of the rudder and sail control algorithm in design/code/test cycles, with land-testing - Jan 24th*** Improve basic course navigation functions*** Improve motor control/response to inputs
 * Determine if we need to change the rate that compass/wind data is sent to the boat, what is sent
 * Benchmark alternative solutions where applicable


 * Plan a "stay in the box" navigation function


 * Feb
 * Write a "stay in the box" navigation function
 * Ensure reliable basic "sailing" on land (parking lot with portable elec system)
 * complete code, get ready for Beta Alpha test when lake thaws
 * Work on more advanced sail control algorithm improvements Features will be worked on if there's time before the lake melts*** Collecting sailing data via zigbee; applications to polar plots and tuning boat construction
 * Advanced sailing techniques
 * Simulation code for testing (this could be as simple as outside data simulation, instead of getting data from a serial port, get it from a class which generates data depending on the wind conditions and the boat's internal variables)
 * Add updated and accurate GPS
 * Testing, map compass direction vs actual speed over ground from GPS to determine boat's leeway
 * Write a function to approach a target angle based on sensor data
 * March
 * final code revisions, water testing
 * bug fixing of water bugs
 * check serial data code by itself; then combine with pololu motor turning (which we know already is working by itself)


 * April
 * code deadline

Goals and Priorities
Software Planning has our goals laid out.

Boat Sailing Performance criteria - quantify/rank our goals for:
 * Autonomous navigation accuracy
 * Speed obtained (from sail trim/ rudder control/ canting keel)
 * Collision avoidance (for year after)

Team performance criteria - qualify/quantify/rank goals for:
 * Skills attained
 * Interest/ attendance/ involvement / responsibility /communication

Other key decisions/rank priorities of these:
 * what level of interfacing with the people on the shore is appropriate?
 * would interrupts be a good way to program the sail code?
 * should we work on a simulation program?
 * other?

=Software Design Guidelines=
 * Keep it simple.
 * Document.
 * Each line should have an explanation of: what the variable represents, why the logic is that way, which port the code drives, whether there are other options for this line of code we considered but didnt use, etc. Include links.
 * Each function should have a detailed comment at the top which describes what it does and why it exists, and any foreseeable future improvements
 * Each function should have a detailed comment at the top which describes the input variables, output variables, and internal variables (alternatively, descriptions can be written as a comment after each variable)
 * Write in Short, testable chunks
 * Basics of starting a program
 * common mistakes to look out for
 * Beginner tips on errors and basics of program design
 * Beginner programming - tips to learn
 * Learn C in 21 Days - Beginner programming guide.


 * Thread of free/open flowchart software

Testing Procedures
Testing is important! It will save much time and grief later, and a few comments go a huge way.


 * Comment each line explaining why it's necessary as you write.
 * Test the code as you write.
 * This can be done with the ELEC299 simulator; or with the Arduino 0021 IDE for code which cannot be compiled on the simulator (specific to the Arduino Mega 2560)
 * Test for functional accuracy (expected results) with the simulator
 * before and after drastic changes to the structure
 * every 10 lines of coding
 * Record unexpected testing results in a comment, either at the top of the function or at the line of code which had unexpected behaviour
 * Test in both "expected conditions" and "abnormal conditions" ie parsing a line of normal data from sensors, and data that starts half-way through a line

Interesting article about Software Quality Assurance

Software Team Management
Here's some interesting resources on how to create good productivity in software teams.

Producing better code the first time

Scheduling

Writing code specifications

=External Links= These links, ideally, need to be sorted into their appropriate pages, now that there are many more pages on the wiki.

RS232 guide

Linux Serial comm

the PWM controller that simmons has

sample linux RS232 code that doesnt work

example of input and output processing with RS232

great guide to TS7260 XDIO commands

FTP with a few more sample programs

mailing list archive

TS-SER4 expansion board description

programming guide

programming guide 2

yahoo users group