Ardupilot Flight Controller with onboard OSD

[Andy Little]

Hi,

Thought you might be interested in this project using ArduPilot to create an STM32F4 based Flight Controller with onboard OSD. The board is basically an OSD dev board with the spare stm32 pins broken out:

The software uses FreeRTOS. There are 2 top level tasks, one to draw the OSD and one to run the Ardupilot scheduler.

So far the only other task is the scheduler timer which I opted to put in a task rather than an interrupt for now.

Some tests of the drivers:

All software and hardware is licensed under GPL

regards
Andy

[Andy Little]

Completed and tested basic SPI driver

That means I should have a working set of sensor drivers.  I guess at some point soon I should try running the AP_InertialSensor INS_generic example

unless anyone can suggest a better in between step ?


regards
Andy

[Andy Little]

Carrying on with my barebones STM32F4 based Ardupilot port.

Here is a pic of pretty much everything attached to the board (except Cam and Vtx)

There are 4 servo outputs
The Compass is a HMC5883L. I have used these on all my other APM based planes. Very cheap and seems to work well enough.
The Baro is a MS5611. Its pretty accurate and not too pricey
The Compass and Baro share the single I2C bus. I hope that wont cause a major problem, since neither needs a very high update rate.
The IMU is a MPU6000. This is on the single SPI bus and the clock can be cranked up to 21 MHz which is just in spec.
The Airspeed sensor is an analog sensor. I would consider this essential now and wouldnt fly without it. There are also analog inputs for RSSI Batt votage and Batt currentt. So its all pretty minimal, but that is the essence of this project enough and no more
There are 3  1/2 uarts. (1 tx only). This covers the basic needs of GPS/ telemetry and console.

So far I am working through the examples for the sensors:
   AP_Compass_test
   BARO_generic
   GPS_AUTO_test

The AP_HAL concept certainly seems to be working well. After having done my basic drivers, the code generally seems to "just work" :)
  
Just fired up INS_generic. This is the biggie, but not sampled the menus yet as its way past my bed time.

So far these single tests seem to be going OK. How well eveyrthing works together ? ... that is the next level I guess :)

regards
Andy

"avoid success at all costs " (Simon Peyton Jones)

[Andy Little]

Unfortunately moving (what was once) the AVRScheduler::_timer_isr_event to a FreeRTOS task is problematic. Either that or I have written some very strange SPI driver code.  I wont rule that out a it is still very young! Assuming the spi driver is working  I either move the timer functions back into an ISR ( though I really dont like long ISR's even though I can stack them on the STM32) or I move the timer_isr client functions out into their own tasks. I have already done this with the ADC so maybe it is time to bite the bullet. There are only  at max 3 timer functions I can see. ADC, IMU, Baro. Separate them into tasks and they can be called at their own pace, try to use DMA rather than busy waiting on the I2C and SPI busses and notify their relevant drivers when there is new raw data to process.  That is probably not Ardupilot any more though :)

regards
Andy

[Tom Pittenger]

Andy,

"Waiting" should be avoided at all costs. I'm not sure how much of the DMA is available in the SMT32 but that is a must-have for smooth operations. There are too many moving parts with critical timing to have *any* waiting going on.

-TomP

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Little]

On Friday, September 18, 2015 at 5:42:21 PM UTC+1, Tom Pittenger wrote:

Andy,

"Waiting" should be avoided at all costs. I'm not sure how much of the DMA is available in the SMT32 but that is a must-have for smooth operations. There are too many moving parts with critical timing to have *any* waiting going on.

-TomP

Hi Tom,

The STM32 has pretty good DMA support . There  are in total 16 so called "DMA streams" which can theoretically run in parallel. Its possible to hookup (among others) SPI, I2C, ADC and UARTs to DMA.  AFAIK the I2C DMA is a bit problematic so I'm running that in an interrupt . I do plan to use DMA for SPI though once I have things working. For the initial attempt at this though and to get something running I'm basically following the AVR implementation. and for SPI AFAICs that is busy waiting

https://github.com/diydrones/ardupilot/blob/master/libraries/AP_HAL_AVR/SPIDevice_SPI0.cpp#L86

But yes with FreeRTOS I cant really do usec timing as it uses  preemptive scheduler with a granularity of 1 millisec. I am unlikely to give up FreeRTOS so I have yet to discover what interesting problems that leaves me with :)

regards
Andy

[Tom Pittenger]

>>AFAIK the I2C DMA is a bit problematic

I²C is problematic in general :)

[Andy Little]

Some progress on my APM port...

The main issue is the use of an RTOS in what was originally a single threaded application.
I hoped this would be less of a problem since the code is now mainly running on multi-tasking operating systems,
but I ended up writing some higher level sensor architecture  while reusing much of the existing code which I know works :)

I decided to try to avoid using the  scheduler timer process altogether. I am currently using only single sensors and
have a single i2c bus and a single SPI bus available.

I  put the one I2C bus in its own  FreeRTOS task You can only use a bus serially so this seems to make sense!
The HMC5883 compass and the MS5611 baro are on the same i2c bus.
To make life easy I decided to run the i2c task loop at 100 Hz.
I used low pass filters for pressure and temperature right in the I2C task which expect a consistent sample rate, so the task 
alternates between reading the baro pressure and temperature, giving a raw update rate for those variables, of 50 Hz. 
I used the request single measurement option for the compass to give a smooth 100 Hz  raw data rate.

I applied a low pass filter to the compass too.
Thei2c  task starts a particular i2C transfer on the bus and then yields,
waking up when the transaction is done.  At some point I could try to get I2C DMA working but it works
well enough using interrupts. I leave the I2C bus at its lowest speed. I found that high speed doesnt
work well on long cables, which are mandatory for a compass so I figure it has to work at the lowest possible speed
for reliability and if the transaction is done via interrupts, it makes little difference, except to the lag, which
is not so critical for these variables anyway.

The data from the compass and Baro are communicated into the APM task using FreeRTOS message queues.
The APM task will block if there are no messages, but messages are fed at a high enough rate to keep the queue full, so
if all is working then there should be no blocking. The custom AP_Compass_Backend and AP_Baro_Backend are just stubs, which
receive the FreeRTOS messages.

The only thing on the SPI bus is the MPU6000 .When it has new data, the MPU6000 causes an interrupt
which is used to start a DMA transfer of the gyro and accel data from the IMU
I opted to run the SPI at 21 MHz which is just in spec for the MPU6000 but can throttle it back if its a problem. (At some point

it might be worth trying  another SPI accel/gyro interleaved on the same bus)

The DMA transfer complete interrupt is used to apply the raw data direct in the interrupt into low pass filters at a steady rate dependent on
the AP_InertialSensor settings. (The interrupt is given a low priority so may be pre-empted. ) The
 APM task blocks in the AP_InertialSensor::wait_for_sample function. It is woken at the end of the DMA transfer complete interrupt
if it is time to pass it new data ( ie at the required sample rate which can be selected as 50 Hz, 100 Hz, 200 Hz, 400 Hz).  By this means the MPU600 is running the main APM loop!

I found that I could run the MPU600 without a dedicated task, so providing a very timely response with little lag.

Again the AP_InertialSensor_Backend is just a stub, which picks up the latest sample when AP_InertialSensor::wait_for_sample unblocks.

Well that is the design so far. The code is written so just needs testing to see how well it works in practise :)

I hope to put the latest code on the quantracker_master branch of my Github/kwikius fork of Ardupilot shortly

regards
Andy

[Andy Little]

Nearly Ready to flight test ... Will of course tidy up the wiring a little first :) 

regards

Andy

[Andy Little]

Sensors working on the OSD board as seen through the OSD

https://www.youtube.com/watch?v=a5Qq_5Q6v9k

Also added a 128 K SPI FRAM, which is certainly simpler than my original plan for a I2C EEPROM. It meant adding an SPI task and figuring how to work with the MPU6000 on the same SPI bus.

Code at  https://github.com/kwikius/ardupilot/tree/quantracker_master.

In changing the application from a singlethreaded app to a multi threaded one, I found I had to change some wait loops to delays. ( My code blocks the thread in delays allowing other threads to work). However as you can in the vid, the STM32F4 has ample power to run the OSD overlay as well as the ardupilot code, so I hope I will be able to get this flying shortly!

regards

Andy

[Andy Little]

Anyone interested in this port on here?  Somehow feel i'm wasting my time posting anything about it. Doesnt seem to have had much reaction at all?

Or should I assume that silence is the official answer from drones-discuss?

regards

Andy

[Andy Little]

Well I at least am pleased with what I have done here and  dont really comprehend why there is zero interest in it on here, so to avoid wasting any more time I am going to fork this now and go my own way with it. 

Anyway, here is a video of the OSD running my ArduPlane fork. Hopefully now ready for a maiden flight.

https://www.youtube.com/watch?v=A6lSktmKMyI

Thanks for your time :)

regards

Andy

[Randy Mackay]

Andy,

 

     A video speaks a thousand words.  That is very smooth.

 

     So this is arduplane running on the OSD board under FreeRTOS (i.e. no NuttX)?  So there’s no pixhawk involved at all?  That’s quite impressive.

 

     I suspect the lack of response is more just that there’s a lot going on and people didn’t really understand what you’re doing.

 

-Randy

--

[Philip Rowse]

yes, pleas keep on it! lots going on at the moment, keeping us all distracted!

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER

    3D Robotics Australia

    +61 (0)427326366

    website | facebook | instagram

[Andrew Tridgell]

Hi Andy,

> Well I at least am pleased with what I have done here and dont really
> comprehend why there is zero interest in it on here, so to avoid wasting
> any more time I am going to fork this now and go my own way with it.

My apologies for our lack of response. I'm afraid my email load has got
to the point that I don't read every thread on drones-discuss, and it
wasn't until Randy just pinged me about this thread today that I read
it.

I'd previously misread the subject as being about adding an OSD to
ArduPilot, which isn't something I really need to help anyone with so I
skipped the discussion thread. Porting ArduPilot to a FreeRTOS based
board is much more interesting :-)

So I don't know if its too late, but having looked at your branch I have
a few comments, presuming you are interested in having this merged to
master.

I've been hoping someone would do a FreeRTOS based port of ArduPilot for
a while, as it would open up a lot of possible boards. The NuttX port
has served us well, but there are a heap of boards that FreeRTOS
supports and in many cases it would be a lot less work putting ArduPilot
on FreeRTOS than doing a NuttX port.

The architecture you've chosen is certainly quite different from our
other ports. It is somewhat of a mix between the approach we used for
the old AVR port (for APM1/APM2) and the approach we use for PX4 and
Linux.

Having a separate thread for I2C is something we are planning to do soon
for the PX4 and Linux ports. Lucas and I have been discussing having a
"thread per bus" approach. So if you have 2 I2C buses then you'd have
two dedicated I2C threads. The same goes for SPI - if you have 3 SPI
buses you'd have a thread for each.

What is more unusual is doing the handling of sensor inputs in the HAL
specific layers (assuming I've understood what is going on in your port
correctly).

We used to do some averaging in the HAL layer previously on PX4, but
we're been moving away from that and instead doing all of the processing
of sensor data in common code. The idea is to keep the sensor drivers as
simple as possible, and also allowing us to log raw samples (we can log
accel data at 1600Hz on PX4, which is great for vibration analysis). It
also enables things like the delta-angle/delta-velocity handling of IMU
data, with common code for coning corrections and improved accuracy in
the EKF.

Can you explain a bit about the quantracker library that your port uses?
In board_quan.mk it has this:

QUANTRACKER_ROOT_DIR = /home/andy/cpp/projects/quantracker/

Is that the FreeRTOS tree, or is this a layer on top of FreeRTOS? I'd
like to be able to build the port and it looks like I need some extra
dependencies.

I had a quick go at rebasing your port on top of current master and
there are a lot of conflicts. One of the things we ask contributors to
do is to make separate commits per directory and to mark the commit
messages with the directory being changed. That often makes rebasing on
master much easier. For example I get merge conflicts with changes in
libraries that really shouldn't be HAL specific (such as AP_NavEKF), but
I can't just tell git to skip those patches as they are mixed up with
changes to other parts of the tree.

What are your plans for this port? (now that we're no longer ignoring
you!) Are you planning on a PR to get this merged into master?

Cheers, Tridge

[Craig Elder]

Andy, I think we all missed the significance of this.  It is really great work and quite an amazing effort on your part.

[Andy Little]

Hi,

Thanks! The project does have some innovative features which I was sure would be of interest. I'm glad I'm not wasting your time

I will take a little time to compose a proper reply.

regards

Andy

[Andy Little]

 

"So this is arduplane running on the OSD board under FreeRTOS (i.e. no NuttX)?  So there’s no pixhawk involved at all?"

Yes. The STM32F4 is running ArduPlane in one thread and the OSD drawing code in another thread. The OSD driver code itself lives entirely in interrupts, but communicates with the osd drawing thread by semaphores.

The display is double-buffered. The drawing code in the on_draw callback function can take as long as it likes to draw its new overlay frame: 

https://github.com/kwikius/quantracker/blob/master/air/osd/video/draw_task.cpp#L40

Once the on_draw function returns, a buffer swap request is sent to the OSD Driver from the draw_task. The driver code replies (e.g handshake) once it has actually swapped buffers. The switch completes just before it is about to draw a frame. There is no pressure on the drawing code to complete within a particular video frame howvere. This makes it easy to write the on_draw function. Here is the minimal but fully functional Hello World app:

https://github.com/kwikius/quantracker/blob/master/examples/hello_world/main.cpp

The OSD driver doesnt take as much resources as one would at first think. You can have 4 colours, black white, grey and transparent, so needing a 2 bit "colour". For this, 2 SPI slave ports are used to drive the display, both driven by a single pixel clock. At the start of each osd line a gate timer is triggered. A DMA request is also setup on each of the SPI ports . When the gate goes high it starts the pixel clock running which in turn starts the DMA transaction to output the pixels for the line. Much credit for the classic STM32F4 OSD driver must be given to Sami Korhonen who wrote the original code 

in the OpenPilot repo, which was the basis of my code , and I believe those for BrainFPV and PlayUavOSD.

"Porting ArduPilot to a FreeRTOS based 

board is much more interesting :-) "

I have only been using FreeRTOS for around a year, but I like it a great deal and it is a kind of standard. It is quite a small library ( not that many functions) but extremely stable and with the functionality you need. I havent touched the more advanced parts yet, or the instrumentation etc. It works really well with STM32F4 ( and I am thinking to move on to STM32F7 for next iteration)

----------------

"The architecture you've chosen is certainly quite different from our 

other ports. It is somewhat of a mix between the approach we used for 

the old AVR port (for APM1/APM2) and the approach we use for PX4 and 

Linux"

I decided that APM1 and APM2  is the ideal basis hardware model for this FC. The rationale was that if the ArduPlane code could run on a 16 MHz 8 bit controller, it should easily run the same code to run satisfactorily on an STM32F4 ( with addition of the OSD ). I decided to target the same single sensors as the APM2. I have had an APM1 and a couple of APM2's and  know my way around the code a bit. I also have a PX4, but for my plane flying, the APM2 still does the job. My flying is Mostly manual but when I am putting the FPV goggles on or get into trouble or just for fun or showing off, flip RTH and watch the plane come back home. I think there is still a demand for that

(BTW The genesis of the OSD board was to provide telemetry via the video for sending data to an antenna tracker:

http://www.zoomworks.org/fpv/quantracker/doc/osd/firmwares/osd_telem_tx.html

http://www.zoomworks.org/fpv/quantracker/doc/osd/firmwares/osd_telem_rx.html

Or The board can also output Audio FSK telemetry:

https://github.com/kwikius/quantracker/blob/master/examples/osd_example1/board/fsk_task.cpp

It has gradually metamorphised intoa FULL FC.  )

So the basic idea is  the spirit of APM2 but with an OSD onboard,

like an upgraded APM2 with the emphasis on *physically small*, basic, simple and cheap. At some point I would certainly like to do an ArduCopter port too of course. The  problem with APM2 on Arducopter was it ran out of puff I think.. ? And an AntennaTracker port too of course...

That said the board will be capable of much more than just the basics, if it is part of the Ardupilot ecosystem. It needs to be done I think :)

"Having a separate thread for I2C is something we are planning to do soon 

for the PX4 and Linux ports. Lucas and I have been discussing having a 

"thread per bus" approach. So if you have 2 I2C buses then you'd have 

two dedicated I2C threads. The same goes for SPI - if you have 3 SPI 

buses you'd have a thread for each. "

Yes, as soon as you have threads available it makes sense. 

---------------------

"We used to do some averaging in the HAL layer previously on PX4, but 

we're been moving away from that and instead doing all of the processing 

of sensor data in common code. The idea is to keep the sensor drivers as 

simple as possible, and also allowing us to log raw samples (we can log 

accel data at 1600Hz on PX4, which is great for vibration analysis). It 

also enables things like the delta-angle/delta-velocity handling of IMU 

data, with common code for coning corrections and improved accuracy in 

the EKF. "

OK ..  and The following said slightly tongue in cheek, bearing in mind your experience!  I have been hacking this together to get it to work, but havent really been analysed in that much depth, but basically "bottom-up"

The MPU6000 driver code has no thread. Once set up, it all works in 2 interrupts

 

I have enabled the single MPU6000 data-ready interrupt, at 1 kHz for ArduPlane, ( 4 kHz hoped for copter but not tested)  with no on-MPU6000 Low Pass filter ( just to KISS and not try to tune)

 

The data ready interrupt starts a DMA request:

https://github.com/kwikius/ardupilot/blob/quantracker_master/libraries/AP_HAL_Quan/imu_task.cpp#L682

The data is filtered directly in the DMA complete interrupt:

https://github.com/kwikius/ardupilot/blob/quantracker_master/libraries/AP_HAL_Quan/imu_task.cpp#L746

The filtered data is only sent ( in a 1 element FreeRTOS queue ) every n'th  interrupt 

to fulfill the Sample_rate passed in the AP_InertialSensor constructor:

https://github.com/kwikius/ardupilot/blob/quantracker_master/libraries/AP_HAL_Quan/imu_task.cpp#L815

I was trying achieve a deterministic ( low jitter ) time interval between each raw IMU sample input to the filter

based on that being the optimal ( constant dt) input to give accurate gyro and accel low pass filtering. All this is done in interrrupts so no thread switching involved

( I havent looked in detail as to how the PX4 scheme works but 

https://github.com/diydrones/ardupilot/blob/master/libraries/AP_InertialSensor/AP_InertialSensor_PX4.cpp#L56

suggests that passing the data up the layers may lead to timing jitter? ( I dont know) )

The ArduPlane Plane::loop() function blocks the APM thread in imu.wait_for_sample() until the 1 element queue from the end of the DMA complete interrupt is not empty:

https://github.com/kwikius/ardupilot/blob/quantracker_master/libraries/AP_InertialSensor/AP_InertialSensor.cpp#L1357  ( starting at  L1365)

It feels tight!

I appreciate that my problem is much simpler though and I am not  tackling some of the details you mention above, except by trying to provide a consistent dt. I'm leaving that part to the Frontend

------------------

"Can you explain a bit about the quantracker library that your port uses? 

In board_quan.mk it has this: 

 QUANTRACKER_ROOT_DIR = /home/andy/cpp/projects/quantracker/ 

Is that the FreeRTOS tree, or is this a layer on top of FreeRTOS? I'd 

like to be able to build the port and it looks like I need some extra 

dependencies. "

There are 2 libraries involved. There is my quantracker library and my quan library

https://github.com/kwikius/quantracker

https://github.com/kwikius/quan-trunk

There are some docs at :

http://www.zoomworks.org/fpv/quantracker/doc/osd/software_devel/toolchain.html. 

The python script should work in Linux.

I have been in close contact with Tom Ren of PlayUav.com who has been very supportive of the project (Thanks Tom !)  and there is a good possibility that he will be producing a samll batch of sensor boards to fit the Air OSD board soon. I should add a plug for www.PlayUav.com here :)

I am sure Tom would be happy to send you the set of hardware if you prefer to wait for that. The board is being designed to be compatible with the APM and PixHawk sensors connectors where appropriate

--------------------------------------------------

"I had a quick go at rebasing your port on top of current master and 

there are a lot of conflicts. One of the things we ask contributors to 

do is to make separate commits per directory and to mark the commit 

messages with the directory being changed. That often makes rebasing on 

master much easier. For example I get merge conflicts with changes in 

libraries that really shouldn't be HAL specific (such as AP_NavEKF), but 

I can't just tell git to skip those patches as they are mixed up with 

changes to other parts of the tree. 

What are your plans for this port? (now that we're no longer ignoring 

you!) Are you planning on a PR to get this merged into master? "

Yes definitely. However I am pretty sure that It is not ready for a PR at all yet. There are lots of issues and I had better read the coding guidelines, For example the 2 external dependencies above and I should also get the code back in sync as far as possible. I would need to think about and discuss all that in more detail. For example I have made more use of my physical quantities library:

http://www.zoomworks.org/quan-trunk/quan_matters/doc/quan/fixed_quantity/intro.html

as it looked less and less likely there was interest. Its perfect for a fork of ArduPilot but not really to merge. There are many issues that boil down to how to make this properly compatible with ArduPilot, what should stay and what should go,.

I should also concentrate on getting the Plane in the air!

regards

Andy

[Andy Little]

Maiden flight completed. N.B the short video is just highlights. The flight was a little longer than that :) However the legal 25 mW Vtx power in U.K. means I need an antenna tracker, to get decent video quality which hasnt been added yet, so I cut out much of the bits with poor video quality. Still much work to do therefore

https://www.youtube.com/watch?v=pU-V8o-kjuI

Anyway, it flies, even if currently it has only proved itself so far as a glorified elevon mixer :)

regards

Andy

[Randy Mackay]

 

     Congrats!

 

     One small question, why is it leaning sideways at launch?

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Andy Little
Sent: 13-Nov-15 4:33 AM
To: drones-discuss
Cc: airt...@gmail.com; Craig...@uniserve.com
Subject: Re: [drones-discuss] Re: Ardupilot Flight Controller with onboard OSD

 

 

Maiden flight completed. N.B the short video is just highlights. The flight was a little longer than that :) However the legal 25 mW Vtx power in U.K. means I need an antenna tracker, to get decent video quality which hasnt been added yet, so I cut out much of the bits with poor video quality. Still much work to do therefore

--

[Andy Little]

On Friday, November 13, 2015 at 1:17:33 AM UTC, Randy Mackay wrote:

 

     Congrats!

Thanks. A good day !  This port is something have wanted to do for quite a while.  

 

     One small question, why is it leaning sideways at launch?

 

:) Thats the "non finger slicing" launch technique..  See about 20 seconds in to :

https://www.youtube.com/watch?v=oPdkDcDMQwI

regards

Andy

[Andrew Tridgell]

> https://www.youtube.com/watch?v=pU-V8o-kjuI
>
> Anyway, it flies, even if currently it has only proved itself so far as a
> glorified elevon mixer :)

Congratulations!

Did you get a tlog for us to look at?

I notice you don't define HAL_OS_POSIX_IO, so I'm guessing the board
doesn't have a local filesystem for dataflash logs? If we could see some
logs we may be able to get a good idea of how well it may be able to
perform in auto flight.

Cheers, Tridge

[Andy Little]

Hi Tridge,

On Friday, November 13, 2015 at 9:03:10 AM UTC, Andrew Tridgell wrote:

> https://www.youtube.com/watch?v=pU-V8o-kjuI
>
> Anyway, it flies, even if currently it has only proved itself so far as a
> glorified elevon mixer :)

Congratulations!

Thankyou. It was a good day. Some way to go and I had better try syncing my code before too long !

Did you get a tlog for us to look at?

I notice you don't define HAL_OS_POSIX_IO, so I'm guessing the board
doesn't have a local filesystem for dataflash logs? If we could see some
logs we may be able to get a good idea of how well it may be able to
perform in auto flight.

There is no logging at all yet. I have on my desk an OpenLog module which I am hoping I can use for logging, but I havent yet looked in detail to see if it will work.  Says it can do up to 100 k Baud to a serial port, which I hope is adequate..

regards

Andy 

 

[Andy Little]

Hi All,

Still porting away :) Currently trying to catch up.

https://github.com/kwikius/ardupilot/tree/quantracker_merge

Is the closest to master but the AP_InertialSensor code causes my OSD Artificial Horizon (ie showing latest IMU data) to update incredibly slowly, so something seriously wrong there. Lots change in ApInertialSensor recently?

https://github.com/kwikius/ardupilot/tree/quantracker_devel

.. is the same as quantracker_merge branch but with the old Ap_InertialSensor codes put back in, and in which AH works correctly . Not sure what the change is but scaling or filtering? probably should change my MPU6000 lib to send back an array of raw samples and then use the official MPU600 backend code. 

Also I see that libraries associated with a port are now added to the build without being added to the make.inc file, but not sure where that occurs. If anyone knows I would be glad of a hint. I am just modifying the inc file ATM.

Hope to get some work on logging done soon too. Still plan to use OpenLog for now, 

I will try to sync more reularly from now on! 

regards

Andy

[Andy Little]

On Monday, November 16, 2015 at 2:42:34 PM UTC, Andy Little wrote:

Hi All,

Still porting away :) Currently trying to catch up.

https://github.com/kwikius/ardupilot/tree/quantracker_merge

Is the closest to master but the AP_InertialSensor code causes my OSD Artificial Horizon (ie showing latest IMU data) to update incredibly slowly, so something seriously wrong there. Lots change in ApInertialSensor recently?

Solved. Simply set the sample rates to 0 when registering the gyro and accel in AP_InertialSensor backend.  Presumably not the optimal solution, but currently just at the "get it working" stage, and so can move on to getting some logging working now

regards

Andy

[Andy Little]

Quick update on the Ardupilot with Onboard OSD. I have been working on the problem of logging since the only available port I have left on the 64 pin part is  a uart. I originally planned to use the Sparkfun OpenLog, but in testing, Unfortunately it doesnt seem to like being written at more than 19,200 baud. I was thinking of starting on an upgrade to a stm32 based version when I saw this product:

http://www.artekit.eu/products/accessories/ak-sdfs-uart/

It looks to do pretty much everything I want and is based on a STM32F1 , so I have ordered one and am looking forward to testing it.

regards

Andy

[Randy Mackay]

Looking good.

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Andy Little
Sent: 26-Nov-15 10:31 PM
To: drones-discuss
Cc: airt...@gmail.com; Craig...@uniserve.com
Subject: Re: [drones-discuss] Re: Ardupilot Flight Controller with onboard OSD

 

 

Quick update on the Ardupilot with Onboard OSD. I have been working on the problem of logging since the only available port I have left on the 64 pin part is  a uart. I originally planned to use the Sparkfun OpenLog, but in testing, Unfortunately it doesnt seem to like being written at more than 19,200 baud. I was thinking of starting on an upgrade to a stm32 based version when I saw this product:

--

[Andy Little]

Quick update on this project

I managed to get out for a quick test flight today and tested out FBWA and RTL modes. Although it was gusty, both modes work fine. Unfortunately my SD card logger still hasnt arrived so I still cant get any logging data yet, but I am very pleased with how it is working otherwise

I have also set up Travis to run the Ardupilot test suite based on the official script ( though I have yet to add my own port yet as need to figure out the script !)  and aim now to clean up my code in preparation for a PR.

Video evidence to follow

regards

Andy

[Randy Mackay]

Cool, looking forward to the video!

 

-Randy

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Andy Little
Sent: 3-Dec-15 12:19 AM
To: drones-discuss
Subject: Re: [drones-discuss] Re: Ardupilot Flight Controller with onboard OSD

 

Quick update on this project

--

[Andy Little]

Video of 2nd flight with FBW and RTL modes. 1:14 FBWA, 2:32 RETL

https://www.youtube.com/watch?v=KQLArFbRjWg

Still flying quite close obviously but getting more confident, especially now that RTL mode is working, so hope I can push out a bit next time .

Also my logging hardware arrived this morning so I will try to get logging working for the next test flight.

regards

Andy

[Andy Little]

Have now added sending telemetry via the unused parts of the video signal to the list of features of the OSD. The main use of this is to provide position information for an antenna tracker. Out testing this morning with my old tracker and  works flawlesslyl. I used a second OSD dev board on the tracker which receives the video telemetry and just sends it out the serial port to the old tracker. I hope to get an Ardupilot/AntennaTracker version working shortly though. No video of this morning unfortunately as I couldnt get my DVR working, but I am sure I will be out again soon.

So what I have now is a compact minimalist FPV system which sends telemetry frm the aircraft in-band with the video. Couple that with the fact that OSD and FC are on the same ic and it starts looking nice and compact.

Anyway Really happy with it.  I may try a PR though the code is some way behind, but I may as well get the ball rolling :)

regards

Andy

[Andy Little]

An update on the project so you guys know its still alive :). Have had a few flights with the system now, despite the fact that UK is pretty wet and muddy at the moment. Here is a light from a couple of days ago, somehat more relaxed than  the previous flights, since for once t it was quite a calm day so you can get more idea of the FC working. The Autopilot is sending position telemetry down the video link throughout the flight to the tracker. Onboard the plane is a 25 mW 5.8 GHz video transmitter. The range is not great and so (though it was quite wet, which reduces range), I need now to see if I can track down noise in the system. I have been over 2 km with a similar setup, though on a nice hot sunny day...

https://www.youtube.com/watch?v=ybab6q70icI

The video is unedited and quite long, but hope that gives it authenticity :)

AS far as getting a PR together, I hope to get back to that now that Christmas is out of the way. If I get a bit of dry weather, I will try recording some logs too. As yet I havent completed the onboard logging via the serial port, but could record via Mavlink, however, In the current mud and damp here, I dont really want to take a laptop out flying, but hope to get some log data eventually.

Now looking to get a version of the board on a different style of plane...

reagrds

Andy

[Josh Welsh]

This is very, very cool.

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Andy Little
Sent: Friday, January 8, 2016 8:17 AM
To: drones-discuss <drones-...@googlegroups.com>
Subject: Re: [drones-discuss] Re: Ardupilot Flight Controller with onboard OSD

 

An update on the project so you guys know its still alive :). Have had a few flights with the system now, despite the fact that UK is pretty wet and muddy at the moment. Here is a light from a couple of days ago, somehat more relaxed than  the previous flights, since for once t it was quite a calm day so you can get more idea of the FC working. The Autopilot is sending position telemetry down the video link throughout the flight to the tracker. Onboard the plane is a 25 mW 5.8 GHz video transmitter. The range is not great and so (though it was quite wet, which reduces range), I need now to see if I can track down noise in the system. I have been over 2 km with a similar setup, though on a nice hot sunny day...

--

[Andy Little]

Update on this project.

Having worked exclusively on Linux over the past few years, I recently decided to try to get things building on Windows. The choices there seem to be

MingW

Cygwin

MingW64

MSVC

For now I have opted to just get it working in Cygwin. It seems the easiest for a user to setup and get running without issues as well as being still portable to other OS and compatible with current code

As far as a diydrones/ardupilot PR goes, I have to admit that my feeling now is just to take this project off in its own direction. I dont really look forward to arguing my case to get a FreeRTOS port accepted, against a stack of Linux/ Nuttx boards.  Having followed this list for some time, it seems that that things are heading rapidly in the direction of Linux. That is great but I dont feel I have much to add there. I like microcontrollers at heart.  The diydrones/ardupilot project also has moved a long way now from its Arduino roots. I would like to do something to get back in the Arduino direction. I thought about reviving the AVR branch, but  I would ideally like to make something that allowed to be used on the old hardware somehow

The other issue is that the diydrones/ardupilot API is currently changing rapidly. I think that if I try to keep up with the changes, I will never get any useful work done on the areas I am interested in, such as a [mixer](https://github.com/kwikius/mixer_lang). 

regards

Andy

[Lucas De Marchi]

Hi Andy,

On Thu, Jan 21, 2016 at 7:52 AM, Andy Little <airt...@gmail.com> wrote:
> Update on this project.
>
> Having worked exclusively on Linux over the past few years, I recently
> decided to try to get things building on Windows. The choices there seem to
> be
>
> MingW
> Cygwin
> MingW64
> MSVC
>
> For now I have opted to just get it working in Cygwin. It seems the easiest
> for a user to setup and get running without issues as well as being still
> portable to other OS and compatible with current code
>
> As far as a diydrones/ardupilot PR goes, I have to admit that my feeling now
> is just to take this project off in its own direction. I dont really look
> forward to arguing my case to get a FreeRTOS port accepted, against a stack
> of Linux/ Nuttx boards. Having followed this list for some time, it seems

Getting a FreeRTOS port would be very welcome (and this coming from
the Linux maintainer ;-) ).

> that that things are heading rapidly in the direction of Linux. That is
> great but I dont feel I have much to add there. I like microcontrollers at

I would appreciate changes from you targeting Linux :)

> heart. The diydrones/ardupilot project also has moved a long way now from
> its Arduino roots. I would like to do something to get back in the Arduino
> direction. I thought about reviving the AVR branch, but I would ideally
> like to make something that allowed to be used on the old hardware somehow

what really changed is that we are following more closely posix and
posix-like interface. So we can have
saner HAL interfaces. Recently Tridge added support for QURT, that is
an RTOS much in the spirit of
nuttx and freertos. I don't think you'd need to revive the avr branch
for that, the main architecture of
ardupilot did not change much since the removal of AVR... we just have
lots of cleanups to remove some cruft
that accumulated over the years.

> The other issue is that the diydrones/ardupilot API is currently changing
> rapidly. I think that if I try to keep up with the changes, I will never get
> any useful work done on the areas I am interested in, such as a

Well... we are rapidly changing but also accepting PRs much faster,
too. This means it's certainly more difficult to "keep your own way"
and then try to come back. However I also see this as an incentive for
people to working more closely with upstream. More contributions to
upstream == everybody wins.

Lucas De Marchi

[Andy Little]

Hi Lucas,

 Its not that simple...

I decided  that my priority is to get a finished board working with the Onboard OSD. This is quite a radical change.

I also have had an ambition to make a generic mixer for Ardupilot for several years,. This is a radical rework too since you need to rip the guts out of existing code to do that.(e.g https://github.com/diydrones/ardupilot/blob/master/ArduPlane/radio.cpp#L161 )

Finally I am using FreeRTOS. I would say that FreeRTOS ( or other RTOS , but I cant find any docs for QURT?) is a good fit for a flight controller IO, since it plays well with hardware interrupts and event driven programming... I would guess better than Posix which is not really a real time OS at all, so I would be interested in the rationale for using POSIX ? ( BTW .. For anyone wishing to try, a FreeRTOS port is obviously perfectly possible using a PX4 hardware. You might find a reduction in ROM use as well ! )

In my case All these things OSD /  OS / Mixer,  are big changes and I would have to fight for them all in a PR. (Been there done that !) I think it would be impossible with my code as it is, no board and on top of that the Ardupilot codebase is changing rapidly.

Based on the above reasoning I decided for now to freeze my Ardupilot revison and work on the parts I am interested in. This for me is just for fun after all !

When I have a finished board with everything working and have written some documentation then it will be easier. Maybe the Ardupilot API will be more stable too.

[Lucas De Marchi]

HI Andy,

see answers below

On Mon, Jan 25, 2016 at 7:51 AM, Andy Little <airt...@gmail.com> wrote:
> Hi Lucas,
>
> Its not that simple...
>
> I decided that my priority is to get a finished board working with the
> Onboard OSD. This is quite a radical change.
>
> I also have had an ambition to make a generic mixer for Ardupilot for
> several years,. This is a radical rework too since you need to rip the guts
> out of existing code to do that.(e.g
> https://github.com/diydrones/ardupilot/blob/master/ArduPlane/radio.cpp#L161
> )
>
> Finally I am using FreeRTOS. I would say that FreeRTOS ( or other RTOS , but
> I cant find any docs for QURT?) is a good fit for a flight controller IO,
> since it plays well with hardware interrupts and event driven programming...
> I would guess better than Posix which is not really a real time OS at all,
> so I would be interested in the rationale for using POSIX ?

Well... posix is not an OS... it's just a standard API the OS can
implement anyway it wants. It's up to the OS to do it in an
RT-friendly manner. Even for those that aren't, our HAL layer should
be able to abstract most of the things needed.

> In my case All these things OSD / OS / Mixer, are big changes and I would
> have to fight for them all in a PR. (Been there done that !) I think it
> would be impossible with my code as it is, no board and on top of that the
> Ardupilot codebase is changing rapidly.
>
> Based on the above reasoning I decided for now to freeze my Ardupilot
> revison and work on the parts I am interested in. This for me is just for
> fun after all !

Yeah, sure. I can't change your priorities. I'm just trying to help
saying you are trying to do 3 hard different things at the same time.
You could split it up and benefit from the code evolving together with
your changes rather than giving you lots of headache to keep it up to
date. As a first step, a HAL layer to support freertos for your board
could be done and then put the other things on top (or independently).

> When I have a finished board with everything working and have written some
> documentation then it will be easier. Maybe the Ardupilot API will be more
> stable too.

Problem with this approach is that code will never stop to evolve. As
I said, keeping it as a fork will always be more trouble than trying
to integrate it the right way.

Lucas De Marchi

[Andy Little]

On Monday, January 25, 2016 at 6:33:21 PM UTC, Lucas De Marchi wrote:

HI Andy,

[...]

> When I have a finished board with everything working and have written some
> documentation then it will be easier. Maybe the Ardupilot API will be more
> stable too.

Problem with this approach is that code will never stop to evolve. As
I said, keeping it as a fork will always be more trouble than trying
to integrate it the right way.

Lucas De Marchi

Hi Lucas,

You are right. It would be easier. 

however to get to a P.R, I need to get a board designed and built. I also need to get tests running, which requires an installer for some of my dependencies for Travis, etc

Unfortunately till those things are done I have to stop trying to keep in sync with upstream, else I wont get them done. That is life :)

regards

Andy