PC Dashboards and Telemetry

Hi,

If anyone is interested in operating their robot from a PC over IP,

The current beta version is available for download for free,. Feedback is helpfull good or bad.

Lou

Lou, this is an interesting program you have shown, but without reading the whole of the manuals, I sort of miss some key points. Maybe you could explain them.

What goes into the robot? You say it is IP via RF, Bluetooth, 802.11. But are you providing a software for the robot, and assuming it is a PIC, and therefore will run as a communications interface? And does the PIC have to be wired up just so then? or can it be adapted to any PIC based robot?

Where are you going with this eventually? Is this a shareware, or a future product?

I am just now involved in a LabVIEW class, and am getting exposed to Virtual Instruments. It looks like you've made a Virtual Instrument like panel for the PC, and have a communications standard to a program to run on the PIC or Lego Next. Am I getting the "jist" of what you're up to?

-- Randy M. Dumse

Yes, there needs to be some code running on the serial device so it may act as a slave and respond to incoming bytes over the USART. I provide sample C code and a simple protocol in the docs, and used the PIC 18F452. I also included a sample Lego NXT workspace. The app can support multiple communication protocols ( more to come soon ) and has build in support for serial com ports, as well as tcp-ip sockets. So any link over IP, RF ( modules ), 802.11, should be no problem.

The roboDNA Dashboard Designer app allows you to define how each uC device is wired up, so you can easily ( on the fly, or while prototyping ) change for example pin RA0 from analog input to digital output, and drag-drop a button onto a dashboard surface. By linking the button to the device's memory register, the pin can be toggled from the PC. ( assuming the device is responding using a known protocol ) If the RA0 pin is set back to analog, the user may choose to delete the button from the dashboard and use an analog gauge instead. Changing the singal on RA0 from 0-5v would move the dashboard gauge. Once you have defined what memory registers the device has, they can be linked to dashboard gauges/buttons. Also, it allows you to build a library ( xml file ) of you prototype or other devices, so you can have dashboards and connect to each on,e all from 1 location/app. For example I currently use 1 PIC board for 3 different robots, so I download the C code from MPLAB, and load up the dashboard specific to that bot.

I'm planning on always having a free version for a few platforms/devices including the NXT and PIC, and then allow users to upgrade.

My app is currently just for fly-by-wire type remote operation, as well as telemetry feedback. I did not including scripting capabilities, however 3rd party apps will be able to communicate and handle events/messages from roboDNA Dashboards. (eg. Microsoft Robotics Studio )

I included a simple communication protocol, but more like Lego NXT can/will be added soon. For example MODBUS and JAUS.

Regards, Lou

Man, if you could do JAUS... you might have a huge commercial success on your hands. But then you'd have to work for guys with bars/leaves/birds/stars on their shoulders and collars. They can be pretty impossible. (I know because I used to work for some, and before that, way back when, I was one of them :)

Have you thought about posting to the PARTS MarkIII mini sumo list? They have mostly PIC's and OOPIC's on their MarkIII's. I don't run PICs or Lego, so I can't use what you've got. But! The idea is super. Very interesting. Very inspiring.

Got me thinking I might be able to do something similar with my LabVIEW. Need a class project anyway. I looked up the various communications channels in LabVIEW, and see they have a USB and Serial interface built in. Looks like I can talk to my boards from LabVIEW. The language I use, IsoMax(TM), runs all the robot controls in the background, so the foreground is left open for the system console interface, and I can define tokens which can dump any data, variables, sensor readings I want. So I'm going to try to do something similar.

I've even got a little wireless video cam I can mount in the body, and LabVIEW talks about being able to integrate video into the front panel. Maybe I'll be able to really 'see" what the sumo sees as it operates. Of course, there are only so many hours in a day...

Best wishes with your efforts Lou. Keep us posted how it goes.

-- Randy M. Dumse

The JAUS protocol seems simple enough. Although my app is C# and will never be mil-spec, it is still a good one to support. I got the idea from the folks at Allen-Vanguard robotics. ( bomb disposal bot )

If they have an RF module or comm link of some kind, getting and loggin telemetry back from the SUMOs should be simple enough.

You should be able to use the Atmel or other uC, but the C code would need to be modified to run with those compilers. The C code is quite simple though.

How do you do your 802.11 interface on the PIC end? Does NXT come with that kind of connectivity? Seems I recall it being Bluetooth. Is that right?

-- Randy M. Dumse

I use a Lantronix RS232-TCP-IP module for 802.11, or Maxstream modems for RF. The Lego NXT does have a Bluetooth built in, so the virtual com port can be used as an RS-232. I should have a sample workspace for Microchip's Explorer 16 dev board ready in a couple of weeks. ( 16 bit parts )