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
- 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
Find our exciting google code here!
Recent Code Changes:
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
- 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
echo "text to send" | > /dev/ttyS0
- 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)
get Pololu working
- test autonomous-ness of boat's code
get ready to demo for Eng Banquet, sidewalk sale
- make guides to linux, software
intro, email out code to look at, intro to C guides with exercisesrefer 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 withTS-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</font> - 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??
find arduino emulator to test programs onSail_Code#Using_the_ELEC299_Simulator
- 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 librariesArduino 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 specificationSail Code on dropbox
ResearchSailing Polar Plot
- write to wind sensor Ryan
- X-CTU wireless programming How_to_Zigbee#Wireless Arduino Programming dependant on hardware task first and non-critical
test pololu with arduinoPololu_Micro_Serial_Servo_Controller#Pololu_and_Arduino
compassCompass and wind sensorWind Sensor with arduino Arduino#Arduino_Serial_Ports Compass#On_arduino
test zigbee with arduino(How_to_Zigbee#Zigbee_with_Arduino) How_to_Zigbee#Working_Notes
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 MASTORRyan
- finish orange tasks from other months
Find some good sailing logic/terms explanations NateSailing Terms
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 checksumReading and Parsing Data Steve
Move to version-controlled codeVersion 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
- 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 17thJan 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 codeBenchmarking 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
- 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
BetaAlpha 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
- 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)
- code deadline
Goals and PrioritiesEdit
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?
Software Design GuidelinesEdit
- Keep it simple.
- 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.
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
Software Team ManagementEdit
Here's some interesting resources on how to create good productivity in software teams.
These links, ideally, need to be sorted into their appropriate pages, now that there are many more pages on the wiki.
All items (47)