PDA

View Full Version : [Question(s)] Can Roboard capture (read) PWM from an RC receiver (RC Servo lib)?



John Elliott
08-16-2009, 11:11 PM
Can the Roboard capture (read) PWM from an RC receiver?

The Roboard documentaion for the "RC Servo lib" says it has
"Capture mode (for reading RC servo’s position feedback)"
but I am not sure if I understand what is meant by the term
"RC servo position feedback"?

My application is to have the Roboard in an RC airplane and
have the Roboard read the servo commands from the traditional
RC receiver. If the Roboard decides that the RC receiver is in
failsafe mode it will overide the commands from the RC receiver
and use GPS to guide the RC airplane back to the position of the
pilot on the ground. Some people call this "pigeon homing".

Thanks. John Elliott (Seattle)

lnxfergy
08-16-2009, 11:19 PM
I believe the capture mode is for the higher-end digital servos that support a serial communications protocol, in other words, it uses an entirely different strategy than PWM and is not for reading in an RC pulse.

I think you'll have a hard time reading the length of an inbound RC-pulse on the roboard since programming in real time under an operating system such as Windows is quite difficult. Personally, I'd also be afraid to use PC-based failsafe.... seems more likely to fail than the device it's monitoring.

Any reason not use a true embedded controller, where real-time programming is easy, and the hardware/software is typically very robust?

-Fergs

jes1510
08-16-2009, 11:27 PM
Take a look at the Ardupilot project. It sounds like it may do what you want and is a real-time system.

Adrenalynn
08-16-2009, 11:29 PM
Seconded and thirded. There's a reason I have to build watchdogs into my critical PCs. I don't think I'd _ever_ consider having a PC *be* the watchdog.

Welcome to the forum, btw!

John Elliott
08-17-2009, 01:38 AM
I was afraid that might be the case.

I was hoping to use a PC based controller since I have done most of my programming on PC's in Windows and DOS, so it would be much less of a learning curve. A true embedded controller would probably be a better solution.

Thanks. John Elliott (Seattle)


I believe the capture mode is for the higher-end digital servos that support a serial communications protocol, in other words, it uses an entirely different strategy than PWM and is not for reading in an RC pulse.

I think you'll have a hard time reading the length of an inbound RC-pulse on the roboard since programming in real time under an operating system such as Windows is quite difficult. Personally, I'd also be afraid to use PC-based failsafe.... seems more likely to fail than the device it's monitoring.

Any reason not use a true embedded controller, where real-time programming is easy, and the hardware/software is typically very robust?

-Fergs

John Elliott
08-17-2009, 01:44 AM
I looked at the Ardupilot and it does look pretty capable. I may have to switch over to the Ardupilot.

I have already ordered a Roboard so I will look for another work around to get PWM input.

Thanks. John Elliott (Seattle)



Take a look at the Ardupilot project. It sounds like it may do what you want and is a real-time system.

CogswellCogs
08-17-2009, 03:40 AM
Have you looked at Windows Embedded CE ? It is a real time OS, is compatible with the RoBoard, and programs very much like Windows and DOS. You can even run .NET and MS Robotics studio applications. There is a learning curve involved in building an OS image, but the payoff is an extremly small footprint Windows OS.

Adrenalynn
08-17-2009, 05:56 AM
You've still got drivers goin' on, and from what I've seen, it just doesn't smell mature enough for me to consider it fault-tolerant. Even hard-realtime isn't necessarily fault-tolerant by nature... Just a total "IMHO" though.

CogswellCogs
08-17-2009, 12:25 PM
I've used WinCE on robots needing real time processing and it worked well. No crashes or hangs, either.

I've also written custom drivers under WinCE. Again, there's a learning curve but it is a great driver development environment. You get remote source code level debugging while your driver is running within the OS. WinCE ships with many, many drivers. Custom drivers are often not needed.

Adrenalynn
08-17-2009, 12:58 PM
Custom drivers would be needed for the RoBoard's servo control...

And RoBoards drivers have not proven to be particularly robust at this time.

[shrug]Not my plane that falls out the sky, crashes into a group of school-children, and explodes in a nitromethane fireball... ;) ;) ;)

darkback2
08-17-2009, 12:59 PM
There is a device...usb that can get RC data from an RC receiver. It shows up as an HID device (http://www.mftech.de/usb-interface_en.htm). I was going to use it to control my mech, but I ran into a few problems that may or may not be a factor for you. One thing was that I had to set the values to a fairly wide spectrum because of noise. This may have more to do with my radio and not the unit itself.

So the above device coupled with a roboard might be what you need. Hope this helps.

DB

John Elliott
08-17-2009, 01:01 PM
I will definitely consider WinCE for my applications with the Roboard.
Thanks. John Elliott (Seattle)


I've used WinCE on robots needing real time processing and it worked well. No crashes or hangs, either.

I've also written custom drivers under WinCE. Again, there's a learning curve but it is a great driver development environment. You get remote source code level debugging while your driver is running within the OS. WinCE ships with many, many drivers. Custom drivers are often not needed.

Adrenalynn
08-17-2009, 01:02 PM
>> It shows up as an HID device (http://www.mftech.de/usb-interface_en.htm).

Now we're going to add a USB HID device to a PC running Windows to be the watchdog/safety?

That's like the leadin for a cheesy 80's horror movie right there... ;)

John Elliott
08-17-2009, 01:28 PM
Great find! This could be exactly what I need for my application.
Excerpt from the website with the R/C USB-Interface:
www.mftech.de/usb-interface_en.htm (http://www.mftech.de/usb-interface_en.htm)
"It can be connected with an R/C receiver. So a transmitter without buddy box or PPM signal can be made suitable for simulators. The USB-Interface supplies the receiver with power. It reads up to 7 R/C channels from the receiver."

Thanks. John Elliott (Seattle)


There is a device...usb that can get RC data from an RC receiver. It shows up as an HID device (http://www.mftech.de/usb-interface_en.htm). I was going to use it to control my mech, but I ran into a few problems that may or may not be a factor for you. One thing was that I had to set the values to a fairly wide spectrum because of noise. This may have more to do with my radio and not the unit itself.

So the above device coupled with a roboard might be what you need. Hope this helps.

DB

darkback2
08-17-2009, 01:37 PM
well...we could always use linux...Next I'll propose he program it in MAX and use a mac mini.

:P

Seriously though, I'm sure everyone is right, there is probably a much more simple solution. But depending on the payload capacity of the RC plane Maybe a PC isn't a bad way to go. If you can use a PC for "pigeoning" Then perhaps with the addition of sensors you could use a PC as a sort of Auto pilot, and for self stabilizing, then perhaps in the future you could work into fully autonomous operation. You may need something faster than a roboard at that point.

Cool project though...keep us posted.

DB

jes1510
08-17-2009, 01:48 PM
What happens if Windows crashes? How much damage will the plane do?

darkback2
08-17-2009, 02:17 PM
Another question is what does the plane do by default? How does the plane respond to flying out of range of the transmitter? Does it fly around in a circle? Because if windows crashed, depending on how you had things set up, you could just have it go into a mode like that...

DB

John Elliott
08-17-2009, 03:12 PM
Good questions. On one of my earlier experiences with the glider with just a conventional RC receiver I had a radio lockout and the glider dove into the ground resulting in moderate airframe damage.

A frequent problem with flying RC gliders is loss of visual contact with the glider. This may be a more common problem than radio lockout. Almost every weekend at the local flying field you hear someone start yelling "I've lost it" and asking people to help look for it. Many gliders are never seen again.

I plan to do my flight testing with the Roboard in an area with sparse population and which is several miles away from the nearest house.

I have had some experience at work with software for an autonomous underwater vehicle for a PC104 based embedded PC running the Windows Operating System. The vehicle would run missions under the ice in the Arctic and it was important that it return to the hole in the ice for recovery. It seemed to be fairly reliable and we always got it back.

Thanks for the suggestions. I am still thinking about what to do and how to implement it.

John Elliott (Seattle)


Another question is what does the plane do by default? How does the plane respond to flying out of range of the transmitter? Does it fly around in a circle? Because if windows crashed, depending on how you had things set up, you could just have it go into a mode like that...

DB

John Elliott
08-17-2009, 03:23 PM
I just got the reply below from Andrew Alter of Trossen Robotics concerning my question on PWM capture. This confirms that the Capture mode of the RC Servo lib is for a special servo type. I was impressed at how quickly the Trossen Robotics support person replied to my question. Good support!

Hi John,


The PWM capture capability in the RC Servo Lib is actually a proprietary
function of the Kondo series servos. It's intended to provide real time
capture of the servo positions, enabling playback of entire motions rather
than still reference frames.


That said, technically the digital I/O should be capable of reading PWM,
however I'm not sure if the library is setup to do this properly. Long story
short: In theory? Yes. Have I tried it or seen it done yet? No.


Its still a very new product that hasn't fully matured on the market, as is
common with a lot of 'bleeding edge' robotics hardware.


Andrew Alter
Trossen Robotics
Hardware Support & Technical Writer

rp74
01-10-2010, 08:50 AM
If you're familiar with C or C++, you should be able to figure out what you need to do by examining the source code for the RoboIO library.

The method used in RoBoIO to capture servo positions is to evaluate a pin, and time its duration using a call to RDTSC (this is by a function called "getclocks" located in the source code file COMMON.CPP) once the pin has changed state. RDTSC simply returns a clock tick counter in the CPU. You could monitor a pin, and when it goes high, get the clock count, monitor for low, and when it goes low, get the clock count again. Subtract last from first, divide by 999, and there's your pulse width in microsecond increments (nice part about using a 1gHz CPU). See "delay_us" function in COMMON.CPP, same basic method.

The source code is, to this OO VB guy, a bit rough, but the capability is definitely there.

Thus far, I've managed to understand the C++ code (being a VB guy, that says something) well enough to build up enough functionality to move a servo without using the RoboIO code. Ultimately, I will end up integrating some C functions to do the more timing-critical things. The hardest part was in understanding how the registers get set up for certain functions. I've got that fairly well sorted, so I'm on my way.

Today, I plan to do more work on my motion control engine, something with accel and decel and chaining of motions, etc. I found the simple "capture and play" stuff in the RoBoIO library to be, well, limiting. :) You can use parts of RoboIO in a more direct fashion, but it's not straightforward.

In my opinionated opinion, the RoBoIO source is good proof of concept, but needs more work to be more fun. At some point, I'll take the time to write out functionally what it takes to talk to the IO on the board. I'm pretty set on the PWM / GPIO access, but still need to work on the SPI, I2C, and A/D converter access.

Whether or not you want to trust a PC versus an embedded controller for this type of application is a discussion I won't even get into. :)