Today we finally got bored of waiting for the windy weather to subside so we took ArduWot out anyway. In the couple of weeks since our last flight we've written an interface between APM and MATLAB/Simulink utilising the MAVLink protocol. For anyone not famliar with Simulink its basically a tool used by control engineers to prototype control systems in a (reasonbly) friendly graphical way. We've used Simulink to control helicopters (T-Rex 250) indoors using a Vicon visual tracking system to determine position/attitude at 100Hz and a conventional RC transmitter. By utilising APMs fly-by-wire mode as the inner loop controller we can command roll, pitch and thottle at a fairly low rate from Simulink over Zigbee. This functionality lets us move outdoors (where we don't have the luxury of a VTS to give us 0.1mm/deg resolution!) and conduct some more interesting research activities, such as optimal control, formation flying, target tracking, etc...
Todays flight was a simple proof of concept test where we used a Simulink based PID controller to perform heading hold. It worked remarkably well but it was too windy to perform any meaningful performance assessments. The biggest issue we have is that using the RC_CHANNELS_OVERRIDE message takes command away from the RC transmitter (in FBW mode) so when we terminate the Simulink model if APM doesn't receive the message to stop overriding (setting all commands to zero) then it freezes on the last signal it received. As we're currently using XBee modules with whip antennae we do regularly lose connection for short periods so occasionally can not get control back (without switching to manual mode, which is undesirable in strong winds!). However, it seems that APM times out after about 20-30s and defaults back to the RC transmitter.
We are using RC_CHANNELS_OVERRIDE at the moment because the SET_ROLL_PITCH_YAW_THRUST message doesn't seem to be implemented on APM. I think for our purposes we may implement this message instead as this would allow us to command the nav_pitch and nav_roll angles on APM directly and utilise the mixing of RC transmitter and APM control if we ever need to get out of trouble quickly!
If anyone is interested in control of APM from Simulink I'd be happy to release the code (after a bit more testing!). Also if anyone has an interest in sending attitude commands and implementing the relevant MAVLink messages, let me know and I'd be happy to help!
Comments
Great work!!! I´m very interested in this application. Thanks!
@Fabien. Our testing to date has been hampered by poor weather and poor Zigbee antennae so I can't comment too much on the delay. By utilising the inner loop (attitude hold) on the APM we are hoping that our system is pretty insensitive to delay. Based on our testing of APM before implementing our own code, we're expecting a worst case delay of about 0.5-1s. I will let you know more when we have some test data.
We'll be releasing the code as soon as we get a chance to properly test it, unfortunately the weather seems to be conspiring against us! :-(
I'd be very interested in your code, are you getting good results implementing controllers over wireless, or do you strongly notice the time delay?
Outstanding work Owen, I am definitely interested in trying out the Simulink code.
Tanks
Today I set about implementing the SET_ROLL_PITCH_YAW_THRUST message in APM which was really quite simple. This implementation is far better than what I document above as it turns the "Auto" mode (or any other custom mode should you desire) into a "Simulink in command" loop, leaving your FBW mode free for manual handling.
Today was far too windy to do any flight testing but hopefully by the end of the week this system will have flown and I can report back with the results. As there seems to be some interest in this I would be happy to submit our APM modifications to the core code (although I've no idea how to go about this!), and release the Simulink code as well. I'll be setting up a google code account for our lab in the next couple of days and once the code is flight-proven I shall pass it on to you guys!
It's cool. @Owen
I'm impressed with your job.
I want to know more detailed information about your interface.
Thank you.
Great stuff, I too would be keen to take a look at the simulink interface!
Good work, I shall be interested to test this interface,
Regards, Jean-Louis
Well done! I'm not sure I've seen too many people adding an extra layer of control ontop of arducopter although I'm pretty sure that this type of thing was part of the reason why MavLink was used - i.e. Mavlink wasn't meant just for APM<->GroundStation but also to allow extensibility without reprogramming the APM itself. Congrats!
Cool!
@Owen
I would definitely be keen to take a look at the Simulink code. Getting data straight into Simulink would be a great advantage.
-
1
-
2
of 2 Next