Aerflite Ardupilot Flight controller with onchip OSD - DevBoard

Ardupilot dev board

As shown in the pic, The Flight controller dev board has now sprouted various parts. Also carries a GPS not shown which screws on in the middle at the front of the contraption. I am pleased to say that the GPS easily gets a lock when mounted right close to the FC, unlike my original OSD which could kill the GPS unless carefully sited.

In the picture you can see 2 versions of the FC. Unfortunately, the original died when I connected the battery the wrong way around. I added a diode on Mk2 to prevent a repeat. The original is still dead in the pic. I opted to make a new board rather than find the blown parts, but hope eventually to revive the dead one. I had hoped that the polarised battery connectors would prevent this sort of error, but the culprit in this case was the battery balance connector which could make contact when fitted backwards as I found out.

It certainly takes a while to put this 2nd board together by hand again, which has put me back a few days, but I hope that I will be running the ArduPlane image soon now.

I decided to try out using Eeprom rather than FRAM for storage, since it is much cheaper per byte of storage (Fram is 10 to 15 times the price). This caused me a bit of head scratching. There is a big difference between EEPROM and FRAM.
With Fram you can send a command to read/write some input data to/from storage. The data can be any length and start at any position in the fram memory.

With EEPROM however there are 2 additional hurdles. Firstly you can only write 1 page at a time. (Pages vary from 32 bytes to 256 bytes in size). Secondly after a write of that page has been sent, you must wait an interval while the write is processed. This is usually of the order of a few milliseconds.

To try to make EEPRom writes fast, I decided to buffer the writes. I allocated some structures which allowed a copy of up to 32 bytes of data ( this allows for a 3D vector of floats + some extra data), so when a write is done, initially it just sits in the buffer. The buffer is polled periodically to see if there is new data to write and then written to eeprom.
For reading on the other hand I poll at a higher rate. For a read the data usually need to be available ASAP, so the thread requesting the data is blocked until the eeprom has been read and the data returned.

The only snag with this scheme is if you write some data and then immediately read it. The data read will come from the eeprom and the latest written data may be in the buffer. Mostly in ArduPilot, data seems be generated and then saved rather than saved and then read. Logically why would you write data too eeprom then read it back immediately. However I need to go quite thoroughly through the code to check all this. In the worst case I will have to consider using FRAM again.

Also can be seen in the pic , a monitor has been attached to the contraption and a 3DR telemetry transceiver has been added. This comes in useful since much testing requires turning the FC around in 3D, but getting data to a PC via USB is also essential.

You can also use the OSD as a monitor, for outputting data. In the pic I am running a test to calibrate the LIS3MDL onboard compass. This is a very cheap part, but once calibrated seems to work fine. It is still nice to be able to write data to a PC for testing and logging though.

I have also been doing a lot of other tests. These are often customised versions of the ArduPilot examples. You can see them here.

Anyway I hope that I can get the ArduPlane image running soon, at which point I willneed to get a plane to put it in!

1 Like

You may be interested in a change I put into master today to add support for storage to FLASH on stm32. It uses the last 2 sectors of flash instead of FRAM for persistent storage (ie. parameters, waypoints etc).
Just change this line to 1:
and change your bootloader to not wipe the last 2 sectors of flash. I have a branch for doing that in the ardupilot stm32 bootloader here:
master also has support for the LIS3MDL compass.
Cheers, Tridge

The Flash storage solution is great and I will certainly try it out, but uses up 256K of Flash and there are some interesting stm32 processors which are available in a small footprint but are somewhat constrained re FLASH. Anyway the use of EEPROM is just an interesting problem to solve so I will see how it goes. In worst case I will simply switch it off so you can read but not write to the eeprom in flight.

As far as the bootloader is concerned, I currently use the builtin stm32 bootloader It caters for USART, USB, CAN, SPI and I2C. The diy bootloader has to be uploaded at some point using the built in bootloader anyway? What is the advantage of the roll your own bootloader? I would like to avoid that if I can as it is just another hoop to go through

It is good to have support for LIS3MDL in master .

Finally managed to get ArduPlane running on the FC. Here is a quick video.

( Note that the pitch and roll sense is wrong I think but I hope you get some idea of the OSD.) I am also finding the OSD useful as a monitor
Of course much more could be done with the display, but now the plan is to get hold of a cheap and cheerful wing and get this flying

1 Like