Meetings
# | Date | Time | protocol | apo | fma | lan | lpe |
---|---|---|---|---|---|---|---|
1 | 2015-04-23 | 16:00 - 17:30 | lpe | ||||
2 | 2015-04-23 | 17:30 - 18:30 | lpe | ||||
3 | 2015-04-26 | 17:30 - 21:00 | fma | ||||
4 | 2015-04-30 | 16:00 - 16:40 | lpe | ||||
5 | 2015-05-07 | 16.00 - 18.00 | lan |
Meeting Details
- Moderator: ssm
- Protocol: lpe
- Attendees:
- ssm
- cmot
- fma
- lan
- apo
- lpe
- Start: 16:00
- End: 17:30
Agenda
Choosing the hardware (fma/lan/apo)
- Choosing between Crazyflie or an alternative (i.e. FlameWheel F450 + Arduino board) --> Probably (most likely the FlameWheel F450!)
- Determined the scope of working with the FlameWheel:
- What can the Arduino do? SCCharts on Arduino? Might be a whole topic for a thesis
- Is the Arduino strong enough (clockwise)
- We will have to create a whole Flight Control (But there are presumably enough tutorials on the internet)
- In General: Check existing projects (of Arduino-Copters and similar things)
- Planning and Constructing of the Copter is not its own topic of a thesis
- We still have to settle on concrete sensors
- Estimate of prices important for our proposals
- If things go wrong, always stay in contact with ssm/cmot! If there is really no solution, "it doesn't work" is also a conclusion for our theses
Stash, Confluence (lpe/ssm)
- We need our own repository in the Stash
- How does the Build work? Not necessarily important for us, since we for the most time wont work on the main branch (or on KIELER)
- How does Confluence work for us? We needed our own page and working rights (–> Solved as of April 24th)
- We need to uploads protocols and documentation
Proposals (all)
- How will we allocate the different topics of the proposals? And what exactly will we need?
- Price & Time estimation
- Constructing the Copter
- Skeletton
- Sensors
- Distance
- Positioning
- Gyroscope
- Microcontroller
- (Arduino)
- How to control sensors and actors
- All of this probably in cooperation of all of us
- SCCharts-Connection
- Flying/Hovering (SCCharts)
- Simulation
- Flight
- Reading and Interpreting sensors and act accordingly
- Safety
- Collision control, what to do when the battery is low, when systems fail, etc.
- Flying from a to b
- Pathfinding
- etc.
- How does the Computer know what a and b are?
- Simulation is very important!
- Handing in until April 29th necessary? --> But probably a first draft until then
Wed. 13.05.15 - 13:25 (fma)
For providing the ability of using the real sensors and actuators as well as the simulation to test the quadcopter, we decided to use some interface, which can both, communicate with the hardware or with the simulation.
...
Tue. 12.05.15 - 13:19 (fma)
Since the components are shipped with an unknown arrival date and for testing the interaction of the different sensors and actuators we will build an Arduino Lego Mindstorms setup on three wheels.
The NXT will therefor provide some basic navigation functions like goForwards, goBackwards, rotateRight, etc., as the software for basic flight is going to do later, too, and control the motors accordingly. The Arduino will be connected to the rest of existing components as usual.
An NXT block is generally able to communicate over I2C as master to any slave device, for instance the Arduino. Via simple looped polling the NXT can ask the Arduino for drive commands.
To connect the Lego block to the Arduino a Mindstorms NXT cable is ordered, which will be cut open and linked to the microcontroller. For further understanding about wiring and I2C the LEGO MINDSTORMS NXT Hardware Developer Kit.pdf gives a good start. In addition the webpages of leJOS News and Dexter Industries seem to be quite helpful and even give some basic code example. Further information following...
Mon. 11.05.15 - 14:43 (fma)
Ultrasonic sensors and bluetooth bridge have been delivered. Communication with Arduino is working.
Code:
The bluetooth module is found on the MacBook Pro as HC-06 in the list of available bluetooth devices. A connection can be established with Code '1234'.
Unfortunately the MacBook does not reconnect automatically after reset of the Arduino. The bluetooth module has to be unpaired and paired again to be usable again. Hopefully this will can be fixed somehow...
Update:
A much easier way of connecting via bluetooth is to use the Arduino Serial Monitor (Tools -> Serial Monitor).
It is now clear, how the module is handled by the MacBook Pro. Once paired, the HC-06 is always shown in the list of bluetooth devices as 'Not connected', unless an explicit connection is established. Establish a connection with a screen or the Serial Monitor. Once the connection is closed, HC-06 will be shown as 'Not connected' again. It is important to notice that the previous screen method has to be killed explicitly, not only closed, since there can only be one serial connection at once.