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.
> 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.
> -- > You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
> To post to this group, send email to lunar-numbat@googlegroups.com.
> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
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
On 8 May 2012 21:07, John Scott <johnsco...@me.com> wrote:
> 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.
> --
> You received this message because you are subscribed to the Google Groups
> "Lunar Numbat" group.
> To post to this group, send email to lunar-numbat@googlegroups.com.
> To unsubscribe from this group, send email to
> lunar-numbat+unsubscribe@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
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.
On May 9, 2:58 pm, Ross Dungavell <r...@dungavell.net> wrote:
> 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
> On 8 May 2012 21:07, John Scott <johnsco...@me.com> wrote:
> > 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.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lunar Numbat" group.
> > To post to this group, send email to lunar-numbat@googlegroups.com.
> > To unsubscribe from this group, send email to
> > lunar-numbat+unsubscribe@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
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
On 9 May 2012 19:59, John Scott <johnsco...@me.com> wrote:
> 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.
> On May 9, 2:58 pm, Ross Dungavell <r...@dungavell.net> wrote:
> > 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
> > On 8 May 2012 21:07, John Scott <johnsco...@me.com> wrote:
> > > 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.
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Lunar Numbat" group.
> > > To post to this group, send email to lunar-numbat@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > lunar-numbat+unsubscribe@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
> --
> You received this message because you are subscribed to the Google Groups
> "Lunar Numbat" group.
> To post to this group, send email to lunar-numbat@googlegroups.com.
> To unsubscribe from this group, send email to
> lunar-numbat+unsubscribe@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
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.
On 08/05/2012, at 9:43 PM, Liam McQuellin <liam.mcquel...@gmail.com> wrote:
> On 08/05/2012, at 9:07 PM, John Scott <johnsco...@me.com> wrote:
>> 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.
>> -- >> You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
>> To post to this group, send email to lunar-numbat@googlegroups.com.
>> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
> To post to this group, send email to lunar-numbat@googlegroups.com.
> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
> 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.
> On 08/05/2012, at 9:43 PM, Liam McQuellin <liam.mcquel...@gmail.com> wrote:
>> Hi John,
>> Have you seen the Paparazzi software and associated hardware? Perhaps that is worth a look.
>> On 08/05/2012, at 9:07 PM, John Scott <johnsco...@me.com> wrote:
>>> 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.
>>> -- >>> You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
>>> To post to this group, send email to lunar-numbat@googlegroups.com.
>>> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
>> To post to this group, send email to lunar-numbat@googlegroups.com.
>> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
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.
<bern...@gondwana.com.au> wrote:
> Did this go through???
> Sent from my iPad mini.
> On 09/05/2012, at 8:06 AM, Bernard Davison <bern...@gondwana.com.au> wrote:
>> 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.
>> On 08/05/2012, at 9:43 PM, Liam McQuellin <liam.mcquel...@gmail.com> wrote:
>>> Hi John,
>>> Have you seen the Paparazzi software and associated hardware? Perhaps that is worth a look.
>>> On 08/05/2012, at 9:07 PM, John Scott <johnsco...@me.com> wrote:
>>>> 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.
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
>>>> To post to this group, send email to lunar-numbat@googlegroups.com.
>>>> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
>>> --
>>> You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
>>> To post to this group, send email to lunar-numbat@googlegroups.com.
>>> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "Lunar Numbat" group.
> To post to this group, send email to lunar-numbat@googlegroups.com.
> To unsubscribe from this group, send email to lunar-numbat+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lunar-numbat?hl=en.
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.
