CHANGELOG.TXT
This is a porting on a single dsPIC33FJ64MC802 of previous double PID Motor Control (dsPID) formerly performed with two dsPIC30F4012 plus odometry and field mapping formerly performed with a single dsPIC30F3013 (dsODO). So the version numbering of this program starts with 2.0, following dsPID and dsODO versions.
===============================================================================
dsPID33 Version History
2.2.6 - december 2011
- the comments are going to be optimized in order to be compatible with Doxygen sintax
2.2.5 - july 2011
- the procedure to compute the repulsive force field of the obstacles has been optimized
2.2.4 - august 2010
- added transmission of sensors raw data toward console (command Q) this function is implemented on dsNavConsole starting from ver.1.6.1
2.2.3 - june 2010
- field mapping (SLAM) procedures debugged and tested also with dsNavConsole 1.5.0
2.2.2 - march 2010
- found a bug in AnglePID that cumulates a very small amount of error in history (integral part of the PID) at every orientation assignment
- this version is compatible with: version 1.4.0 telemetry console, dsNavConsole Processing sketch version 1.3.0 Arduino SensorBoard sketch
- this is a stable version that performs UMBmark test as shown in: http://www.guiott.com/Rino/RinoUMBmark/RinoUMBmark.htm
2.2.1 - february 2010
- some minor bugs fixed
- it can now be compiled to run on prototype board, Droids 990.011 dsNav board, prototype board with 44pins smd dsPIC or Katodo Robocontroller
- first version that participated to RTC real test in Von Neumann gymnasyum
- most of the time spent on mechanical parameters calibration via UMBmark
2.2.0 - november 2009
- some bugs fixed
- added compass bearing reading from sensors board
- first version for 990.011 Droids board
2.1.5 - june 2009
- start writing of double version for both 28 pin and 44 pin dsPIC series
2.1.3 - may 2009
- Obstacle avoidance code written, yet to test
- Start writing of parameters storage in flash memory
2.1.1 - december 2008
- UART2 communication complete. Sensor board sends obstacles and target data to dsNavCon board.
- Starting development of obstacle avoidance strategies
2.1.0 is a stable version with basic movement functions, useful for demos
2.1.0 - december 2008
- Written an article about Rino, dsNavCon and dsNavCon33, to be published on Circuit Cellar #224-225
- Sensor Board designed, developed and programmed. This board, wrapped around an Arduino board, controls 3 x SRF08 ultrasound range finders, 3 x GP2D120 Sharp infrared sensors, 3 x optical switch bumpers, 3 x light sensors, 2 x Figaro TGS822 gas sensors. This board sends environment infos (obstacle and targets) via serial communication, in order to allow dsNavCon33 to navigate, for both RTC or Explorer senior contests.
- Starting of development for UART2 communication with SensorBoard.
2.0.3 - august 2008 -porting almost completed with some bug fixes and improvements -DMA used for TX simplifies even more the program development and reduces a lot the effort of the DSC.
2.0.4 - october 2008
- full debug on HW done
- PID parameters almost OK, it walks and turns regularly with a good measured precision
- developed Scheduler procedure
2.0.2 - july 2008
- start porting of dsODO part of the project too on a single chip.
- In order to have enough RAM for field mapping, now a dsPIC33FJ64MC802 is used.
- Both speed PIDs are executed every 1ms. Orientation PID every 10ms, distance PID every 50ms.
- Even if all of the three PIDs are executed in un cycle, it requires less then 400us overall.
- everything is a lot simplified without the need of high speed communications between separated MCs and Supervisor.
2.0.1 - july 2008
- both MCs ported. It requires 5.7us to perform both PIDs, 5.37us without ramp.
- With speed calculation (Vel1 = Kvel1*IcIndxTmp/IcPeriodTmp) it requires 26.4us To perform just the PID library function 0.825us
2.0.0 - may 2008
- porting of both MC parts of the project on one dsPIC33FJ32MC302 with two QEI interfaces
===============================================================================
dsPID Version History
1.0 - december 2007
0.9 - december 2007
- First real steps of the boy! The bot travels on a straight line at any speed, responding to remote commands. Is it possible to control the speed of both wheels obtaining any kind of trajectories.
- As calculated theoretically, the movement is smooth and controlled between 0.025 and 0.5 m/s. Below that minimum the control is noisy with irregular rotation of the wheels, even if the bot still go straight. Above the maximum speed of 0.5 m/s the movement may become uncontrolled since the PID has no more margins of controls to compensate variations of load or power supply.
- The maximum uncontrolled speed, with a full charged battery pack is about 0.6 m/s.
0.8 - november 2007
- Some bugs fixing
- Implemented circular queue for communication procedures to obtain a best separation between second and third communication layer
- Augmented robustness of the communication protocol
0.2 - october 5th 2007
- Second sending to Circuit Cellar Contest Administrator.
0.1 - september 20th 2007
- First project sent to Circuit Cellar Contest Administrator
0.0 - august 7th 2007
- registration of the project to Circuit Cellar Contest with number MT2155
-- - Startup may 2007
===============================================================================
dsODO Version History
1.0 - march 2008
- Updated telemetry with a completely new interface on PC written with Processing.
- The new GUI allows the live modification of all the PID and mechanical constants. Added some new commands parsing from telemetry.
- Added parameters storing on EEPROM.
- Added PID for rotation angle and for distance.
0.9 - december 2007
- First real steps of the boy! The bot travels on a straight line at any speed, responding to remote commands. Is it possible to control the speed of both wheels obtaining any kind of trajectories.
- As calculated theoretically, the movement is smooth and controlled between 0.025 and 0.5 m/s. Below that minimum the control is noisy with irregular rotation of the wheels, even if the bot still go straight. Above the maximum speed of 0.5 m/s the movement may become uncontrolled since the PID has no more margins of controls to compensate variations of load or power supply.
- The maximum uncontrolled speed, with a full charged battery pack is about 0.6 m/s.
- Tested and debugged dead-reckoning procedure including telemetry of position.
0.8 - november 2007
- Some bugs fixing
- Implemented circular queue for communication procedures to obtain a best separation between second and third communication layer
- Augmented robustness of the communication protocol
0.2 - october 2007
- Second sending to Circuit Cellar Contest Administrator.
- Added procedures for Dead Reckoning
0.1 - september 2007
- First project sent to Circuit Cellar Contest Administrator
0.0 - august 7th 2007
- registration of the project to Circuit Cellar Contest with number MT2155
-- - Startup july 2007
=============================================================================