Close

Mission Controller

A project log for Pandelphi

MorningStar's Walking, Talking, Flying and Swimming Oracle

morningstarMorning.Star 05/07/2018 at 08:540 Comments

Having run out of screws to build Cub with, I'm now looking into the Naze32 AI pilot.

Connecting everything up properly is the first order of the day. Everything is pretty much taken care of by the board, its VBat input takes up to 36 volts and it has a built-in 3.3v regulator for the ST core running CleanFlight. It doesnt have an internal 5v supply, this is a bit remiss compared to everything else the board has built in because things like GPS, the receiver board and cameras etc run on 5v.

The wiring Scheme

I've included a 24v - 5v 2A USB power converter to feed the subsystems Naze doesnt handle. Pi and camera need 5v, as does the Atmel MCU and the camera levelling servos.

The Atmel has a 8bit Capsense port wired to antennae in the shell. These provide differential biosensing on six sectors and can detect any living creature from as much as a few feet away with good antennae. This reports to the Pi via I2C.

Also on the Atmel are the collision sensors. These are pairs of active UV photo transmitter-receivers that detect close-range objects hopefully including glass. I did consider using ultrasound, but six of those boards is unnecessary weight if I can get away with tiny photosensors instead. The four horizontal quadrants have full range discrimination and can measure distance, but of the vertical ones only the presence of something to land on is needed as altitude is capped and tightly controlled by the Naze32.

Landing will need to be performed on flat surfaces and a dedicated charging pad and is an area of research in its own.

Talking to the Pilot

Hacking into the Naze turned out to be ridiculously simple. CleanFlight recognises many different protocols that have sprung up for receiver boards, mostly proprietary. Luckily one is fairly well documented, and the Naze32 supports a Serial UART input for it.

MSP - Multiwii Serial Protocol is a packeted solution hosted on the two-wire data transfer built into nearly all microcontrollers. It has the following format.

Preamble : $M in ASCII.
Direction : < or > ASCII characters; the direction the data travels in, respective to the controller.
Size : Number of data bytes sent or zero if the command is a request for data from the controller.
Command : One of the Message_ID bytes.
Data : Data bytes expected by the command.
CRC : Command, Size and Data are XORed and summed.

The commands I'm particularly interested in are

105 : MSP_RC - Send ROLL / PITCH / YAW / THROTTLE / AUX1 / AUX2 / AUX3 / AUX4

200: MSP_Set_Raw_RC - Override ROLL / PITCH / YAW / THROTTLE / AUX1 / AUX2 / AUX3 / AUX4

Which take 16 bytes of data, 2 bytes per value as uINTs.

AUX1 is the Camera Gimbal Y Tilt, to level the camera when moving forwards and backwards.
AUX2 is the Camera Gimbal Y Rotate, to level the camera when moving sideways.
AUX3 and AUX4 are currently unused.

104 : MSP_RAW_IMU - Return ACCX / ACCY / ACC Z / GYRX / GYRY / GYRZ / MAGX / MAGY / MAGZ

Which returns 18 bytes of data, 2 bytes per value as uINTs.

114 : MSP_ANALOG - Return VBAT / POWER / RSSI / AMPS

Which returns 7 bytes, an INT and three uINTs

Using the override command 200, when the Naze doesnt see any data it returns to hovering. That means I can just override it when needed by the PI's AI, and let it get on with its job of flying and monitoring the batteries.

Building the Turbines

I've ordered a pack of 'Triprops' - 20 props in all, half of them are CW and half CCW with three blades. These things are everywhere, seem to be a standard with 5mm hubs, all 140mm dia in a range of colours.

Yes of course I ordered them all in purple...

They are way too big of course, I'll have to cut them down. For this I'll mount them on a motor thats itself mounted on a hinge with a pin so I can mark them all identically. I'll still have to balance them with dots of glue, but it wouldnt be as bad as trying to manufacture these myself.

The turbines will have three or four prop sets each, I havent decided yet and will experiment with lift generated by them. This is the general format.

Typically they will still be a real nuisance. They turn CCW too, and the threads on the motor shafts are reversed so the torque tightens the locknuts. That means the extended shaft will have to be threaded with a left-hand thread too, for which I will have to buy a tap and die. I have right-handed ones...

I never thought I'd find a use for them, but you cannot buy left-handed aluminium screws for love or money even in this day and age, I'll have to make them. ;-)

Discussions