Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   FIRST Tech Challenge (http://www.chiefdelphi.com/forums/forumdisplay.php?f=146)
-   -   [FTC]: Drive Platform- Design Exercise (http://www.chiefdelphi.com/forums/showthread.php?t=137636)

DavisDad 24-10-2015 13:43

Re: [FTC]: Drive Platform- Design Exercise
 
We moved the lower churro stubs up to the 50 deg part. See video below. It gets stuck most of the time with the back wheel locked in and doing a wheelie. A few pounds force on the front enabled it to climb past (not shown).

Prototype Climb Test 2.5

I think the performance warrants going the next step to make the other side rail and test full functionality. This will ensure our holding the cross bar hasn't introduced something to the test that doesn't represent what a 4 wheel platform does.

If we get a positive ruling on using code or clutch to limit torque while on the floor, we'll proceed with the design.

wgardner 24-10-2015 19:18

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad (Post 1501572)
I totally agree, if you analyze the scoring potential, being able to climb the churros is worth a max of 80 (not including chin-up). Blocks in the bins are worth a lot; 300 point by my calculation (10 pieces in 1 low, 1 med, 1 high).

It's possible to do the chinup without driving over churros. About the only thing you sacrifice by not driving over the churros is possibly 40 points in autonomous for getting to the high zone, but you get 10 for getting in the low zone and you get more points anyway by going for the beacon, putting the climbers in the shelter, maybe scoring debris during autonomous (which counts at the end of the driver period, but if you score some in autonomous then you can keep piling it on during driver control), etc.

For teams that can climb the mountain, awesome and kudos! But for teams that can't, there are other ways to score as many points (or more) with different types of scoring mechanism designs. Don't give up!

DavisDad 24-10-2015 20:43

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by wgardner (Post 1501625)
...But for teams that can't [climb mountain], there are other ways to score as many points (or more) with different types of scoring mechanism designs. Don't give up!

Amen brother! Often the simpler, less glamorous strategies win the day.

Ok... time to check our progress against the "User Requirements Specification" written after the game was revealed.

5.1 All materials. Components and controls must be legal per “2015-2016 FIRSTŪ Tech Challenge Game Manual Part I” and “2015-2016 FIRSTŪ Tech Challenge Game Manual Part II”
The prototype failed the first wheel test of "against wall for 15 seconds at full power". Plans are to limit torque to the wheels while on level ground to prevent slipping and abrading the tiles. A question has been posted on the Q&A forum regarding this strategy.
5.2 The control system will be based on the new Modern Robotics Inc. control modules. The legacy module will not be used.
Requirement meet
5.3 The platform must be no larger than, or collapsible to 18 inches square.
Requirement meet
5.4 The motors will be one of the allowed 12VDC gear-motors.
Requirement meet
5.5 The platform, when loaded to a total weight of 35 lb, will be able to climb a 50 degree incline with ladder rung spacing per game manual and field design.
The prototype (1/2 bot) will be loaded and tested at approximately 18 lb
5.6 The platform should have a loaded (35 lb) full speed of 2 ft/sec on the level field.
Requirement meet so far by estimate of speed from motor testing and drive train calculation:
*Motor RPM @ 20% of max power = 175 RPM (see test data)
*Wheel diameter = 8.75"
*Wheel to motor ratio = 0.5 rot/rot

Calculated speed = 0.5 rot/rot x Pi x 8.75 in/rot ft/12 in x 175 rot/min x min/60 sec = 3.34 ft/sec
5.7 The platform should have a pushing force of 20 lb.
To be tested if prototype completed
5.8 The platform should be able perform with the field littered with “debris” game elements and still meet all user requirements.
To be tested if prototype completed
5.9 The platform must be capable of supporting navigation systems for the
autonomous period with driving through the “debris”.
To be tested if prototype completed

wgardner 25-10-2015 08:47

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad (Post 1501541)
I'm concerned that it's going to be difficult to design a wheel or tread that can both climb the mountain, and not damage the floor tiles.

FYI, I've asked a few questions on the official Q&A forum that have gone unanswered for weeks. Maybe they'll answer you and maybe they won't.

My opinion only: there's nothing in the rules to prevent you from doing the things you described (as long as they're not COTS with 2+ DOF, etc). If you don't hear back, I'd suggest that you go forward with your plans. After all, you're following the rules in an attempt to prevent field damage.

Limiting the power so the motor stalls is a little dangerous as it can heat up the motor/ smoke the motor/ prematurely drain the battery/ etc. Finding that power setting may also be tricky as it will depend on robot weight, battery charge level, etc.

Adding a clutch is a good idea if you can pull it off without limiting your power when you need it.

Another option is a software mechanism that detects wheel slippage and kills the power when it is detected until the gamepad controls are released and re-engaged. I think there are threads on this on CD on the FRC side. Then during inspection, your robot drives, detects wheel slippage and then stops the motors so there's no way for it to grind into the field for 15 seconds. This can be demonstrated to the inspector.

Also keep in mind that field damage is going to be dependent on robot weight. I fear many teams may build tread-based robots, test the light drive-train-only chassis and find it to be non-damaging, then add another 20 pounds of scoring mechanisms, and then find at the tournament that their new, heavier robot damages the field.

Good luck!

DavisDad 25-10-2015 09:48

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by wgardner (Post 1501656)
FYI, I've asked a few questions on the official Q&A forum that have gone unanswered for weeks. Maybe they'll answer you and maybe they won't.

My opinion only: there's nothing in the rules to prevent you from doing the things you described (as long as they're not COTS with 2+ DOF, etc). If you don't hear back, I'd suggest that you go forward with your plans. After all, you're following the rules in an attempt to prevent field damage.

Hi wgardner - thanks for the thoughtful feedback; much appreciated! This "design exercise" has been a project my son (FTC alum) and I have been working on for over 2 years. It's not my FTC team's design, so won't be going into competition. My team is leaning toward a tank tread design.

If this project is successful, anyone could use the info to inform their designs. If not, I hope they can learn something from our dead ends. We're posting the work here as an example of applying engineering principles to the design/build process.

Quote:

Limiting the power so the motor stalls is a little dangerous as it can heat up the motor/ smoke the motor/ prematurely drain the battery/ etc. Finding that power setting may also be tricky as it will depend on robot weight, battery charge level, etc.
Roger that- I've tested the Matrix 12V gearmotor direct from battery, stalled for about 3 seconds. But... 15 seconds is scary.

Quote:

Adding a clutch is a good idea if you can pull it off without limiting your power when you need it.
... and complicated. :(

Quote:

Another option is a software mechanism that detects wheel slippage and kills the power when it is detected until the gamepad controls are released and re-engaged. I think there are threads on this on CD on the FRC side. Then during inspection, your robot drives, detects wheel slippage and then stops the motors so there's no way for it to grind into the field for 15 seconds. This can be demonstrated to the inspector.
Great idea about kill and reset from the game pad! If we get that far, we'll try that. I'll look for the posts in the FRC threads.

Quote:

Also keep in mind that field damage is going to be dependent on robot weight. I fear many teams may build tread-based robots, test the light drive-train-only chassis and find it to be non-damaging, then add another 20 pounds of scoring mechanisms, and then find at the tournament that their new, heavier robot damages the field.
We're working on weight testing today. We've added weight to simulate a 35 lb bot (~18 lb for the 1/2 bot) and tested on the test ramp. We're seeing the motors loose power when they get near stall speed; <~ 10 rpm @ motor pulley. We're not getting enough power to climb 50 deg with the added weight. That was with encoder control of speed. We're making another Op Mode to run straight power control while we charge the battery to full.

I've calculated we should get about 350 in-ounces (21 in-lb) torque from the motor; so should be seeing about 9 lb tangential force at each wheel. The dynamics are complicated and 9 lbs probably won't be enough. We can always increase the driven pulley diameter. and design for a super-light build.

Quote:

Good luck!
Thanks!- we're going to need some luck. :)

DavisDad 25-10-2015 11:20

Re: [FTC]: Drive Platform- Design Exercise
 
We added about 7 lbs to prototype and tested (with a fully charged battery) and the prototype had enough power to climb. See link to video below; sorry for wrong orientation.
https://www.youtube.com/watch?v=Kt9V27x_JaA
Butt.. now the modified cogs fold down and loose grip. We're working on a better profile for grinding the cogs that will be stronger in bending:




DavisDad 25-10-2015 19:23

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad on FTC Q&A forum
Hello,

The 10-08-2015 Q&A post (#39) in the "Robot Inspection and Build Rules" thread defines how tires can be tested for passing inspection. We have tested a cogged drive belt idea and the prototype design failed the test requirement: "run the wheels at full power for 15 seconds". The wheels spun and abraded the surface of the tile. See video of test: https://youtu.be/-63vg4V7UfM

Question: May we limit the power of the wheels in programming so that static friction force is not exceeded by the torque from the motor and the wheels do not spin?Is "full power" 100% of motor controller available power, or 100% of game controller command to robot.

a: If there is any possibility that the motor will run at 100% power during either autonomous or tele-operated mode, then the tread must be tested at 100% power. It is a violation of Gracious Professionalism for a team to run the motors at one power during inspection and at a higher power level during a match. Teams that are caught doing this will be disqualified from the event.

I guess they think we work for VW ;)

DavisDad 27-10-2015 05:39

Re: [FTC]: Drive Platform- Design Exercise
 
I've been thinking about the Q&A response about limiting the wheel spin and how we might design/code the bot to ensure that the field is not damaged. In my engineering job, there's a formal method of evaluating how systems can fail: "Failure Modes and Effects Analysis (FMEA)". I'm thinking we analyze, test and documented our work with this engineering tool. A team could present the work to the inspectors.

Here's the next prototype wheel profile we plan to test for gripping the churros:


DavisDad 01-11-2015 10:11

Re: [FTC]: Drive Platform- Design Exercise
 
We got the prototype to climb the 50 deg section: Test-5 YouTube Video

We did the following to modify cogged belt for optimize profile to engage with churros:
  1. Made a grinding wheel with optimized profile. This was interesting as we stacked 4 1/16" grinding wheels and shaped the negative profile with diamond grinding blade.
  2. Made a jig to hold grinder and wheel on mill. This allowed us to index the wheel on every other cog and raise/lower the grinder with pretty accurate x-axis location and good control of the z-axis (up/down) grinding travel.
  3. Ground each profile. Removed every-other cog and small vertical cut on adjacent cogs.
  4. Cleaned each cogged belt to remove gummy residue. Grinding makes a gummy, tarry residue (burned rubber) which needs to be removed from belt. We used mineral spirits and then TSP to remove the mineral spirits.





DavisDad 01-11-2015 10:37

Re: [FTC]: Drive Platform- Design Exercise
 
Review of prototype performance to date:
  • Successful climb of the 30 and 50 deg zones requires very precise design of wheels
  • Center of gravity (COG) will need to be controlled. At 50 deg zone, the COG needs to be at the front axle to have equal force on front and back wheels.
  • The wheels need to be controlled to a slow rotation to keep the wheels' contact with the churros in static friction; too fast causes slip (dynamic friction) and chatter (bounces on the cogs). We had issues with the motor controllers maintaining full power at the slow speeds and high torque; when the battery wasn't fully charged, the back motor would loose torque.
  • This prototype only models half the drive platform and does not account for potential problems with left/right wheels being out of alignment.
  • The cogged belt failed the sSoftTile damage test. It is possible to use current design if we could prove to the inspector we have controls to prevent wheel slippage on level ground. But... this would be difficult to do in software and we couldn't be sure the inspectors would pass the design.

I'm thinking this design is too risky to pursue for FTC 2016. We're going to continue developing the platform as part of this "design exercise", but do not recommend this design for competition build.

Next steps:
  1. Increase gear ratio from 2:1 to 3:1 by using a larger wheel pulley.
  2. Build other half of the drive platform to see how the whole design performs.
  3. With whole platform, test different controls set-ups for tele-op driving and autonomous climbs.

wgardner 01-11-2015 10:57

Re: [FTC]: Drive Platform- Design Exercise
 
I'm looking forward to seeing how it works with both sides built! Thanks for continuing to share!

DavisDad 12-11-2015 18:10

Re: [FTC]: Drive Platform- Design Exercise
 
Modern Robotics is selling a new version of the Matrix 12V motor: 12v 6mm Motor Kit

This fixes the only thing I don't like about the Matrix motor; 4mm shaft requires pretty high precision machining of couplings and we've had issues with the set-screws loosening. 6mm (just under 1/4") shaft has more meat and is now compatible w/ Tetrix and AM gear. Now adapting to 1/8"square shafts will be a lot easier: drill a rod half way 6mm and other half with No. 30 drill size, then broach through No. 30 hole.

I prefer the Matrix planetary gears to the others' spur gear designs.


DavisDad 15-11-2015 12:43

Re: [FTC]: Drive Platform- Design Exercise
 
We've completed the first whole prototype chassis build. We increased the pulley" gear ratios from 2:2 to 3:1. Now ready to mount electronics.


Greg Needel 15-11-2015 16:22

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad (Post 1504840)
Modern Robotics is selling a new version of the Matrix 12V motor: 12v 6mm Motor Kit



Is this a legal motor for use in FTC? It does not seem to be listed in the game manual on the approved motor list.

DavisDad 15-11-2015 17:48

Re: [FTC]: Drive Platform- Design Exercise
 
Probably not legal. Maybe next year...

DavisDad 15-11-2015 17:52

Re: [FTC]: Drive Platform- Design Exercise
 
19 lbs


DavisDad 17-11-2015 18:29

Re: [FTC]: Drive Platform- Design Exercise
 
We won't be able to test on mountain for a while; don't want to distract the team with this "design exercise". Here's a video running it around the house. Need to glue the fan belts on AM wheels; they work their way off when pivoting.

It has better turning than I expected; not much chatter.

https://youtu.be/h68eNyzMy44

RRLedford 20-11-2015 15:37

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad (Post 1505935)
We won't be able to test on mountain for a while; don't want to distract the team with this "design exercise". Here's a video running it around the house. Need to glue the fan belts on AM wheels; they work their way off when pivoting.

It has better turning than I expected; not much chatter.

https://youtu.be/h68eNyzMy44


I highly recommend that you use black Shoe Goo urethane adhesive to glue the treads to the wheels. It has extremely high peel strength, and bonds exceptional well to most materials. We use it in FRC for the attachment of tread to hubs and have now ceased using any rivets at all, since it bonds so aggressively and durably. Multiple years and no failures

Beware though that it is solvent based and needs at a lot of time to dry and cure. I suggest at least 48 hours, or even more if the path for solvent to escape from is long.

DavisDad 21-11-2015 12:35

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by RRLedford (Post 1506761)
I highly recommend that you use black Shoe Goo urethane adhesive ...

Thanks RRLedford- I've ordered some. I haven't used it, but it sounds like just the right stuff. Thanks for the advice!

DavisDad 22-11-2015 09:51

Re: [FTC]: Drive Platform- Design Exercise
 
The next step is to develop a controls design strategy. Since were're only designing the drive platform, with little consideration of other game functions, we're looking at these requirements:
  1. We must address the wheel's damage to the SoftTiles as required by FTC test: "run the wheels at full power for 15 seconds". We'll need to have controls that prevent the wheels from spinning on the tiles.
  2. In order to score the maximum autonomous climbing points, we'll need to navigate accurately to the high zone.
  3. We'll need to be able to drive through debris (balls & blocks) in autonomous while maintaining our course to the high zone.

For effective navigation, we've purchased a sensor that I've been interested in for a while: navX-MXP Robotics Navigation Sensor. This board uses the Invensense MPU-9250. I got interested in this when I saw David Sachs' video: Sensor Fusion on Android Devices: A Revolution in Motion Processing. I'm hoping that with the FTC specific Android software support by Kauai Labs and my son finds the time to help me with JAVA, we can achieve the navigation requirements. The sensor may also be useful for anti-slip control.

I've done the simple programming so far using App Inventor (AI), but will need to use Android Studio with the navX-Micro.

NOTE: I don't think that driving into the high zone is the best approach for the Res-Q game; the most successful teams I've seen (YouTube) are reaching from the low or mid zones and avoiding the difficulties of the high zone. But... my son and I want to bring this prototype design as far as possible to achieve the original design intent.

Gdeaver 22-11-2015 10:34

Re: [FTC]: Drive Platform- Design Exercise
 
We used the NavXMXP For many things on our 2015 FRC robot. This was done before the software and firm ware upgrade. Have been very satisfied with it. It may be a little simpler with the Adafruit Bosch IMU board which also has proven to be good. I think for 2016 we will stay with the naxmxp.

DavisDad 22-11-2015 10:57

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by Gdeaver (Post 1507132)
We used the NavXMXP For many things on our 2015 FRC robot. This was done before the software and firm ware upgrade. Have been very satisfied with it. It may be a little simpler with the Adafruit Bosch IMU board which also has proven to be good. I think for 2016 we will stay with the naxmxp.

Thanks Gdeaver- do you have any advice for me, a complete novice in Android Studio, where to start with:
  • Installation and use of FTC SDK with navX "Software libraries"
  • Any special considerations for programming in Android Studio vs. use of the navX
  • Good tutorials or discussions re IMU use for FTC or FRC

I got Android Studio working with FTC SDK early in the season. I got the ZTEs driving a single motor with the game controller; so I think I have the programming environment set up correctly. I was just blindly following Tom Eng's tutorial. I'm not sure my son (the programmer in the family) will have a lot of time for this. I need to "beg, borrow or steal" enough programming to test navigation and anti-slip functionality.

Any help much appreciated!

DavisDad 22-11-2015 16:19

Re: [FTC]: Drive Platform- Design Exercise
 
We translated the App Inventor teleOp program into an Android Studio (AS) version. My son helped me a bit, although I had to hear what an idiot I am with programming. :)

I followed the tutorials by Swerve Robotics for updating the AS SDK files and programming an Op mode. The prototype is now running as before with AS code.

Thanks Swerve Robotics!!

Now to work on a "dead reckoning" autonomous version, with run-to-position encoder control, and see how repeatable "dumb" navigation is.

OllieK 22-11-2015 18:38

Re: [FTC]: Drive Platform- Design Exercise
 
Craig,

I am in process of creating a tutorial/blog to compare a built-in fusion, such as in Adafruit bno055, with a lower cost simple gyro where the integration/fusion is done in OpMode library.

You can find an example how to create your own I2C device drivers in this blog. This example is for the bno055 IMU..

The source code can be found in Github.

Cheers, Ollie

PS. I have been a long term fan of your mechanical designs and CAD files.

DavisDad 23-11-2015 05:58

Re: [FTC]: Drive Platform- Design Exercise
 
Hi Ollie,

Thank you for the links, and kind words. I'll look forward to reading your comparison. It'll be interesting to know how much the fancy "sensor fusion" devices help with FTC navigation.

Best,

Craig

slibert 24-11-2015 11:54

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad (Post 1507138)
do you have any advice for me, a complete novice in Android Studio, where to start with:
  • Installation and use of FTC SDK with navX "Software libraries"
  • Any special considerations for programming in Android Studio vs. use of the navX
  • Good tutorials or discussions re IMU use for FTC or FRC

Start with these instructions for installing the NavX-Micro FTC libraries into Android Studio. Then review the sample code like rotate to angle. After you install the latest build, all the samples are installed to subdirectories underneath <home_directory>\navx-micro\java\examples (e.g., C:\Users\Robot\navx-micro\java\examples).

There are many helpful items to help your team use and learn more about on the website, start with the links above, and you can ask questions at the support forum.

DavisDad 24-11-2015 20:00

Re: [FTC]: Drive Platform- Design Exercise
 
Hi Scott,

Thank you for the instructions. Using the "Getting Started" guide, I have successfully installed the libraries and configured the "rotate to angle" opMode to compile without error. I'm really looking forward to getting the robot navigating with the navX over Thanksgiving weekend.

Thanks again,

Craig

slibert 24-11-2015 20:03

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad (Post 1507138)
I need to "beg, borrow or steal" enough programming to test navigation and anti-slip functionality.

Any help much appreciated!

Regarding anti-slip, I'd recommend you look into using encoders on each motor shaft and having the motor controller maintain whatever speed (in revolutions per minute) it is commanded to based on input from the encoders. Not only will that provide predictable behavior even as the battery charge level changes, but it's also the general principle behind traction control in cars. We use this technique very effectively on FRC robots, it should work ok for FTC robots too.

DavisDad 26-11-2015 12:09

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by slibert (Post 1507711)
Regarding anti-slip, I'd recommend you look into using encoders on each motor shaft and having the motor controller maintain whatever speed (in revolutions per minute) it is commanded to based on input from the encoders. Not only will that provide predictable behavior even as the battery charge level changes, but it's also the general principle behind traction control in cars. We use this technique very effectively on FRC robots, it should work ok for FTC robots too.

Yes- that's how we're controlling and it's so much better than power control! But... the wheels will still slip at the set speed (RPM). I'm thinking we'll need to determine slip by sensing motion with IMU and stop the wheels from rotating (and/or slow way down) if the bot stops moving when wheels are commanded to rotate.

DavisDad 26-11-2015 12:16

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by slibert (Post 1507610)
Start with these instructions for installing the NavX-Micro FTC libraries into Android Studio. Then review the sample code like rotate to angle....

We got the "rotate to angel" example working this morning. The first time we started the opMode, it work great; would very repeatably rotate to the same angle and return when pushed by hand. I mounted the IMU more solidly and now it's erratic. I need to understand better how the unit works vs. the code, calibration and magnetic interference from the motors.

slibert 26-11-2015 16:46

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by DavisDad (Post 1507957)
We got the "rotate to angel" example working this morning. The first time we started the opMode, it work great; would very repeatably rotate to the same angle and return when pushed by hand. I mounted the IMU more solidly and now it's erratic. I need to understand better how the unit works vs. the code, calibration and magnetic interference from the motors.

My intuition is that the mounting may not be the issue, most likely the "P" coefficient needs to be tuned a bit. A lower battery voltage than last time, or a change in robot weight could account for the change in performance. Do make sure the sensor has completed calibration before using it. For rotate to angle which uses the yaw angle, the magnetometer is not involved, so magnetic interference shouldn't be an issue.

ArtemusMaximus 26-11-2015 18:52

Re: [FTC]: Drive Platform- Design Exercise
 
I wish we'd have opportunity to play with that 9-DOF sensor. Sound like a way to go for Autonomous mode. May be next year.
It would be nice to have color and gyro sensor in KOP.

DavisDad 26-11-2015 22:17

Re: [FTC]: Drive Platform- Design Exercise
 
Quote:

Originally Posted by slibert (Post 1508022)
My intuition is that the mounting may not be the issue, most likely the "P" coefficient needs to be tuned a bit. A lower battery voltage than last time, or a change in robot weight could account for the change in performance. Do make sure the sensor has completed calibration before using it. For rotate to angle which uses the yaw angle, the magnetometer is not involved, so magnetic interference shouldn't be an issue.

Thanks slibert- I think I wasn't waiting for the calibration to complete. I've been trying various PI gains and max speed combinations. I looks like "I" gain, set at 0.0001, winds up and overshoots quite a bit.

I ended up increasing "P" = 0.01, setting the min/max speed at +/- 0.5 and the "Tolerance Deg" = 1. This performed nicely.

Next is run_to_position coding for straight travel segments.

DavisDad 02-01-2016 12:40

Re: [FTC]: Drive Platform- Design Exercise
 
No progress on this as we had to cannibalize the motors from the Big Wheel bot for our team bot. MRI has been out of the Matrix motors for a while...


All times are GMT -5. The time now is 12:26.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi