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!