RTD Explorer Feature Requests (Cougar Controller Interface Software)

[adamj12b]

Well, Im not sure this is the right location for this thread, but I wanted to keep it close to Paul's 144V motor controller thread.

My friend and I have been working very hard over the past few months to develop RTD Explorer. For those of you that don't know, RTD Explorer is a GUI based program that runs on Windows to interact with the Cougar based motor controllers. It allows you to see all the data coming from the controller in real time and is displayed on a scrolling graph. There are feature such as a built in terminal for reading and setting parameters along with an interface to the boot-loader to make it easy enough for anybody to use.

Now....The program has had almost all the bugs worked out and alot of people are using it...All Around the World!! BUT, there is a problem, We are quickly running out of ideas. Which is the reason for this thread. Im am asking you guys, "What features would you like to see in RTD Explorer???"

As of right now we are working on integrating a plug-in system that will allow for easy future expansion. The plugins we have planed so far will be as follows:

1. GPS Integration - This will allow for things like range estimations, KW/H used, Efficiency, and some other things along those lines.

2. PakTrackr Integration - This will allow for graphing battery information right along side of the controller information. You will be able to get on screen warnings of battery issues and it will be able to more accurately calculate range and efficiency.

3. Other BMS Integration - We will also be making plugins for other battery management systems, such as Paul's new system that he is working on, The system that Greg is working on or even more!!

So the 2 things I ask from you are: 1. Let us know what you would like to see added and 2. If you have any way you can help out, maybe a small donation (Donations)to help procure some of the hardware needed It would be VERY much appreciated and we will be sure to add your name to the credits list!!

Well I think thats all for now. Let me know what you guys think.

-Adam

[mrbigh]

I'm here, a quick post to be nailed at all the updates.
The first post is over-scanning my 1360x768 screen, so I can't read 1/3 or the text.
I love the idea of the new thread for the RTD explorer,though
An idea or request, if you are going to implement other features to your RTD, I rather have the ability of having a separate screens for different functions and not all of them cluthering the same main screen, or separate, re-sizable, selectable windows to full screen on command for their specified app. sharing data altogether.
Is it clear?

PS
Over-scanning is fixed

[esoneson]

Adam,

I would like to see a way of defining a set of variables that could be used to program the controller's variables in a 'one button' approach.

I.e. User defines a 'button' with the title "Valet Mode" and sets throttle response to a particular low value, sets max amps to a specified low value, and any other appropriate controller variable.

Similarly, a 'button' that would have a title of "Normal" would set the variables to what you think 'Normal' means.

Then a 'button' that could be labeled "Hot Rod".....

Then display these 'buttons' in another window for easy choosing.

This would require the RTD to have some knowledge of limits for each variable in combination with the others for error and warning conditions.

This would basically be a 'one button' setting of the 'general characteristics' of the controller.

Eric

[adamj12b]

Originally Posted by mrbigh

An idea or request, if you are going to implement other features to your RTD, I rather have the ability of having a separate screens for different functions and not all of them cluthering the same main screen, or separate, re-sizable, selectable windows to full screen on command for their specified app. sharing data altogether.
Is it clear?

mrbigh,

We will not be adding any more stuff to the main screen then core program functionality. I am thinking along the lines of tabs that will appear under the File menu bar to allow switching to the new plugins. For example. A default install will just as it does now, but say you want to use the new PakTraker plugin that just came out? When you select to load the plugin, the window with go to a tabbed display. There will now be a tab for the Main Screen with what is there now, but a second tab will be show thats for the PakTrakr. You will be able to click this tab and enter the new display. The same thing will happen with additional plugins, they will show up as aditional tabs.

Do you think this would be an acceptable system?

Originally Posted by esoneson

Adam,

I would like to see a way of defining a set of variables that could be used to program the controller's variables in a 'one button' approach.

I.e. User defines a 'button' with the title "Valet Mode" and sets throttle response to a particular low value, sets max amps to a specified low value, and any other appropriate controller variable.

Similarly, a 'button' that would have a title of "Normal" would set the variables to what you think 'Normal' means.

Then a 'button' that could be labeled "Hot Rod".....

Then display these 'buttons' in another window for easy choosing.

This would require the RTD to have some knowledge of limits for each variable in combination with the others for error and warning conditions.

This would basically be a 'one button' setting of the 'general characteristics' of the controller.

Eric

Eric,

I am currently working on a profile system that will gather the current configuration of the controller and store it in an external file. I would be easy to add "HOT Profile Switching" to this to allow for quick and easy.....switching. LOL

One thing I have been working on with the profile system is the ability to share profiles online so others could try the settings somebody else has programmed. It could be a good way for somebody to get started. Also, It would allow for backup of your configuration in cases of firmware updates that wipe the EEprom or upgrading of microprocessors.



Well thats what I got for now. What do you guys think??

-Adam

[mrbigh]

Tabs for the plug-ins will work also, with out chocking the core app.
I like the idea of selecting diferent controller's setting like "esoeson" mentioned and easy to change over on the road.

[dcb]

I think something that is missing is distance tracking with a vehicle speed sensor. Yes a gps can approximate it, but that is a fair bit of change and isn't always the most reliable. There should really be some onboard sensor so you have accurate and reliable kwh/mile readings. Most vehicles already have a vss, and a fixed gear unit can interpret from rpm.

[roflwaffle]

A *nix version would be nice.

[dcb]

yah, java source would take care of that.

[bobert5064]

Originally Posted by dcb

I think something that is missing is distance tracking with a vehicle speed sensor. Yes a gps can approximate it, but that is a fair bit of change and isn't always the most reliable. There should really be some onboard sensor so you have accurate and reliable kwh/mile readings. Most vehicles already have a vss, and a fixed gear unit can interpret from rpm.

This is a limitation of the controller at this point. There is no mechanism to get approximate speed out of the controller... and without creating our own hardware interface, no way to get that data into the software. Also, you have to keep in mind that the speedometer will only measure the speed the wheels are spinning at (assuming proper calibration) so it is not the most accurate way to find actual speed. In our testing we have found the GPS speed to be quite reliable and it also has the benefit of not needing to be re-calibrated, especially after changing components on the vehicle.

Thanks for the comment!

--Kyle
RTD Explorer Architect

[bobert5064]

Originally Posted by roflwaffle

A *nix version would be nice.

At some point we may port it to Mono, but at this point we have no plans to do that as it seems most people are using Windows.

Originally Posted by dcb

yah, java source would take care of that.

Ya, we could port it to Java, but that would just add a whole mess of headaches that I have no interest in. I am really not a big fan of Java despite it's ability to develop cross platform.

Who knows maybe with HTML5 we will port it to the browser

--Kyle
RTD Explorer Architect