Arduino Vs. Beagle Board Vs. others for UAV controller.

[John Scott]

Hi everyone. I haven't formally introduced myself, my name is John, I
am a 4th year mechanical engineering student studying at the
university of Queensland.

I would like to ask for some advice on the best micro-controller and
method of implementing an auto pilot for a UAV project I am working
on.

The project is to build a hovering rocket powered by three mono-
propellant hydrogen peroxide thrusters. It is quite an ambitious
project; more details can be found on my blog at: http://chokedflow.blogspot.com.au/.

I am currently working on the control problem which is quite similar
to that of a counter-rotating tri-rotor UAV but with some added
challenges due to the rockets changing mass. In particular I am having
trouble choosing the best method of turning the simulink model I have
of the vehicles control system into hardware.

I have given some thought to using an ArduPilot by modifying its tri-
copter code but I decided to start from scratch as the ArduPilot has
many more features than I need and I wanted to keep the code as simple
as possible.

Simulink is able to generate code which can run stand alone on an
Arduino or Beagle Board and it would definably be easier to build the
program in simulink as I would be able to reuse most of what I already
have, but I am not sure this is the best option. I think that a
simulink generated code should be to be run fast enough on an Arduno
Mega, although I am not sure. The system is pretty simple only
consisting of PID loops for roll and pitch. I haven't decided weather
to control the vehicle using a joystick connected to a computer which
sends commands or to use a RC remote in the same way that n-copters
and other hobbyist UAV's are usually controlled

If an Arduino mega didn't have enough power I thought that I could use
the other micro controller (apart from NXT) supported by simulink
which is the Beagle Board. The problem with the beagle board is they
have any low level digital/analog IO/s so I would need-to interface
something like another micro-controller for I/O. Simulink can also run
in real time on a PC so one other option would be to use a micro-atx
(probably atom) PC running windows and a I/O interface (probally
arduino) for connectivity. This would probally be easier but would be
a bit silly.

The other option is to just code the control system in C using avr
studio or Arduino. I think this will have to be done eventually but
while I am proving the concept I would like to stay with simulink as
its much easier to work with.

I would appreciated any advice or suggestions on the best path to take
for choice of micro-controller (even alternative micro-controllers)
and method of implementing my control system.

[Liam McQuellin]

Hi John,

Have you seen the Paparazzi software and associated hardware? Perhaps that is worth a look.

http://paparazzi.enac.fr/wiki/Main_Page

Liam

> --
> You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
> To post to this group, send email to lunar-...@googlegroups.com.
> To unsubscribe from this group, send email to lunar-numbat...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
>

[Ross Dungavell]

Hi John,
you can always split the task into two and use a separate arduino for each task:
Task 1: Flight Stabilisation - keeping your hovering rocket  at a fixed attitude and height or fixed rate of change. This is your inner control loop. It is high frequency and hopefully almost constant time to execute.
Task 2: Navigation - Moving the rocket from a to b - interpreting joystick controls or mission commands into a path. This is your outer loop and produces a new state for the inner loop.


With and ArduPilot for the outer loop you can easily do either reading analog signals from an RC receiver or digital link (i.e. xbee series 1,  digi xtend or microhard ). If you wanted to maintain a consistent user interface across both you could plug your RC controller into a PC.

With the beagle board your analog I/O would typically be done using custom hardware on an I2C bus (normally I2C bus 2 on a beagle board, as it is most accessible).

The micro ATX board with windows would be a bit of a challenge timing wise unless you intend to use one of the windows embedded versions.

As far as selecting a language to use it is really just a matter of what you are most comfortable with. You can try exporting code from simulink or writing in C. It's really a matter of which you think you can debug easiest.
Have you considered using quaternions rather than euclidian x,y,z for your coordinate system?

Also for your gaskets if you can't afford copper consider using high temperature silicone rubber (as for car exhausts).

Who at UQ is your supervisor for this project?


Cheers

Ross

--
You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
To post to this group, send email to lunar-...@googlegroups.com.
To unsubscribe from this group, send email to lunar-numbat...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.

--
Ross Dungavell
34 Marland Street
Kenmore
QLD 4069
Home 07 3129 5576
Mobile 0419 784492

[John Scott]

Thanks for the replies Liam and Ross.

I was not aware of the paparazzi, it looks quite a powerful tool.

Splitting the task into two sub tasks is a good idea. I suppose this
is how allot of complex systems probably work. For some reason I had
the idea that communication with other devices would be too slow but
after a bit of research I can see its not an issue.

My first goal is some really quick tethered hops where the vehicle
will throttle up till it can support its own weight then back down.
This should allow for controlled testing of the stabilisation system.
I think you are right Ross in saying this its just a matter of what
you feel comfortable with. I think that for the initial testing and
tuning flights (before I even think about manoeuvres) simulink is
probably the best tool to use (particularly not having a huge amount
of confidence in programming) as it will allow me to easily get data
back and tune my control loops. Simulink also has good support for
joysticks, which is how I currently control the simulator and I should
be able to just send joystick commands over the wireless link.

I think for any untethered flights I will want to re-write the system
in C as I feel like simulink provides another level of abstraction
which could cause problems, or am I just being pedantic? Once I know
exactly what I wan it to do translating it into code wont be as
daunting.

The project isn't associated with UQ. I wanted do do a part of it for
my thesis project but for various reasons (mainly safety concerns) I
wasn't allowed to. Still I talk to some of my lectures about it
(mainly Richard Morgan) who I believe think it really cool but seem
hesitant to get too involved (posibly because of liability?). I don't
really blame him, university's need to survive and a accident wouldn't
be good for..... business. Its a shame because its such an interesting
area of research and I think that the uni could get a great deal from
it if there were a way to work with them. There are two other Mech and
Aero students that are helping me, which is good because it is quite a
large and project. I would like to get more students involved also
because I have learnt so much, but I am also not sure about the best
way to go about it also because of liability.

Silicone gaskets are a good idea, I will look into if they are
suitable.

[Ross Dungavell]

Hi John,
one more thought upon reading your blog is that if your operating pressure is 500psi then rather than assuming you will never reach the rupture pressure of your tank you should have a pressure relief valve that operates at ~600psi (operating +20%) which still gives you a safety factor of 1.58 if 950psi is the consistent rupture pressure of the kind of pressure vessel that you intend to use.


Ross

[Bernard Davison]

Hi John,

My suggestions are
1) Don't use peroxide. It's to hard to do safely. It's killed many people.
2) The Paparazzi hardware will easily do the control that you need.
3) Don't use Peroxide unless you want to kill yourself and your team.
4) You should be able to use a hybrid rocket motor very easily and safely. You need to speak to Michael Nicholls. ASRI member in Adelaide. You can get his contact details from the ASRI website or go and speak to Richard Morgan or Fabian Zander. I believe they are in the Mech Eng building. Fabs is in the basement with the shock tunnels.
5) Don't use Peroxide as it'll take you 10 years to put together a safety plan that will satisfy the UQ OH&S guys.
6) Liam and I are actually working on something similar to what you want to do with Paparazzi hardware and we'd be happy to help.
7) Don't use Peroxide. It caused the sinking of the Kursk and caused the only death on the woomera range in the 30-40 years of rocket development that went on there. The ADF won't touch it with a barge pole.

Hope this helps.

Cheers
Bernie.

Sent from my iPad mini.

[Bernard Davison]

Did this go through???

Sent from my iPad mini.

[James Schults]

Hi John,

I am working on a similar problem for an unmanned UAV implementing our own control system. From our initial tests the arduino lacks the computational power to control a very low stability margin craft. In the case of rocket based thrust I would strongly suggest using a beagle board or perhaps a rasberryPi simply for speed. The question really depends on the complexity of your model and how efficiently it is implemented thought.

Based on the blog I assume you have a considerable budget I would suggest purchasing (or even borrowing an arduino) and running a Hardware in the loop simulation ie.

Computer sim -> Arduino with controller ->Computer Sim

This should give you some reliable response time data.

Cheers
James

[Luke Weston]

Somewhat off topic, but still, a fun bit of recreational reading :)

http://homepage.mac.com/sjbradshaw/baxterium/prospero.html

Cheers,
Luke

[John Scott]

Thanks everyone for all the feedback.

With regard to the safety concerns of using peroxide, my personal
feeling is that peroxide is safer than nitrous oxide. It is easy too
say that because historically there have been more issues with
peroxide compared to nitrous that it must be less safe and neglect the
fact that nitrous wasn't used historically. Indeed in recent years it
seems like there have been many more issues with nitrous, partly I
think because people have the idea that it is a "safe" fuel. The same
thing could have happened to peroxide back in the day, which proved to
be wrong (that you can handle it without any PPE) and that could be
why it has its reputation now.  My main concern about nitrous is that
how it behaves in vapour phase isn't well understood. We could have a
pretty big debate about the two oxidisers but I guess all rocket fuels
are dangerous but it seems like the dangers of peroxide are well
understood.

Bernard, I would love to hear more about your project with the
Paparazzi.

I am working on a hardware simulation currently so I should have some
speed data soon.

I have been talking to a control systems person and they have
suggested that a PID controller might not cut it for my unstable
system. Instead they recommended looking into using a linear quadratic
regulator. PID seems to be ok for inverted pendulum problems which is
basically what mine is. His other suggestion was to ditch the arduino
as it wouldn't be fast enough.