Society of Robots - Robot Forum

Software => Software => Topic started by: Admin on January 27, 2009, 09:52:38 PM

Title: how to make a GUI for robots?
Post by: Admin on January 27, 2009, 09:52:38 PM
I'm considering making a GUI for my ERP (that uses the Axon). Hyperterminal is getting out of date for me . . .

Basically I want a GUI that displays all the sensor data being sent over by USB. Also the ability to control servos from the GUI.

Something like this:
(http://www.sparkfun.com/commerce/images/products/IMU-Mixer.jpg)

I have no problem doing it from the Axon side, but not quite sure how to do it on the PC side. I guess I should use Visual Basic? Anyone know of source that basically does this already that I can reverse engineer? It just needs to send/receive UART data, and look pretty. :P

Or perhaps anyone willing to write a tutorial? <cough>
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 28, 2009, 12:51:48 AM
Is this something that people usually want? Here's my proposition, I can do this over the weekend (well... I can do the PC part over the weekend, not sure about the MCU part  ;D )
How about a generic application that allows one to select an COM port and takes it's input formating from an tiny script.

Script example:
<code>
Sensor {
  Name="Pitch";
  Type="Linear" min=0 max=255;
  Prefix="01";
}
Sensor {
  Name="Roll";
  Type="Linear" min=0 max=255;
  Prefix="02";
}
</code>

The MCU should send data from the sensors using an simple format. I'm thinking of the configurable text (configured in the script using "Prefix") immediately followed by the result from the sensor. Because it's configurable it would work for anyone's robot and it would not require too much programming experience.

Something similar should be done for the other way around communication (PC to MCU). How does this look?
Title: Re: how to make a GUI for robots?
Post by: Admin on January 28, 2009, 01:21:22 AM
Quote
I can do this over the weekend (well... I can do the PC part over the weekend, not sure about the MCU part)
Do you have an Axon? If so, just upload the axon_DAQ.hex and the MCU part is done. It outputs all 16 ADC as a constant data stream.


Quote
The MCU should send data from the sensors using an simple format. I'm thinking of the configurable text (configured in the script using "Prefix") immediately followed by the result from the sensor. Because it's configurable it would work for anyone's robot and it would not require too much programming experience.
I completely agree. The easier it is for someone else to reconfigure the better.

Also, you wouldn't by any chance know how to create a time graph from data? For example, if I wanted to plot sensor output vs time in realtime, etc.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 28, 2009, 03:17:58 AM
Quote
I can do this over the weekend (well... I can do the PC part over the weekend, not sure about the MCU part)
Do you have an Axon? If so, just upload the axon_DAQ.hex and the MCU part is done. It outputs all 16 ADC as a constant data stream.

Sorry, I don't have an Axon :(
Can you give me a sample dump as received from the Axon running the axon_DAQ program?

Quote
Quote
The MCU should send data from the sensors using an simple format. I'm thinking of the configurable text (configured in the script using "Prefix") immediately followed by the result from the sensor. Because it's configurable it would work for anyone's robot and it would not require too much programming experience.
I completely agree. The easier it is for someone else to reconfigure the better.

Also, you wouldn't by any chance know how to create a time graph from data? For example, if I wanted to plot sensor output vs time in realtime, etc.

I'll do that too.
Title: Re: how to make a GUI for robots?
Post by: Admin on January 28, 2009, 04:18:31 AM
Quote
Can you give me a sample dump as received from the Axon running the axon_DAQ program?
Its really just a data dump if anything. Basically 16 sensors, 8 bit, with a carriage return at the end after each print out data. Here is an example of sensors with static data:

12 44 255 0 87 23 129 221 76 8 187 12 44 255 0 0
12 44 255 0 87 23 129 221 76 8 187 12 44 255 0 0
12 44 255 0 87 23 129 221 76 8 187 12 44 255 0 0
12 44 255 0 87 23 129 221 76 8 187 12 44 255 0 0

Oh, and perhaps take the clock from the PC to add real time? The mcu time is always off by some small % that just keeps building up.

Also, perhaps baud rate detection and/or selection? By default its 115200bps.
Title: Re: how to make a GUI for robots?
Post by: yerbie on January 28, 2009, 07:56:25 AM
hmm, very interesting task.  i'll start working on it and see what i'll come up with :)
Title: Re: how to make a GUI for robots?
Post by: airman00 on January 28, 2009, 08:59:19 AM
I've made GUI programs before for some of my projects. I've used Visual Basic 6 ( classic :P )and had no problems at all doing it.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 28, 2009, 10:01:00 AM
The interesting part is making the GUI easily configurable so that Average Joe can take advantage of it without doing any GUI programming. This brings into discussion all sort of interesting things, like auto-detecting COM port and port configuration.
Title: Re: how to make a GUI for robots?
Post by: Admin on January 28, 2009, 10:48:27 AM
Quote
This brings into discussion all sort of interesting things, like auto-detecting COM port and port configuration.
I think ideally it should be kept really simple for the first version, and worry about feature creep after it works :P

airman00, feel free to share more info about your VB source :P
http://www.societyofrobots.com/member_tutorials/node/170
http://www.instructables.com/files/orig/F01/57FK/FIHVKCYW/F0157FKFIHVKCYW.zip
(http://i273.photobucket.com/albums/jj202/erobot/Chives%20Reloaded/Software/Picture4.png)
Title: Re: how to make a GUI for robots?
Post by: airman00 on January 28, 2009, 11:29:05 AM
airman00, feel free to share more info about your VB source :P
http://www.societyofrobots.com/member_tutorials/node/170
http://www.instructables.com/files/orig/F01/57FK/FIHVKCYW/F0157FKFIHVKCYW.zip
(http://i273.photobucket.com/albums/jj202/erobot/Chives%20Reloaded/Software/Picture4.png)
I don't really consider that too much of a GUI

This program however is a GUI - http://i273.photobucket.com/albums/jj202/erobot/Fx/Picture22-1.png 
Its for one of my projects ( admin I think you know which one )
Graphics were done by my friend Eli - www.photography.narobo.com  . I just did all the coding and stuff like that.

As for source code - the butler robot source code is released online, but I can't reveal any source code for that other GUI program.
Its very easy - just make buttons , labels, pictures, etc. and just update them in your program. Visual Basic is very very easy to learn and extremely useful. I use it to make all kinds of programs ( even the Servo Calculator Program )
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 28, 2009, 02:49:58 PM
I've done an quick test/demo. Unfortunately I can't test it in any kind of realistic conditions: I'm working over Remote Desktop on a remote computer, I don't have serial ports available so I'm using an "Virtual Serial Port" that creates two virtual ports and links them with an virtual "Null Modem Cable". I obviously have no Axon to test with so I simply made an other application that sent data to the other COM port (remember there are two virtual ports linked by an virtual cable).

This "alpha-quality" application can be downloaded here: http://stoiadan.ro/portdump.zip
For those that don't want to test alpha-quality I'm attaching a picture here in the forum.
Title: Re: how to make a GUI for robots?
Post by: Tomas on January 28, 2009, 03:45:26 PM
I know we have a program at our university that is very, very easy to create these GUI for microcontrollers. It reads values straight off the COM port, and it has a neat and easy graphical interface to create sliders, buttons, graphs and such. I'll see if its easily usable with the axon tomorrow, and learn what the name of the app is again. I used it just a little bit last year, so I forgot.
Title: Re: how to make a GUI for robots?
Post by: izua on January 28, 2009, 08:16:18 PM
I think you should create something flexible, so each user can enter the data format.
There won't be major differences between the formats on the long term, mostly everybody outputs the values raw from the memory - but to make it good, the trick will let them be to configure this order, and how to display them.

You could also add 'special' type of variables, for example the pitch-yaw-roll or acceleration could be displayed on an opengl type of thingy, in 3D, or proximity stuff as transparent/less transparent walls around a crude model (box, circle?)
Title: Re: how to make a GUI for robots?
Post by: Admin on January 28, 2009, 08:29:45 PM
cosminprund, it doesn't work. It seems to be connecting to the com port properly though because it gives me an error if I try to use Hyperterminal at the same time. It also detects the com port correctly. But no data gets displayed.

Tomas, probably LabView? Horrible software . . .
Title: Re: how to make a GUI for robots?
Post by: Admin on January 28, 2009, 09:01:39 PM
cosminprund, turns out I'm a moron . . . the DAQ prints out 18 values, where the last two represent the timer. Could that be why it didn't work?
Title: Re: how to make a GUI for robots?
Post by: Admin on January 28, 2009, 09:36:41 PM
I just found this:
http://www.andreavb.com/forum/database/index.php?action=showmod&mod=182

Quote
This program shows how to connect to a GPS receiver (wired or bluetooth via SPP outgoing connection) and decode GSV, GSA and GGA sentences of NMEA protocol, display position coordinates and satellite informations such as signal strength, satellite ID and satellites used for fix

(http://www.andreavb.com/images/screenshots/GPSMonitor.jpg)
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 29, 2009, 12:23:54 AM
cosminprund, turns out I'm a moron . . . the DAQ prints out 18 values, where the last two represent the timer. Could that be why it didn't work?

Yes and now. The program expects 16 values per line. If it doesn't get exactly 16 values per line it doesn't update the progress bars.
On the other hand if you go to the "Bulk data" page where the big black screen is, *any* data received on the serial port should be displayed.
If you don't see anything on the "Bulk data" page then it's bad... I'll need to do some tests with some real serial connection, preferably a MCU connection.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 29, 2009, 12:32:35 AM
I think you should create something flexible, so each user can enter the data format.
There won't be major differences between the formats on the long term, mostly everybody outputs the values raw from the memory - but to make it good, the trick will let them be to configure this order, and how to display them.

You could also add 'special' type of variables, for example the pitch-yaw-roll or acceleration could be displayed on an opengl type of thingy, in 3D, or proximity stuff as transparent/less transparent walls around a crude model (box, circle?)

I've done the thing in a highly flexible way. The 16-value DAQ is not what I want to use so I'll add flexibility. I also want it to work the other way around (send data to the MCU). I don't want to deal with 3D stuff and complex visualizations for now, nor will I bother with very complex input GUI's - I just want the thing to work, be modular. Next I'll add in the ability to create visualizations and input-modules as plugin modules that may be written in any programming language.
Title: Re: how to make a GUI for robots?
Post by: Admin on January 29, 2009, 12:48:42 AM
Quote
If you don't see anything on the "Bulk data" page then it's bad... I'll need to do some tests with some real serial connection, preferably a MCU connection.
Nothing is displayed at all, not even on the Bulk data page . . .


Quote
I've done the thing in a highly flexible way. The 16-value DAQ is not what I want to use so I'll add flexibility. I also want it to work the other way around (send data to the MCU). I don't want to deal with 3D stuff and complex visualizations for now, nor will I bother with very complex input GUI's - I just want the thing to work, be modular. Next I'll add in the ability to create visualizations and input-modules as plugin modules that may be written in any programming language.
As long as the bare basics are there, it's enough for others to reverse engineer and add on to it. Having something to start with definitely helps!
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 29, 2009, 02:01:57 AM
Nothing is displayed at all, not even on the Bulk data page . . .

Ouch, that's bad. I'll give it a shot tonight at home, with a null-modem cable between an "real" COM port and an USB adapter COM port, see what happens. I only tested with an simulated serial cable that provides full handshake and flow control, so there might be an issue with that! Do you know if the Axon provides flow control and handshake?

In the worst cace scenario I'll wait for my Axon (I ordered one last night) so I'd be able to test with the real thing. But with the way Romania's parcel service works it might be a full month before I actually get the Axon! Even if it only takes 10 days for a packet to make it from USA to my home town :(
Title: Re: how to make a GUI for robots?
Post by: Admin on January 29, 2009, 03:31:25 AM
Quote
Do you know if the Axon provides flow control and handshake?
To my knowledge, no. But not entirely sure what the USB drivers do. Trying turning that stuff off, plus account for 18 values instead of 16, and I'll try it again.

I'm currently struggling to install VB. Worst installer ever. It keeps crashing, giving strange errors, horrible download speeds, and forces you to install MySQL Server, all for a mere ~860mb! I'm now waiting for the ~240mb .NET Framework to download. I'm amazed at how an IDE + compiler takes up as much memory as a movie . . . :'(

Quote
But with the way Romania's parcel service works it might be a full month before I actually get the Axon! Even if it only takes 10 days for a packet to make it from USA to my home town
I live in Thailand and I know exactly how you feel. Except here you have to bribe the mailman occasionally or your mail might get 'lost'. And thats assuming a bunch of protesters don't shut down the airport blocking all international mail :P

I saw your order, and it'll go out next week (my next shipping cycle).
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 29, 2009, 04:24:07 AM
To my knowledge, no. But not entirely sure what the USB drivers do. Trying turning that stuff off, plus account for 18 values instead of 16, and I'll try it again.

I'm pretty sure it's a problem with flow control. With my two applications talking to one another over the serial line I never get good speed! But if one end of the connection happens to be an HyperTerminal everything simply flyes! This leads me to believe it's a problem with software flow control, there's something I'm supposed to do and I'm not doing (and HyperTerminal does it).

Quote
I live in Thailand and I know exactly how you feel. Except here you have to bribe the mailman occasionally or your mail might get 'lost'. And thats assuming a bunch of protesters don't shut down the airport blocking all international mail :P

So you called them "protesters"? That's a interesting twist, they're called terrorists here in Romania. Is this Europe's double-standards at work again? I remamber I wanted to travel to Paris last year for a Firebird conference and there were strikes all over the place in France, they basically shut down the whole country! But no one called them terrorists...
Title: Re: how to make a GUI for robots?
Post by: paulstreats on January 29, 2009, 05:46:59 AM
Just adding a bit of input to this....

 I would try and use name - value pairs like cgi scripts do. If the axon could send first a name such as IR then a control charater like | then the value say 6 then another control character | You can then interpret this.
so the axon would be sending a string like this:       IR|6|        (obviously in hex)
If you have a bar graph type gui then each bar can be configured to a name. So have a text box next to each bar If you type IR into the text box then it will look for any data with the value IR then update itself with the data after the control character |
Title: Re: how to make a GUI for robots?
Post by: reSpawn on January 29, 2009, 03:09:29 PM
on what OS it has to work?
Title: Re: how to make a GUI for robots?
Post by: Admin on January 29, 2009, 08:11:01 PM
My understanding is that there is a mod to get VB to work with Java, meaning it can run on Linux. I haven't really looked into it.

But Windows is the priority, as 95% of you guys use Windows ;D
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 30, 2009, 04:13:31 AM
I've got a new version; This time I'm exposing every single configuration option possible, but I haven't managed to test it on my real hardware com port because... well... I forgot to buy the nullmodem cable :(

The ZIP file is here: http://stoiadan.ro/portdump.zip

It now accepts anything from 16 to 18 decimal values per line.

I've also included in the ZIP file my "demogen" application, the one that sends test values to the port (simulates what would come from the "DAQ" program on the Axon) - I made that application to test the first one without actually having an Axon :)

Please someone confirm this is working with an real MCU so I can move on. The next thing on my list is making this configurable so it can be adapted to any kind of MCU output (the 18-values-per-line format is not particularly usefull in an working robot).
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 30, 2009, 06:40:28 AM
Apparently we have a problem with our network connections at the office, the link I posted doesn't seem to work  :-X
Here's an alternate location:

https://activari2.sediu.ro/portdump.zip

(that's a HTTPS link, click on it as-is, don't change it to HTTP!)
Title: Re: how to make a GUI for robots?
Post by: cosminprund on January 30, 2009, 08:47:13 AM
Arghh. The corect second link is:
https://activari2.sediu.ro:442/portdump.zip
Title: Re: how to make a GUI for robots?
Post by: pomprocker on January 30, 2009, 11:13:11 AM
I wish I was better at Java programming :( I got to learn that 'swing' library so I can make Java GUIs
Title: Re: how to make a GUI for robots?
Post by: paulstreats on January 31, 2009, 11:04:33 AM
Quote
I wish I was better at Java programming  I got to learn that 'swing' library so I can make Java GUIs

The gui's arent the problem in java for this issue...

The problem is that Sun removed their comm api for windows and everything else apart from solaris x86 and some high level linux type meaning that there is no support for serial communications.....

(I still have an old version of the comm api and libraries so im gonna see if it works with my xp system, if so i might release a simple terminal program for other people to test on their systems).

Title: Re: how to make a GUI for robots?
Post by: Admin on January 31, 2009, 11:45:56 AM
Quote
The ZIP file is here: http://stoiadan.ro/portdump.zip
Your first link worked but the others didn't.


Anyway, your PortDump.exe program works for several seconds. Then it just stops. It seems pretty random, perhaps it gets out of sync or something?

I also tried running your DemoGen.exe program, but then it locked up my USB port (the connection didn't close properly?).
Title: Re: how to make a GUI for robots?
Post by: reSpawn on January 31, 2009, 03:52:26 PM
tell me the COM number you are using
Title: Re: how to make a GUI for robots?
Post by: Admin on January 31, 2009, 08:21:41 PM
COM2 is the one that locked up.
Title: Re: how to make a GUI for robots?
Post by: reSpawn on February 01, 2009, 05:33:47 AM
cosminprund, turns out I'm a moron . . . the DAQ prints out 18 values, where the last two represent the timer. Could that be why it didn't work?
16 values from 16 sensors, and 2 values from the timer?
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 01, 2009, 07:11:03 AM
Here's an other variant for you to try:
http://stoiadan.ro/portdump.zip

This time I got it to work with actual hardware: An Atmega324, an SparkFun BlueTooth module and a BlueTooth USB dongle. Unfortunately this time I ran into an other brick wall, but this time the problem is the same with my application, HyperTerminal and Putty: I connect at 38400 bps, it works for about 8 seconds and then it stops. When it stops I see the "connect" LED on the SparkFun bluetooth module turns off and the status LED starts blinking - but Windows doesn't seem to think the port is down! I can't reopen the port from an other application (until I close the first) and I get absolutely no errors (COM errors).

I'm pretty sure this is ether the SparkFun module complaining about frame errors, my Edimax BlueTooth dongle OR my AVR software! I'm pretty sure it's not by Delphi software and I hope it's my AVR software because that's easiest to fix.

@reSpawn
Yes, that's the format, 16 values from the sensors plus two values from the timers. The values are in decimal notation, separated by spaces and at the end of the line there's some sort of line terminator. I'm not sure what line terminator because my code accepts (CR or LF) or any combination of those two :D

And an other tip: If you want to do it with direct Windows API calls, as I wanted to do it, ether use Microsoft's compiler or don't use direct API! That's because the smart people at Microsofot used bitfield typedef's in a very important datastructure (DCB) - the problem's that there's no standard for bitfield order/padding! I don't understand why they didn't used the normal OR-ed flags, they just had to push the Microsoft compiler.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 01, 2009, 08:02:34 AM
Quote
I'm pretty sure this is ether the SparkFun module complaining about frame errors, my Edimax BlueTooth dongle OR my AVR software! I'm pretty sure it's not by Delphi software and I hope it's my AVR software because that's easiest to fix.

I narrowed it down. In my initial tests I was pumping data to the serial port in a continuous stream: As soon as the UDREn bit of UCSRnA register was set I was pushing an new char. By introducing a short pause between lines (25 milliseconds works grate at 57.6 k with an 8Mhz clock) I was able to maintain the stream going for as long as I was willing to test!

I assume the SparkFun module was caching chars and it wasn't able to send them as fast as I generated them. I'm not sure those. The sparkfun thingy should have been able to send data at 38k (that's what I initially used) without problems! An other possible explanation might be that the pause in the stream allows the clock-recover thingy in the SparFun's module to recover after the errors that I was generating (with my 8Mhz clock, at 38k I get 0.16% error rate, at 57.6k I get 3.5% error)

With my next order to Farnells I'll get one of those 7-point-something crystals that allow perfect baud rate generation and figure this out.

I still want to know if this works with the Axon DAQ as it is right now, I assume it does. My next mission is to start make this configurable, but that's for the next Weekend!
Title: Re: how to make a GUI for robots?
Post by: reSpawn on February 01, 2009, 08:22:30 AM
I'm not familiar with Windows API, I'm using Qt to make GUI Applications.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 01, 2009, 08:58:01 AM
Quote
I still want to know if this works with the Axon DAQ as it is right now, I assume it does. My next mission is to start make this configurable, but that's for the next Weekend!
Ok good news and bad news. Good news is that it worked, displayed data correctly, etc.

Bad news is when I clicked 'Bulk I/O' and then checked the box. It immediately crashed/blew up the program. Since data is coming in insanely fast anyway, maybe it should be limited to one line per 250ms or something like that?

Do you know how to show the data as a line graph? Perhaps make it look like an oscilloscope (sensor voltage vs time)?
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 01, 2009, 04:21:15 PM
Bad news is when I clicked 'Bulk I/O' and then checked the box. It immediately crashed/blew up the program. Since data is coming in insanely fast anyway, maybe it should be limited to one line per 250ms or something like that?

Well that was expected considering I used a good old ListBox for the Bulk Data display! It was supposed to be an aid with development. I replaced the ListBox with an all-custom control, this one's so efficient it doesn't need a checkbox: It's always ON and doesn't slow down the system.

Quote
Do you know how to show the data as a line graph? Perhaps make it look like an oscilloscope (sensor voltage vs time)?

I've only seen pictures of how "voltage vs time" looks on an oscilloscope but I gave it a try anyway. The newest version does "time series graphs", in real-time. Again, I used an custom control that I made for this purpose: It's efficient, it's fast and it's ugly :) Because of the way I'm drawing graphics, if you hit "disconnect" right after an interesting event shows on screen, all graphics will freeze and you'd be able to move from one to the other.

I'm too tired right now to make a screenshot of how the new graphics look like. The ZIP archive is in the usual place: http://stoiadan.ro/portdump.zip

Give me a sign if this GUI's on the right track.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 01, 2009, 10:19:13 PM
wow I really like it!!! Ok first I want to thank you for all the effort you've donated. You've earned high priority for any questions you ask in the forum (just email me the link and I'll help you asap) :D

As always I have more additions to request:

1) Add an 'About' button somewhere. When the user clicks on it, they see software version number, release date, and author name (your user name or whatever). Any other info that comes to mind.

2) Scaling on the charts. On the left hand side, write 0V to 5V. 0V is at the very bottom, and 5V at the very top. A little dash for every .1V, and a large dash for every .5V (like a ruler almost). If it was labeled, is there a way to automatically modify the horizontal time scale depending on the 'Time interval' selection?

2a) I'm not sure if this will look good, but maybe a underlying grid as in the image below?

3) Add a 'Pause Signal' button for the charts - basically just stop updating the line chart so that the user can have a close look at the signal until he hits 'Resume'.

4) Label it 0 through 15, not 1 through 16 (the ADC on the Axon are 0-15).

5) Add a 'Detect Ports' button so the user doesn't need to plug in the Axon before running your program.

6) A new program name/icon. Like 'Axon Oscilloscope' or something like that. Got an icon with oscilloscope zig-zag lines?

7) After these fixes I'd like to publish your program officially. I'll write up a nice tutorial today and get your approval before release.

(http://www.winsite.com/info/images/35500000036736/Oscilloscope.jpg)


Feature Creep ideas:
Set these to lower priority unless you consider them very easy . . . but I'm dreaming of options such as 'report max value', 'report min value', 'report average value', data smoothing, print waveform (with a printer), save waveform as .png, and even the ability to overlay several channels in different colors on the same chart.

One idea I have is a 'user scaling equation'. So lets say a person has an equation for a Sharp IR that relates voltage to distance, he just types it into a box and the graph modifies itself somehow to display distance and not voltage.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 02, 2009, 03:27:04 AM
1) [...]
2) [...]
2a) [...]

Those are cosmetic changes and can be easily implemented.

Quote
3) Add a 'Pause Signal' button for the charts - basically just stop updating the line chart so that the user can have a close look at the signal until he hits 'Resume'.

That's a nice idea, I've allready figured out a way to easily implement that. I'll also add some kind of scroll bar to move the "window" so I can see older data, maybe even save the data so I can review it later. Since this requires me to implement an pausing mechanism I might as well implement some kind of "auto-pause": If the sensor value gets stuck on "0" or "255" for longer then 1 second enter auto-pause mode and resume recording only when I start getting other values. The way I'll implement this would also allow me to place a nice vertical red line where the pause happend (auto-pause or pause because the user pressed an button) so it's obvious when looking at the graph that there's something missing.

Quote
4) [...]
5) [...]
6) A new program name/icon. Like 'Axon Oscilloscope' or something like that. Got an icon with oscilloscope zig-zag lines?

I'm aiming more towards "SoR Oscilloscope" if you like that. The idea's that I want this to work with anything outthere, not only the Axon.

Quote
Feature Creep ideas:
Set these to lower priority unless you consider them very easy . . . but I'm dreaming of options such as 'report max value', 'report min value', 'report average value', data smoothing, print waveform (with a printer), save waveform as .png, and even the ability to overlay several channels in different colors on the same chart.

I understand "print waveform" and "save waveform as .png" but I'll need more info for those:
"report max/min/average value" - you want those on the graph or in a corner somewhere?
"data smoothing" - What are you thinking of? Want me to get rid of the squware-ish lines? A Wikipedia link for the kind of algorithm you'd like to see implemented would be grate.

Quote
One idea I have is a 'user scaling equation'. So lets say a person has an equation for a Sharp IR that relates voltage to distance, he just types it into a box and the graph modifies itself somehow to display distance and not voltage.

That's interesting. Would you mind showing me some equation variants? What would be the preferred notation?

Here's what I'm thinking of: I want to be able to use this little software for other things too (ex: for robots that actually run around the house) - so the insanely fast "DAQ" with the very strict format is not very usefull. I'd like to add commands for updating an arbitrary number of sensors at one time AND for sending status code and text comments. I imagine a GUI that can be configured to look like a dashboard with a number of different kinds of sensors plus a little text box (similar to how the "bulk data" box works) that displays comments sent from the MCU.

Next level would be communication in the opposite direction: Send commands from the GUI to the MCU/Robot. Things like a "command box" would work. I'd also be able to translate keyboard/mouse/joystick into text that can be sent to the MCU.

Some of those options can be implemented fairly fast, so I'd be able to declare the first version complete and send it out into the world :) But I absolutely want it a bit more configurable before I consider even a first version as complete. I insist on more flexible input: Being able to update just one sensor, maybe two sensors; Being able to send some text to be displayed on the computer screen. I also like the idea of status code that would be translated into actual text on the PC: It saves memory on the MCU because it doesn't need to store the whole text and it makes communication allot easier because it only needs to send an 2-byte code, not the whole
Title: Re: how to make a GUI for robots?
Post by: Admin on February 02, 2009, 06:03:09 AM
Quote
If the sensor value gets stuck on "0" or "255" for longer then 1 second enter auto-pause mode and resume recording only when I start getting other values.
Probably won't work. For some reason some of the ADC ports on the ATmega sometimes won't go lower than 1 or 2, or higher than 253 or 252.

Quote
I'm aiming more towards "SoR Oscilloscope" if you like that. The idea's that I want this to work with anything outthere, not only the Axon.
OK that'll also work

Quote
"report max/min/average value" - you want those on the graph or in a corner somewhere?
On a real oscilloscope these are options you turn on and off. They appear typically as numbers at the bottom or right of the screen, so that when you print/save the image, the values get captured. Something intuitive, just see what you can do . . . start easy for now, we can always upgrade later.

The equation to convert 8 bit numbers to voltage:
8_bit*5/255=voltage

Quote
That's interesting. Would you mind showing me some equation variants? What would be the preferred notation?
For example, the Sharp IR GP2D12 sensor uses this equation with the Axon:
distance in cm = 1384.4*pow(8_bit_value,-.9988)

So the user just puts this equation in: 1384.4*pow(X,-.9988)
where X is the value the Axon returns. If the equation line is blank, no conversion happens.

A certain gyro uses this equation: (15*8_bit_value-180)
so the user just enters (15*X-180) and the oscilloscope immediately starts returning degrees per second as a graph

Quote
so the insanely fast "DAQ" with the very strict format is not very useful
If your graph shows pixels per millisecond, I need to make it much faster to view servo PWM (one pixel per 100us). I'm going to try and speed it up. Or maybe make a second DAQ program that only prints one ADC (since USB is the bottle neck).

Quote
Here's what I'm thinking of: I want to be able to use this little software for other things too (ex: for robots that actually run around the house) - so the insanely fast "DAQ" with the very strict format is not very usefull. I'd like to add commands for updating an arbitrary number of sensors at one time AND for sending status code and text comments. I imagine a GUI that can be configured to look like a dashboard with a number of different kinds of sensors plus a little text box (similar to how the "bulk data" box works) that displays comments sent from the MCU.
Perhaps we should come out with more than one program, one specialized only as an oscilloscope, and another specialized for robot communication? DAQs need to be run ultra fast to work.

For the dashboard idea:
What if the bootloader can be activated by a button in the GUI? It just needs to run this command:
C:\MY_ROB~1\Axon\FBOOT17.EXE -b115200 -c2 -paxon_tst.hex -vaxon_tst.hex
(in the user options, the user can modify this command)

And perhaps text is displayed next to sensor data on the graph, so the user will know what sensor data triggered which action - great for debugging! For example, a photovore decides to turn left, it prints 'Left' right on the graph right when it got sensor data to make that decision.

Quote
so I'd be able to declare the first version complete and send it out into the world
How about this. Implement just the ideas in my previous post, and consider the DAQ done. Also, make it so it detects the carriage return - that way if the $50 Robot sends only 5 sensor values, it will still work in the DAQ.

We publish it, call it finished.

Then we focus entirely on a robot dashboard, not caring about DAQ features. We'd have to implement some type of communication language. I can see major feature creep in this, and many people requiring an endless array of new features. As such I think the DAQ should be a separate program.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 02, 2009, 07:02:58 AM
Quote
so the insanely fast "DAQ" with the very strict format is not very useful
If your graph shows pixels per millisecond, I need to make it much faster to view servo PWM (one pixel per 100us). I'm going to try and speed it up. Or maybe make a second DAQ program that only prints one ADC (since USB is the bottle neck).

The "backend" that stores data to be shown on the graph has a resolution of 1 millisecond. Happily that resolution is configurable via a constant. What should be the resolution for the backend? Help me do some math here, to figure out how much the GUI should expect.

The Atmega640 says:
Up to 76.9 kSPS (Up to 15 kSPS at Maximum Resolution)

Going on the highest number, 76.9 kSPS per second, that requires a serial transfer speed of 692.1 kbits/sec (76.9 * 9) - Is the Axon capable of pumping that much data over the USB line?

Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 02, 2009, 07:05:11 AM
About the math: as an extreme-case scenario, let's assume the Axon is only sampling one analog input pin and it's dumping the result straight into the USART! No conversion, binary data is just fine and makes good use of every single bit :D
Title: Re: how to make a GUI for robots?
Post by: Admin on February 02, 2009, 09:11:08 AM
Quote
The "backend" that stores data to be shown on the graph has a resolution of 1 millisecond. Happily that resolution is configurable via a constant. What should be the resolution for the backend? Help me do some math here, to figure out how much the GUI should expect.

The Atmega640 says:
Up to 76.9 kSPS (Up to 15 kSPS at Maximum Resolution)

Going on the highest number, 76.9 kSPS per second, that requires a serial transfer speed of 692.1 kbits/sec (76.9 * 9) - Is the Axon capable of pumping that much data over the USB line?
The Axon is limited to 115.2kbps, due to crystal frequency and USB limitations. A servo pulse is between 1ms and 2ms long, so you'd need a resolution of 1/10th that to get a decent reading. Hence ~100us. But if that's still not possible, faster is still better.

Quote
About the math: as an extreme-case scenario, let's assume the Axon is only sampling one analog input pin and it's dumping the result straight into the USART! No conversion, binary data is just fine and makes good use of every single bit
Exactly what I was thinking.

I just wrote a new DAQ program for the Axon (see attached). It reads only ADC pin 9, and is at least 16 times faster. It returns only a single 8-bit number, directly followed by a carriage return.

I chose pin 9 because it's the closest to the AVR on the pcb, meaning less potential noise. I also reduced ADC accuracy in code to speed it up. It could actually be more than 100 times faster, but too lazy to calculate clock cycles . . . If its easier for you to just to pin 0, it'll take a second for me to recompile.

I can in theory make it go even faster by sending individual bytes, but I'd have to research some syntax to do it:
Code: [Select]
uart2SendByte(a9);
uart2SendByte(what is a carriage return as a byte?);
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 02, 2009, 03:16:18 PM
Quote
Code: [Select]
uart2SendByte(a9);
uart2SendByte(what is a carriage return as a byte?);

First of all: the carriage return is 13, line feed is 10; But you don't need to send an carriage return, just the single byte from the ADC! By sending the result from the ADC as a byte HyperTerminal support goes down the drain, the carriage returns only halves the sampling rate by sending two bytes where one would suffice.

What's in uart2SendByte()? Is that a buffered function or will it simply put the char in UDR and be done with it?
I can't test and I can't look because, as you might know, I don't have an Axon :D I've got the mail with the tracking number today, but unfortunately the Axon itself wasn't in an attachment :(

Now back to the math. Since the Axon is limited to 115.2kbps, that gives about 115.2/9=12.8 kbytes per second. So the bottleneck is not in the ADC but in the USART, the ADC may stay at maximum resolution, it doesn't make a difference (the datasheet quotes 15 kSPS at maximum resolution). Assuming the code can be written to fully saturate the USART code, we'd be getting 12,800 samples every second. Time resolution would be 0.000078125 seconds, or 0.078125 ms, or 78.125 us! (yep, lower then 100 us so I guess it's worth the trouble!)

As a coding idea for how to saturate the USART, here's what I'd do:
Warning, untested code, copy-paste from working code but in a different order
Code: [Select]
  // Init the UART
  // Init the ADC
  // Start the first ADC conversion
  while (1) {
    // Wait until the USART is ready to receive an other char
    while((UCSR0A & Bit5) == 0);
    // Send the result of the last ADC conversion
    UDR0 = ADCH;
    // Init the next ADC conversion
    ADCSRA |= Bit6;
  }

The idea behind the code: The first time into the loop the USART doesn't block and we've got the result of the first ADC conversion in ADCH. Next we init the next ADC conversion and we loop to the begining of the code. The second time in the loop the USART blocks because it can't send the char that fast, it needs about 78.125 us to finish. The ADC needs less then 78.125 us per conversion so by the time we're cleared by the USART the ADC conversion is done and we have the next result in ADCH. The loop goes on and on, saturating the serial link.

Some more good news: Today I added an "function generator" check box to the top of the page. When checked the program stimulates itself with test data. I also made the program display the rate it's receiving data (in kylo bytes per second). With the "function generator" checked I've clocked about 160 KBytes/sec with the graph refreshing at about 50Hz and more than 500 KByte/sec with no updates to the screen. What I'm saying is that the program can definitely handle the 13 KByte/sec that the Axon might generate!

The bad news: No updates tonight, I've got an bug and I don't want to hunt it down tonight.
Title: Re: how to make a GUI for robots?
Post by: Webbot on February 02, 2009, 09:23:29 PM
Quote
I wish I was better at Java programming  I got to learn that 'swing' library so I can make Java GUIs

The gui's arent the problem in java for this issue...

The problem is that Sun removed their comm api for windows and everything else apart from solaris x86 and some high level linux type meaning that there is no support for serial communications.....

(I still have an old version of the comm api and libraries so im gonna see if it works with my xp system, if so i might release a simple terminal program for other people to test on their systems).



You may be interested in http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter (http://rxtx.qbang.org/wiki/index.php/Writing_%22Hello_World%22_to_a_USB_to_serial_converter)

and http://sourceforge.net/projects/javax-usb (http://sourceforge.net/projects/javax-usb)
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 03, 2009, 02:55:58 PM
Here's a new version of the "portdump" thingy:
http://stoiadan.ro/portdump.zip

What's new:
-----------------
(1) Includes "function generator". Check the "function generator" and data starts pouring into the test application from thin air, allowing one to test without actually connecting to an real serial port.
(2) Shows data rate in kylobytes per second: how much data is pouring into the application from the serial port or the "function generator"
(3) Improved resolution for "time base": there's an nice editor for the time base with about 32 possible settings. The lowest resolution is 5 us/pixel and it grows to about 2.5 seconds/pixel. There's an factor of 1.5 between consecutive settings, so this thing allows one to zoom-in very nicely to any signal.
(4) Includes a way to review recorded data: On the graph screen there are some move forward / move backwards buttons that tell the application what data to show. By default it shows data in "real time". If one touches any of the position buttons the image stops scrolling and one has the possibility to move back and forward over the whole graph. With the support from the "zoom/time base" facility this allows one to analyze any detail at any point in time.
(5) The graph gets horizontal lines for volts (in the background)
(6) The graph gets vertical lines for time in the background. Those lines are linked to the "time base/zoom" feature so they're always meaningful. A little more twiking is required.
Title: Re: how to make a GUI for robots?
Post by: airman00 on February 03, 2009, 07:58:07 PM
Any source code available?
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 04, 2009, 12:20:31 AM
Any source code available?

Yes, why not. The program's in Delphi and I might be able to compile it with Lazarus.
It's not finished just yet so no source code.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 04, 2009, 05:34:37 AM
Quote
(2) Shows data rate in kylobytes per second: how much data is pouring into the application from the serial port or the "function generator"
It was going at about 10.3 kbps with axon_DAQ.hex. I noticed it was taking a running average, so its a bit slow in displaying the correct bit rate. Can you speed that up?


Some minor bugs I've noticed. In the graphed data, on the far left, the curve spasses just before it goes off screen on the left. The green lines also get freaky and jump around at particular Time Base selections. Otherwise all good and I like it :)

And this will probably not be easy so don't worry about it . . . it'd be nice to use the mouse to zoom into a selection on the graph. Either by using the scroll wheel on the mouse, or by drawing a selection box, for zooming in. Yea, feature creep :P
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 04, 2009, 06:15:49 AM
It was going at about 10.3 kbps with axon_DAQ.hex. I noticed it was taking a running average, so its a bit slow in displaying the correct bit rate. Can you speed that up?

I can do lot's of things :)

Quote
Some minor bugs I've noticed. In the graphed data, on the far left, the curve spasses just before it goes off screen on the left.

Dumb question: what' "spasses"? Google doesn't know the word and I'm not an native English speaker. Also I'm not home to ask my wife.

Quote
The green lines also get freaky and jump around at particular Time Base selections.

The green lines get freaky when you're looking at data with too much variance per selected time unit. The program needs to apply an aggregation algorithm to come up with a value for the graph, for every pixel. Each pixel shows the agregated value as seen throw a window into the recorded data, the windows is of fixed width: the "time base" width, and the windows are right-aligned to the data, not left-aligned; Since new data is always pouring in the contents seen throw this window constantly changes! This is why I'm saying you're looking at data with too much variance for the selected time base: Select a 2-second time base basically *any* signal has too much variance... unless you're logging temperature change in the room, and then then 2s time base makes a lot of sense!

This could be fixed by only updating the graphic once-per-time-base: If you're looking at an graph that has a timebase of two seconds it makes little sense updating it 50 times per second as it happens right now :) In my opinion this fix is not worth the trouble.

Quote
And this will probably not be easy so don't worry about it . . . it'd be nice to use the mouse to zoom into a selection on the graph. Either by using the scroll wheel on the mouse, or by drawing a selection box, for zooming in. Yea, feature creep :P

Zooming with the mouse wheel is easy; Panning with the mouse wheel is easy (fits right into the "paradigm" of what I've got right now). Selecting a part of the graphic and zooming is not that easy because it requires changes to both horizontal (time line) and vertical (volts/whatever). I'll look into it.

Here's my to-do list:

*) Make an File menu with "Save data" and "Load data" options; This would help with development.
*) Implement an expression evaluator so I can "translate" graph data
*) Implement auto-scale in the graph window as well as configurable scale
*) Make it so I can show more then one graph in the same window
*) Implement pauses and auto-pauses;

P.S: You've got an "private message" from me, I'm waiting for some comments.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 04, 2009, 06:27:44 AM
Quote
Dumb question: what' "spasses"? Google doesn't know the word and I'm not an native English speaker.
Its some 90's term that comes from spasm. So if it spasms, it 'spasses out' or just 'spasses'. Spasm basically means to shake, freak out, go into convulsion, etc. The line basically jumps around like crazy and doesn't hold its shape as it exits the screen on the left.

Quote
This could be fixed by only updating the graphic once-per-time-base: If you're looking at an graph that has a timebase of two seconds it makes little sense updating it 50 times per second as it happens right now Smiley In my opinion this fix is not worth the trouble.
ok then lets not bother with it for now.

Quote
Here's my to-do list:

*) Make an File menu with "Save data" and "Load data" options; This would help with development.
*) Implement an expression evaluator so I can "translate" graph data
*) Implement auto-scale in the graph window as well as configurable scale
*) Make it so I can show more then one graph in the same window
*) Implement pauses and auto-pauses;
Lets leave all these for v2. I like/want these features, but they all fall into feature creep. Just clean out the bugs and tweak what we have and call it v1.

I sent you an email :P
Title: Re: how to make a GUI for robots?
Post by: Admin on February 04, 2009, 06:56:59 AM
Would you by any chance find a large data file of Axon sensor data useful?

I can save it in any file format you want.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 04, 2009, 07:24:59 AM
Quote
*) Make an File menu with "Save data" and "Load data" options; This would help with development.

That's what I was thinking of :D
Yes, give me a large dump, whatever format you have it it's fine: I'll just open the file and send it to my GUI one byte at a time.
Or just wait for tomorrow's version, it will have the save/load options.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 04, 2009, 07:51:25 AM
You just quoted yourself instead of my question :P

Anyway, here is like 15 seconds worth of me tapping the ADC with my fingers. Let me know if you want something larger.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 04, 2009, 08:30:22 AM
It was a remainder. I had save/load stuff as the first item on my to-do list.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 04, 2009, 08:58:25 AM
Another thought came to mind . . . what about 8 bit vs 10 bit . . . the Axon can do 10 bit ADC, so we should give the SoR Scope that option.

I wrote up a *rough* draft tutorial for it:
http://www.societyofrobots.com/sor_scope.shtml

Oh and I decided to call it SoR Scope cause it's catchy, short, and it looks good as a picture. But if you got a better idea I'm still open.

(http://www.societyofrobots.com/images2/sor_scope.png)
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 04, 2009, 12:17:17 PM
Got a new version. Here's the download link:
http://stoiadan.ro/sor_oscilloscope_setup.exe

New in this version:
*) Improved graphics in the "scope" window. I find the colors more pleasant and easier to read.
*) File -> Save option, allows one to save all recorded sensor data
*) File -> Load option, allows loading the previously saved sensor data
*) File -> Playback dump file, asks for a file and plays it back byte-by-byte, pausing at every CR/LF (so it doesn't playback the whole file in 1ms :) )
*) On the "scope" window there's an "Snapshot" button that takes a snapshot of what's on the scope and puts it in the clipboard.
*) The program accepts from 1 to 18 values on it's input, in decimal format, separated by spaces and with an CR or LF char at the end of line.
*) Fixed some bug in the "scope" window causing the graphic to "'spass out" on the first value :)

Here's a screen shot of what the application looks like right now:

Title: Re: how to make a GUI for robots?
Post by: Admin on February 06, 2009, 03:27:58 AM
Hey I was looking into the kilobytes per second thing.

Turns out with oscilloscopes you are supposed to use ksps, or kilosamples per second.

So basically count the number of datapoints collected per second and display that instead.



And I was thinking. Can you make a button that automatically runs the bootloader exe? That way with a single click someone can automatically bootload up a DAQ .hex seamlessly. Sound yummy? :P
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 06, 2009, 04:19:47 AM
Hey I was looking into the kilobytes per second thing.
Turns out with oscilloscopes you are supposed to use ksps, or kilosamples per second.
So basically count the number of datapoints collected per second and display that instead.

I haven't managed to buy my oscilloscope yet, but I'm pretty sure they're measured in MEGAsamples per seconds or GIGAsamples per seconds :) Even the USB ones are rated in the 10's of MEGA samples per second. On the other hand I just ran a google search for "ksps", looking for some values, and I found a commercial device that does DAQ logging, 10 bit, a single channel, and advertises an huge 1500 samples per second :)) - asks $170 for that. Axon + this application does WAY better for less!

Quote
And I was thinking. Can you make a button that automatically runs the bootloader exe? That way with a single click someone can automatically bootload up a DAQ .hex seamlessly. Sound yummy? :P

Yeh, that would be very easy to do. Preferably after I get my Axon so I can test stuff myself.

But I've got a few more ideas that would make our toy oscilloscope actually quite usefull in the realm of hobby robotics: A 1-bit (yep, 1 bit) "DAC" usefull for sampling servo signals: The "DAC" would be retrograded to just "D", we'd read an digital input 8 times, make an byte and send that over the serial line. This would give 80 kilosamples per second for a resolution of 12 us - enough to properly "see" the servo signal. The primary reason I wanted to buy an oscilloscope was to be able to see servo signals.

An other option would be an smart Axon application that not only sends data but also receives commands from the GUI. It would default to sending nothing and we could have a command in the GUI to select the kind of output we want from the Axon: 10bit / 8bit / 4bit / 1bit, including selection of channels. So the user might select 4 bit output from channel ADC3; The Axon would start sampling ADC3, putting together the upper 4 bits of two samples and send that over as an 8 bit byte :) A nice way to speed things up while still providing an fair amount of information.



Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 06, 2009, 04:57:25 AM
Here's a dumb question: What's keeping you from setting up the Axon at 1,000,000 baud? Or at 500,000 baud? 256,000 baud? All those settings would give 0% baud error and are supported by the CP2102. They're not standard baud rates but then again on the PC side the port is virtual, the speed setting is just a convention - doesn't really matter :D I'm pretty sure it only matters on the UART side!
Title: Re: how to make a GUI for robots?
Post by: Admin on February 06, 2009, 05:54:39 AM
Quote
Here's a dumb question: What's keeping you from setting up the Axon at 1,000,000 baud? Or at 500,000 baud? 256,000 baud? All those settings would give 0% baud error and are supported by the CP2102.
Thats a good question.

The ATmega640 datasheet says .5M and 1M, while the CP2102 datasheet, your software, and hyperterminal say 460800 and 921600. So I just went with 115200 to avoid any confusion - it was fast enough for the time anyway. Perhaps the ATmega datasheet was just rounding off?

But now looking into it, Device Manager won't let me go above 128000.

Just for the heck of it I tried to do it at 460800, and 921600, but whether I have the Axon turned on or not, your software gives an 'Unknown baud-rate.' error.

Quote
But I've got a few more ideas that would make our toy oscilloscope actually quite usefull in the realm of hobby robotics: A 1-bit (yep, 1 bit) "DAC" usefull for sampling servo signals: The "DAC" would be retrograded to just "D", we'd read an digital input 8 times, make an byte and send that over the serial line. This would give 80 kilosamples per second for a resolution of 12 us - enough to properly "see" the servo signal. The primary reason I wanted to buy an oscilloscope was to be able to see servo signals.

An other option would be an smart Axon application that not only sends data but also receives commands from the GUI. It would default to sending nothing and we could have a command in the GUI to select the kind of output we want from the Axon: 10bit / 8bit / 4bit / 1bit, including selection of channels. So the user might select 4 bit output from channel ADC3; The Axon would start sampling ADC3, putting together the upper 4 bits of two samples and send that over as an 8 bit byte Smiley A nice way to speed things up while still providing an fair amount of information.
excellent idea!
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 06, 2009, 06:21:13 AM
Quote
Here's a dumb question: What's keeping you from setting up the Axon at 1,000,000 baud? Or at 500,000 baud? 256,000 baud? All those settings would give 0% baud error and are supported by the CP2102.
Thats a good question.

The ATmega640 datasheet says .5M and 1M, while the CP2102 datasheet, your software, and hyperterminal say 460800 and 921600. So I just went with 115200 to avoid any confusion - it was fast enough for the time anyway. Perhaps the ATmega datasheet was just rounding off?

But now looking into it, Device Manager won't let me go above 128000.

Just for the heck of it I tried to do it at 460800, and 921600, but whether I have the Axon turned on or not, your software gives an 'Unknown baud-rate.' error.

The CP2102 datasheet says it's getting it's baud rate from the PC side of things so the PC side configuration does matter after all. With the Bluetooth thingy I'm using I can set the baud rate from hyper-terminal and, because it's an virtual port it doesn't matter what speed I'm specifying when I'm connecting (PC-side).

When I get home from work I'll take a look into my application and try to make .256, .5 and 1 Mbit speeds available. When configuring the serial port one has to set up a datastructure that specifies the baud rate; *everyone* uses the predefined Windows constants for setting up those speeds - if Microsoft didn't list the .5 and 1 Mbit constants in the header files there's a good chance no one set them up in configuration programs. But just because a given constant doesn't exist it doesn't mean the value isn't valid! As I said, I'll make the value available so you can give it a try. When I wrote the list of available boud rates I actually copied the list of available boud rates as shown by HyperTerminal :D

P.S: I just took a look on MSDN at the given datastructure! There *is* a constat for 256,000 boud - but it's also the constant for the greatest boud rate defined! The 256,000 boud rate is not offered by most things (including my application) even those it's defined by Microsoft, yet other boud rate are offered even those they're NOT defined by Microsoft. This makes me think all 3 of .256, .5 and 1 Mbit are available and should work!
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 06, 2009, 01:32:06 PM
Two things for tonight: I modified the "SoR Scope" to allow unusual boud rates: 250,000 (yep, 250,000, not 256k!), 500,000 and 1,000,000; The thing with those boud rates is that they can be reproduced exactly on 4/8/16 Mhz MCU! The other thing is that I've actually tested those boud rates on my MCU, and that's an Atmega324P running at 8Mhz. I was able to use 500,000 boud rate - with the boud rate prescaler (UBRR) = 0 and it worked!

The conclusions for tonight is that the Axon might actually go as high as 1Mboud per second! My Roving Networks RN-41 can't handle the 500,000 boud rate (it works but I'm seeing erroneous chars at times) - I'm pretty sure that's the Bluetooth thing to blame, the USB should handle that! I can't test :(

Tonight's installer is at the usual location. Hopefully over the weekend I'd be able to implement the expression evaluator so the graphic can graph centimeters inches and other things besides volts.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 07, 2009, 02:12:41 AM
It worked up to 500k baud.  :)
If I did 1M baud the data came in all corrupted . . .


Also, it just occurred to me that with a simple jumper wire from a hardware PWM pin to the ADC that you can measure the PWM for debugging! What microcontroller do you know of that can graphically measure its own PWM? :P
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 10, 2009, 01:40:53 AM
Over the previous weekend I managed to implement the expression evaluator but I haven't fully linked it to the graphics yet, I need to solve a few more problems. For now the expression evaluator only works on a "debug" page where you write a expression and you get to see the result in some other box :)

Anyway, now I'm facing a few problems: How do you people think I should be scaling the graphic? Right now the "Y" scale is from 0 to 5V and it's fixed, but that doesn't work for graphics that have a expression: I might have a range of 5 to 250 cm! I thought of scaling the graphic according to the absolute minimum and absolute maximum value as seen by the given sensor (ie: min and max over the entire range of recorded data). The downside of this would be that a "glitch" in the sensor would mess with the scale (imagine an IR sensor giving an 1 us 5V sample - being transformed to a 250 cm distance, where all other readings are between 5 and 10 cm - it makes the screen difficult to read). Letting the user manually change the scale would work but would be tough on the user.

Right now I'm leaning towards an automatic scaling system that would work like this:
- Start with a scale that correctly displays whatever's on screen NOW
- While the data on screen changes increase the scale if required (ie: if the data no longer fits the scale, make the scale larger); Never automatically decrease scale!
- Give the user an single button to "fit scale to data" - when the user presses this button the scale goes back to something that perfectly fits whatever data I'm seeing right now.

An other problem I'm facing: What math functions should be implemented in the expression evaluator? I was thinking of getting the list of Math functions listed by Excel under the "math" section and implement as many of them as possible; But hopefully I'd get away with less...
Title: Re: how to make a GUI for robots?
Post by: Admin on February 10, 2009, 02:25:40 AM
I think auto-scaling is really useful, I use it on oscilloscopes all the time. A radio button could be used to let the user define which type of auto-scaling is best for him.

That being said, manual scaling should also be an option - letting the user define the min and max value. The problem with auto-scaling is that when there isn't a signal it focuses on signal noise instead.

Just be careful to not over complicate the GUI.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 10, 2009, 02:36:30 AM
The GUI is allready getting bloated (in my opinion) and it's not even version 1 :(
I might resort to some ribbon-like toolbar (but not THE ribbon because that requires a licence) - just an simple paged control that groups different commands on different pages.

Quote
A radio button could be used to let the user define which type of auto-scaling is best for him.

What would be the options here?

P.S: My Axon is in Sibiu, my home town. I'll get it tomorow. It got here unusually fast!
Title: Re: how to make a GUI for robots?
Post by: Admin on February 10, 2009, 03:40:39 AM
Perhaps put the auto-scale and manual scale stop in the drop down menu, as options or something like that?

It basically qualifies as advanced stuff, so it doesn't need to be that obvious to an ultra beginner.

Quote
What would be the options here?
perhaps it should be in the same window as manual scale . . . such as:

define min value options: scale, fixed value
define max value options: scale, fixed value

autoscale options: throughout session, just immediate window
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 10, 2009, 03:16:00 PM
Progress has been slow lately, but here's an new installer at http://stoiadan.ro/sor_oscilloscope_setup.exe

Here's the news. I've got the expression evaluator working. There's a lot more work to do but it's working and it can be tested. The expression evaluator is a 100% custom job, designed from the ground up to work for the SoR Scope project. The syntax will allow for some very nice "if" statements, as well as some "case" statements - because I absolutely hate Excel's way of doing "if" :) The "runtime" bit is very fast: Expressions are first "compiled" to something that's very close to native code (give or take some virtual method calls :D ) and this makes it efficient. It also has a method of detecting math errors that will allow me to represent them on the graph with a red vertical bar (or some other way). Error processing would be done without stopping the graphing process.

To test just go to the page with the graph and enter the expression in the top box; "V" (from Value) is the "Y" before applying the expression. Don't ask me why I didn't call it "Y"... Just make sure you enter a fairly logical expression: If the expression generates runtime errors they'll slow things down enough to make the program almost freeze. This will probably be fixed. If you want to try this don't try it with simple stuff like "V/0", try it with stuff like "Power(V-128,-2)" - that would raise a library error as an exception that's why it's slow.

Here's the list of functions currently available in the script:
Ignore the function prefix and hope you'll figure out the Pascal syntax. The names should be self-explanatory. If they're not... I'm not sure I understand them all :D I just made all the functions in my Math library available to the scripting engine :D

Code: [Select]
function D1_ArcCos(const X : Double) : Double;
function D1_ArcSin(const X : Double) : Double;
function D1_Tan(const X: Double): Double;
function D1_Cotan(const X: Double): Double;
function D1_Secant(const X: Double): Double;
function D1_Cosecant(const X: Double): Double;
function D1_RadToDeg(const Radians: Double): Double;
function D1_RadToGrad(const Radians: Double): Double;
function D1_RadToCycle(const Radians: Double): Double;
function D1_DegToRad(const Degrees: Double): Double;
function D1_DegToGrad(const Degrees: Double): Double;
function D1_DegToCycle(const Degrees: Double): Double;
function D1_GradToRad(const Grads: Double): Double;
function D1_GradToDeg(const Grads: Double): Double;
function D1_GradToCycle(const Grads: Double): Double;
function D1_CycleToRad(const Cycles: Double): Double;
function D1_CycleToDeg(const Cycles: Double): Double;
function D1_CycleToGrad(const Cycles: Double): Double;
function D1_Cot(const X: Double): Double;
function D1_Sec(const X: Double): Double;
function D1_Csc(const X: Double): Double;
function D1_Cosh(const X: Double): Double;
function D1_Sinh(const X: Double): Double;
function D1_Tanh(const X: Double): Double;
function D1_CotH(const X: Double): Double;
function D1_SecH(const X: Double): Double;
function D1_CscH(const X: Double): Double;
function D1_ArcCot(const X: Double): Double;
function D1_ArcSec(const X: Double): Double;
function D1_ArcCsc(const X: Double): Double;
function D1_ArcCosh(const X: Double): Double;
function D1_ArcSinh(const X: Double): Double;
function D1_ArcTanh(const X: Double): Double;
function D1_ArcCotH(const X: Double): Double;
function D1_ArcSecH(const X: Double): Double;
function D1_ArcCscH(const X: Double): Double;
function D1_Log10(const X: Double): Double;
function D1_Log2(const X: Double): Double;
function D1_Sign(const AValue: Double): TValueSign;

function D2_ArcTan2(const Y, X: Double): Double;
function D2_Hypot(const X, Y: Double): Double;
function D2_LogN(const Base, X: Double): Double;
function D2_Power(const Base, Exponent: Double): Double;
function D2_RoundTo(const AValue, ADigit: Double): Double;

Admin, you gave me those two expressions as sample expressions:

Code: [Select]
1384.4*pow(X,-.9988)
(15*8_bit_value-180)

You'd write them as:

Code: [Select]
1384.4*power(V,-.9988)
15*V-180

The scripting engine also has access to every single "sensor" values throw the use of variables S1 to S99; Yep, I've increased the numbers of sensor to 99; By default only the first 16 get nice graphics but you can go to the expression variable and type "S75" and you'd get a graph of the 75'th value that was sent to the GUI over COM.

The nice thing is that you can graph the difference between recorded values. Example: S1-S2; Of course, you can also do: "S1-Power(S2,S3)*S4-S5"... show me an real scope that can do that :)

An other way to test the expression evaluator is to go to the "SoR Script" page and type an expression into the left side; The expression would be instantly evaluated and the result would be written to the right side. Try something like "Power(2,3)"

The other news is that the auto-scale function works, but it's not configurable.
Title: Re: how to make a GUI for robots?
Post by: Jdog on February 10, 2009, 05:21:17 PM
Is there a way I can communicate to the scope through printf in other programs besides the DAQs.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 11, 2009, 12:16:39 AM
Yes there is: Just send whatever value you want to send in decimal notation (ie: human-readable, not hex or other encoding) followed by end line. The SoR Scope will accept from 1 to 99 values on the same line, and you'll get graphics for the first 16 values.
Title: Re: how to make a GUI for robots?
Post by: Jdog on February 11, 2009, 12:02:48 PM
Would something like this work?
Code: [Select]
rprintf("%d, %d%d, %d%d, %d%d",sharp_ir, scan_angle, wheel_left, wheel_right);
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 12, 2009, 12:26:37 AM
The values are supposed to be separated by space, no commas; Also you've doubled the "%d"'s for some reason, I assume that was just a typo. I'm not sure if the "rprintf" functions prints an newline char after the text, most likely not. Try one of this two, one will work:

Code: [Select]
rprintf("%d %d %d %d\n",sharp_ir, scan_angle, wheel_left, wheel_right);

or

Code: [Select]
rprintf("%d %d %d %d",sharp_ir, scan_angle, wheel_left, wheel_right);
Title: Re: how to make a GUI for robots?
Post by: Admin on February 12, 2009, 12:51:28 AM
I think he doubled the %d because he is doing long ints.

Jdog, are you just trying to graph the values you send to a servo? I think this would be better:

Code: [Select]
int angle_left;
angle_left=convert_to_angle(wheel_left);

rprintf("%d %d %d %d\n",sharp_ir, scan_angle, angle_left, wheel_right);

you get the idea . . .
Title: Re: how to make a GUI for robots?
Post by: Jdog on February 12, 2009, 08:12:14 AM
Thanks, I got it now. Although I don't see why you converted wheel_left to angle_left.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 12, 2009, 10:51:13 AM
Thanks, I got it now. Although I don't see why you converted wheel_left to angle_left.
wheel_left is a long int value, such as 637.

angle_left is an int, some value below 255.

To my knowledge, for now, the SoR Scope can only take in int values.
Title: Re: how to make a GUI for robots?
Post by: Jdog on February 12, 2009, 10:53:23 AM
Then why didn't you convert wheel_right to an int as well?
Title: Re: how to make a GUI for robots?
Post by: Admin on February 12, 2009, 11:03:55 AM
Then why didn't you convert wheel_right to an int as well?
too lazy :P
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 12, 2009, 11:09:01 AM
The SoR scope accepts unsigned integer numbers, that is 0 to whatever.
Internally it stores the values as double precision floating numbers, so I should update the parser to allow negative numbers and to handle floating points (the "." thingy). Maybe I'll make the time tonight. I'm really curios how fast the Axon's DAQ is: I haven't had the time to take it out of it's envelope  ::)
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 12, 2009, 01:37:23 PM
I updated the parser; It now accepts any numbers, positive or negative, integer or floating point.
Title: Re: how to make a GUI for robots?
Post by: Admin on February 12, 2009, 08:37:43 PM
Quote
I'm really curios how fast the Axon's DAQ is: I haven't had the time to take it out of it's envelope

Oh I forgot . . . I attempted to get it to read it's own PWM using the original DAQ program . . . waaaay to slow, see image.

But I can probably get it to work if I wrote the DAQ carefully enough, just haven't gotten around to it yet.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 12, 2009, 11:53:49 PM
I'll be working on an axon_scope.hex :D this weekend; Last night I did manage to take the Axon out of it's envelope and I did some experiments; Sending out constant data to the USB port (ie: rprinf("1 2 3\n");) I got precisely 53.4 kilobytes per second (as shown by the SoR Scope). Next I modified the super-simple loop to read a value from the ADC and then rprint-it to the USART - data rate dropped to just 17 kilobytes - and those kilobytes aren't kilo samples because the data is sent in decimal notation and there's an line terminator in there (probably 4 bytes per sample average).

What I'll attempt to do over the following weekend is to make the axon application talk to the PC application (as in bidirectional talk, not just send data), and make the sampling/sending configurable (10/8/4/1 bit per sensor, configurable number of sensors). I'll also attempt making the USART send overlap the ADC sample, to keep the USART saturated most of the time.

Theoretically the 53.4 kilobytes per second should directly translate to 53.4 kilo samples per second, one sensor, 8 bit precision: that gives 18us time base, enough to see the PWM signal!
Title: Re: how to make a GUI for robots?
Post by: Admin on February 13, 2009, 12:22:34 AM
Quote
Sending out constant data to the USB port (ie: rprinf("1 2 3\n")Wink I got precisely 53.4 kilobytes per second (as shown by the SoR Scope). Next I modified the super-simple loop to read a value from the ADC and then rprint-it to the USART - data rate dropped to just 17 kilobytes
wow I didn't realize the ADC affected the transmission that much . . .

Another solution - don't use the ADC for reading PWM, use a digital pin instead.
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 13, 2009, 12:48:28 AM
Quote
Another solution - don't use the ADC for reading PWM, use a digital pin instead.

That's what "1 bit" mode will do: sample a single digital pin 8 times, make a byte and send that over; Timing would be crucial, ideally the time between the 8 samples should be just right so the 8 bits are produced in the amount of time it takes the USART to send the previous byte. That way we'd get an maximum of 424 kilo samples per second! And that's one thing I'm 100% sure of: I can get 424 kilo samples out of an digital pin because there's no ADC to slow things down.

Do you, by any chance, know how I can make the ADC faster if I only want 8 bit or 4 bit precision? (I'm lazy, I'm sure it's in the datasheet!). Is there a configuration option for this or do I simply read ADCH when I feel it's time to read it? Do I tweak the ADC clock?
Title: Re: how to make a GUI for robots?
Post by: Admin on February 13, 2009, 01:08:32 AM
Quote
Do you, by any chance, know how I can make the ADC faster if I only want 8 bit or 4 bit precision? (I'm lazy, I'm sure it's in the datasheet!). Is there a configuration option for this or do I simply read ADCH when I feel it's time to read it? Do I tweak the ADC clock?

This is what I did. Basically the scaling defines how many clock cycles are used to get an ADC reading. However fewer cycles you use, the more inaccurate it gets (because its charging up internal capacitors). The original DAQ uses DIV32, but the faster version uses DIV4.

Code: [Select]
void axon_DAQ_fast(void)
{
int a9;

//select speed/accuracy of data conversion
a2dSetPrescaler(ADC_PRESCALE_DIV4); // configure ADC scaling

while(1)
{
//gather data
a9=a2dConvert8bit(9);

//report data, add time stamp and overflow count at end of data
rprintf("%d\r\n",a9);
//uart2SendByte(m2);//even faster, but doesn't have carriage return
}
}

And some notes from AVRlib:
Quote
   //select speed/accuracy of data conversion
   a2dSetPrescaler(ADC_PRESCALE_DIV32); // configure ADC scaling, 32 default

   // A2D clock prescaler select
   //      *selects how much the CPU clock frequency is divided
   //      to create the A2D clock frequency
   //      *lower division ratios make conversion go faster
   //      *higher division ratios make conversions more accurate
   // ADC_PRESCALE_DIV2       -> CPU clk/2
   // ADC_PRESCALE_DIV4        -> CPU clk/4
   // ADC_PRESCALE_DIV8        -> CPU clk/8
   // ADC_PRESCALE_DIV16      -> CPU clk/16
   // ADC_PRESCALE_DIV32      -> CPU clk/32
   // ADC_PRESCALE_DIV64      -> CPU clk/64
   // ADC_PRESCALE_DIV128      -> CPU clk/128
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 15, 2009, 04:59:24 AM
Here's a new version of SoR Scope. New stuff:
(1) Made it use the "performance counter" for a time base. The performance counter is directly related to the PC's CPU speed, very accurate, but may give strange result on SMP processors and on computers with ACPI that happen to change CPU frequency to save power.
(2) Made it accept two more encodings for the input stream: "binary-8bit" and "binary-4bit". There's an radio button for "binary-2bit" but it doesn't work right now.

Using the "binary-4bit" encoding, an Axon, a Atmega324 board and an two wire jumper cable that links the ground on the two boards and moves the servo signal output from the Atmega324 to an analog input on the Axon. I got the image in the attachment. The servo signal can be seen fairly well, but I'm afraid I can't do better without buying an actual oscilloscope to test that data! In the picture the graphed time base is 1/100 seconds, so the thick numbered vertical lines are for 1/100 seconds, that's 10 ms; The thin lines are each 1 ms. You can see the high signal being around 1.5ms - that's about what I was sending from the Atmega324.

Here's the code I used on the Axon (control.c):
Code: [Select]
/****************************************************************************
*
*   Copyright (c) 2008 www.societyofrobots.com
*   (please link back if you use this code!)
*
*   This program is free software; you can redistribute it and/or modify
*   it under the terms of the GNU General Public License version 2 as
*   published by the Free Software Foundation.
*
*   Alternatively, this software may be distributed under the terms of BSD
*   license.
*
****************************************************************************/

void read8bit(void)
{

//uartSetBaudRate(1, 500000);
outb(UBRR1L, 1);
outb(UBRR1H, 0);

a2dSetPrescaler(ADC_PRESCALE_DIV16); // Set the ADC prescale so we get fast conversions

// Prepare ADC to convert from port "1" - sorry by this, that's where my inter-mcu cable lands,
    ADCSRB &= ~_BV(MUX5);
    outb(ADMUX, (inb(ADMUX) & ~7) | (1 & 7));   // the (1 & 7) part selects the port, change the 1 to something else (between 0 and 7 that is!)
sbi(ADCSR, ADIF);
sbi(ADCSR, ADSC);
while( bit_is_set(ADCSR, ADSC) );

// Send an start byte

uartSendByte(1,0);

// ADC result
volatile unsigned char ADCR;

while (1)
{
while( bit_is_set(ADCSR, ADSC) ); // wait until previous conversion completes
ADCR = ADC >> 2;
// Start next conversion
sbi(ADCSR, ADIF);
sbi(ADCSR, ADSC);

while(!(UCSR1A & (1<<UDRE1))); // wait until previous byte got sent
outb(UDR1, ADCR);
}
}

void read4bit(void)
{

//uartSetBaudRate(1, 500000);
outb(UBRR1L, 1);
outb(UBRR1H, 0);

a2dSetPrescaler(ADC_PRESCALE_DIV8); // Set the ADC prescale so we get fast conversions

// Prepare ADC to convert from port "1" - sorry by this, that's where my inter-mcu cable lands,
    ADCSRB &= ~_BV(MUX5);
    outb(ADMUX, (inb(ADMUX) & ~7) | (1 & 7));   // the (1 & 7) part selects the port, change the 1 to something else (between 0 and 7 that is!)
sbi(ADCSR, ADIF);
sbi(ADCSR, ADSC);
while( bit_is_set(ADCSR, ADSC) );

// Send an start byte

uartSendByte(1,0);

// ADC result
volatile unsigned char ADCR_1;
volatile unsigned char ADCR_2;

while (1)
{
while( bit_is_set(ADCSR, ADSC) ); // wait until previous conversion completes
ADCR_1 = ADC >> 2;
// Start next conversion
sbi(ADCSR, ADIF);
sbi(ADCSR, ADSC);
while( bit_is_set(ADCSR, ADSC) ); // wait until previous conversion completes
ADCR_2 = ADC >> 2;

ADCR_1 = (ADCR_1 & 0b11110000) | (ADCR_2 >> 4);

while(!(UCSR1A & (1<<UDRE1))); // wait until previous byte got sent
outb(UDR1, ADCR_1);
}
}

void control(void)
{
read4bit();
}

Here's the image:
Title: Re: how to make a GUI for robots?
Post by: Admin on February 15, 2009, 07:23:21 AM
Nice!

I think this is good enough resolution for testing servo PWM. :)
Title: Re: how to make a GUI for robots?
Post by: Admin on February 19, 2009, 03:49:55 AM
RoboRealm now has a GUI that communicates directly with the Axon to control servos from your PC:

http://www.societyofrobots.com/robotforum/index.php?topic=7041.0



edit: fixed link
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 19, 2009, 03:56:30 AM
That's the wrong link, isn't it.
http://www.societyofrobots.com/robotforum/index.php?topic=7041.0
Title: Re: how to make a GUI for robots?
Post by: Admin on February 19, 2009, 04:25:15 AM
lol oops

link fixed
Title: Re: how to make a GUI for robots?
Post by: cosminprund on February 22, 2009, 03:33:18 PM
Just to let you know this is not dead. This weekend I worked on the code that will run on the MCU. The code is made to be easily ported from one Atmel to another, lots of "defines" and conditional compilation. In fact one only needs to alter the file "customize.h" to make it work with an other MCU, and even that is made to be easy. The code also implements an bidirectional communication protocol - or to put it in the usual RS232 words: I implemented an AT command set :D

The brave ones of you might want to download the code (it's in the attachment) and give it a try. The code is NOT complete: only one "dump" method is implemented, the code wasn't tested on anything but the Axon - in fact if you try to compile for an MCU that only has one USART you'll get an error because I haven't implemented that branch of the conditional compilation.

This is a quick reference on the "AT" command set, just to get things started:
"AT" => gives an "OK - I'm here message"
"AT?" => gives information on all available AT commands - sort of like an help.
"ATI" => gives information on the MCU and it's capabilities. It's designed so an GUI like the SoR Scope may parse the returned information and figure out what's on the other side of the RS232 :)
"ATDUMP DECIMAL ALL 8BIT" (or it's short form "ATD D A 8") is basically the equivalent of the "axon_daq" - it converts and dumps all configured pinx (16 on the Axon) and writes the result as a decimal value (human readable). This is the only "dump" variation that works at the moment.

Right now the code doesn't work with the SoR Scope GUI (funny thing, isn't that) because the SoR Scope needs to learn to send the AT commands. The code is provided as an AvrStudio project: unzip, open it up in AvrStudio and hit "build all". I didn't provide an HEX file because I don't want people tempted to use it on the Axon with Axon's bootloader: This project was made from scratch, it doesn't include any of the Axon source code and I'm not sure if any special configuration options need to be made for it to work with the Botloader!

Anyway, have fun with the code, I know I had fun writing it.
More next weekend.
Title: Re: how to make a GUI for robots?
Post by: Admin on March 01, 2009, 09:40:24 AM
Quote
it doesn't include any of the Axon source code and I'm not sure if any special configuration options need to be made for it to work with the Bootloader!
It won't interfere with the bootloader in any way. So no problem with including the .hex!

Just let me know what I should add to the SoR Scope tutorial when you're ready. I haven't been too motivated to work on this much more simply because its already passed my expectations and what I currently need it for. :D
Title: Re: how to make a GUI for robots?
Post by: cosminprund on March 02, 2009, 01:38:42 AM
You shouldn't work on the tutorial until I manage to finish the configurable part in the Scope itself. Ie: after you connect to an MCU that's running the SoR Scope AVR software you'll be presented with a dialog box to decide for yourself what you want to graph and how (what pins, what speed, stuff like that). Technically all the difficult bits are done, it's just that I got carried away with other stuff and haven't managed to write a single line of code over the past week :(

As for what should be in the tutorial, I've got a few ideas:
- It should show how you use the Scope to figure out what data you're receiving from an sensor. IR sensor would work out-of-the-box, for the Ping))) sensor a new option is needed (feature creep :( )
- It should show how you measure the PWM pulse from an other MCU!
- It should show how to use the Scope from an running robot (ie: it needs some functions to send "updates" when needed; Coupled with the ability to send an indication of what the servos are supposed to do it would provide a cool debugging tool).

I'm also planning on writing a small helping library that would do "Hardware Assisted Software PWM", with one or two full ports (ie: 8 or 16 servos), using one 16 bit counter (overflow interrupt actually) in a set-and-forget manner (the library would expose one global variable per connected servo where one just writes the length of the pulse, allowing the software to do everything else). I'm planning on using the SoR Scope to test and prove this library :)
Title: Re: how to make a GUI for robots?
Post by: Webbot on March 13, 2009, 11:21:52 PM
Incidentally: have you tried setting U2XN (see section 22.2.2 of ATMega640 spec).

The transfer rate can be doubled by setting the U2Xn bit in UCSRnA. Setting this bit only has
effect for the asynchronous operation. Set this bit to zero when using synchronous operation.
Setting this bit will reduce the divisor of the baud rate divider from 16 to 8, effectively doubling
the transfer rate for asynchronous communication. Note however that the Receiver will in this
case only use half the number of samples (reduced from 16 to 8 ) for data sampling and clock
recovery, and therefore a more accurate baud rate setting and system clock are required when
this mode is used. For the Transmitter, there are no downsides.


So you may be to double the xmit speed from the CPU. Havent tried it yet but just a thought.
Title: Re: how to make a GUI for robots?
Post by: superchiku on March 14, 2009, 04:06:48 AM
what i have been trying to dois that...iam writing dll files using c++...then usig vb iam designing the gui and importing the dll files to use its functions then...iam programming my microcontroller to recive commands from my c++ back end...

its quite tricky but nonetheless very usefull...oh yes the gui is connected to the mcu via wireless.