add project document and sync with live.kladjes.nl
Some checks failed
generate pdf files / build (push) Failing after 2m4s
Some checks failed
generate pdf files / build (push) Failing after 2m4s
This commit is contained in:
parent
d9498b8135
commit
fc6a086ca2
GPG Key ID:
8A3EF0226518C12D
127
converters/include-files.lua
Normal file
127
converters/include-files.lua
Normal file
@ -0,0 +1,127 @@
|
||||
--- include-files.lua – filter to include Markdown files
|
||||
---
|
||||
--- Copyright: © 2019–2021 Albert Krewinkel
|
||||
--- License: MIT – see LICENSE file for details
|
||||
|
||||
-- Module pandoc.path is required and was added in version 2.12
|
||||
PANDOC_VERSION:must_be_at_least '2.12'
|
||||
|
||||
local List = require 'pandoc.List'
|
||||
local path = require 'pandoc.path'
|
||||
local system = require 'pandoc.system'
|
||||
|
||||
--- Get include auto mode
|
||||
local include_auto = false
|
||||
function get_vars (meta)
|
||||
if meta['include-auto'] then
|
||||
include_auto = true
|
||||
end
|
||||
end
|
||||
|
||||
--- Keep last heading level found
|
||||
local last_heading_level = 0
|
||||
function update_last_level(header)
|
||||
last_heading_level = header.level
|
||||
end
|
||||
|
||||
--- Update contents of included file
|
||||
local function update_contents(blocks, shift_by, include_path)
|
||||
local update_contents_filter = {
|
||||
-- Shift headings in block list by given number
|
||||
Header = function (header)
|
||||
if shift_by then
|
||||
header.level = header.level + shift_by
|
||||
end
|
||||
return header
|
||||
end,
|
||||
-- If link paths are relative then prepend include file path
|
||||
Link = function (link)
|
||||
if path.is_relative(link.target) and string.sub(path.filename(link.target), 1, 1) ~= '#' then
|
||||
link.target = path.normalize(path.join({include_path, link.target}))
|
||||
end
|
||||
return link
|
||||
end,
|
||||
-- If image paths are relative then prepend include file path
|
||||
Image = function (image)
|
||||
if path.is_relative(image.src) then
|
||||
image.src = path.normalize(path.join({include_path, image.src}))
|
||||
end
|
||||
return image
|
||||
end,
|
||||
-- Update path for include-code-files.lua filter style CodeBlocks
|
||||
CodeBlock = function (cb)
|
||||
if cb.attributes.include and path.is_relative(cb.attributes.include) then
|
||||
cb.attributes.include =
|
||||
path.normalize(path.join({include_path, cb.attributes.include}))
|
||||
end
|
||||
return cb
|
||||
end
|
||||
}
|
||||
|
||||
return pandoc.walk_block(pandoc.Div(blocks), update_contents_filter).content
|
||||
end
|
||||
|
||||
--- Filter function for code blocks
|
||||
local transclude
|
||||
function transclude (cb)
|
||||
-- ignore code blocks which are not of class "include".
|
||||
if not cb.classes:includes 'include' then
|
||||
return
|
||||
end
|
||||
|
||||
-- Markdown is used if this is nil.
|
||||
local format = cb.attributes['format']
|
||||
|
||||
-- Attributes shift headings
|
||||
local shift_heading_level_by = 0
|
||||
local shift_input = cb.attributes['shift-heading-level-by']
|
||||
if shift_input then
|
||||
shift_heading_level_by = tonumber(shift_input)
|
||||
else
|
||||
if include_auto then
|
||||
-- Auto shift headings
|
||||
shift_heading_level_by = last_heading_level
|
||||
end
|
||||
end
|
||||
|
||||
--- keep track of level before recusion
|
||||
local buffer_last_heading_level = last_heading_level
|
||||
|
||||
local blocks = List:new()
|
||||
for line in cb.text:gmatch('[^\n]+') do
|
||||
if line:sub(1,2) ~= '//' then
|
||||
local fh = io.open(line)
|
||||
if not fh then
|
||||
io.stderr:write("Cannot open file " .. line .. " | Skipping includes\n")
|
||||
else
|
||||
-- read file as the given format with global reader options
|
||||
local contents = pandoc.read(
|
||||
fh:read '*a',
|
||||
format,
|
||||
PANDOC_READER_OPTIONS
|
||||
).blocks
|
||||
last_heading_level = 0
|
||||
-- recursive transclusion
|
||||
contents = system.with_working_directory(
|
||||
path.directory(line),
|
||||
function ()
|
||||
return pandoc.walk_block(
|
||||
pandoc.Div(contents),
|
||||
{ Header = update_last_level, CodeBlock = transclude }
|
||||
)
|
||||
end).content
|
||||
--- reset to level before recursion
|
||||
last_heading_level = buffer_last_heading_level
|
||||
blocks:extend(update_contents(contents, shift_heading_level_by,
|
||||
path.directory(line)))
|
||||
fh:close()
|
||||
end
|
||||
end
|
||||
end
|
||||
return blocks
|
||||
end
|
||||
|
||||
return {
|
||||
{ Meta = get_vars },
|
||||
{ Header = update_last_level, CodeBlock = transclude }
|
||||
}
|
||||
@ -7,21 +7,47 @@ TEMP_MD_FILE="$BUILD_DIR/$(basename "$MD_FILE")"
|
||||
TEMP_TEX_FILE="$BUILD_DIR/$(basename "$MD_FILE" | sed -e 's|md$|latex|')"
|
||||
mkdir -p "$(dirname "$TEMP_MD_FILE")"
|
||||
|
||||
title="$(grep '^# ' "$MD_FILE" | sed 's|^# ||')"
|
||||
cp "$MD_FILE" "$TEMP_MD_FILE"
|
||||
|
||||
cat "$MD_FILE" | sed \
|
||||
for line in $(grep '^!\[.*\](.*\.md)$' "$TEMP_MD_FILE" | sed 's/ /%20;/g')
|
||||
do
|
||||
src=$(echo "$line" | sed -e 's/^.*(//' -e 's/).*$//' -e 's/%20;/ /g')
|
||||
echo "include found: markdown/$src"
|
||||
|
||||
cp "markdown/$src" "$BUILD_DIR/$src"
|
||||
sed -i "$BUILD_DIR/$src" \
|
||||
-e 's|\[toc\]||' \
|
||||
-e 's|^\[parent\].*$||' \
|
||||
-e 's|^# |\\newpage\n# |' \
|
||||
-e 's|^## |\\newpage\n# |' \
|
||||
-e 's|\[\([^]]*\)\](#\([^)]*\))|[\1](#\L\2)|'
|
||||
|
||||
sed -i "$TEMP_MD_FILE" \
|
||||
-e "s/^\!\[.*\]($src)\$/\`\`\`\\{.include\\}\n${src}\n\`\`\`/"
|
||||
done
|
||||
|
||||
title="$(grep '^# ' "$MD_FILE" | head -l 1 | sed 's|^# ||')"
|
||||
|
||||
sed -i "$TEMP_MD_FILE" \
|
||||
-e 's|\[toc\]|\\tableofcontents|' \
|
||||
-e 's|^\[parent\].*$||' \
|
||||
-e 's|^# .*$||' \
|
||||
-e 's|^#||' \
|
||||
-e 's|^# |\\newpage\n# |' \
|
||||
-e 's|\[\([^]]*\)\](#\([^)]*\))|[\1](#\L\2)|' \
|
||||
>"$TEMP_MD_FILE"
|
||||
-e 's|\[\([^]]*\)\](#\([^)]*\))|[\1](#\L\2)|'
|
||||
|
||||
cd "$BUILD_DIR"
|
||||
pandoc --to=latex --template "${BASE_DIR}/converters/template.latex" -o "$TEX_FILE" "$(basename "$TEMP_MD_FILE")"
|
||||
pandoc --lua-filter=../../converters/include-files.lua --to=latex --from=markdown+abbreviations --template "${BASE_DIR}/converters/template.latex" -o "$TEX_FILE" --data-dir="../../markdown" "$(basename "$TEMP_MD_FILE")"
|
||||
cd "$BASE_DIR"
|
||||
|
||||
# for line in $(grep '^!\[.*\](.*\.md)$' "$TEMP_MD_FILE" | sed 's/ /%20;/g')
|
||||
# do
|
||||
# src=$(echo "$line" | sed -e 's/^.*(//' -e 's/).*$//' -e 's/%20;/ /g')
|
||||
|
||||
# sed -i "$TEMP_MD_FILE" \
|
||||
# -e "s/^!\[.*\]($src)\$/\\include{$src}/"
|
||||
# done
|
||||
|
||||
sed --in-place \
|
||||
-e "s|?title?|$title|" \
|
||||
"$TEX_FILE"
|
||||
|
||||
16
makefile
16
makefile
@ -65,6 +65,10 @@ latex/pakket_van_eisen.latex: converters/mdToLatex.sh converters/template.latex
|
||||
mkdir -p build/pakket_van_eisen
|
||||
bash converters/mdToLatex.sh markdown/pakket_van_eisen.md latex/pakket_van_eisen.latex
|
||||
|
||||
latex/projectdocument.latex: converters/mdToLatex.sh converters/template.latex markdown/projectdocument.md
|
||||
mkdir -p build/projectdocument
|
||||
bash converters/mdToLatex.sh markdown/projectdocument.md latex/projectdocument.latex
|
||||
|
||||
# =======================================
|
||||
# === pdf generation ====================
|
||||
# =======================================
|
||||
@ -92,3 +96,15 @@ pdf/pakket_van_eisen.booklet.pdf: converters/bookletify.latex pdf/pakket_van_eis
|
||||
sed -e 's|?pdf?|../../pdf/pakket_van_eisen.pdf|' converters/bookletify.latex >build/pakket_van_eisen.booklet/bookletify.latex
|
||||
pdflatex -interaction=nonstopmode -output-directory="build/pakket_van_eisen.booklet" "build/pakket_van_eisen.booklet/bookletify.latex"
|
||||
mv build/pakket_van_eisen.booklet/bookletify.pdf pdf/pakket_van_eisen.booklet.pdf
|
||||
|
||||
pdf/projectdocument.pdf: latex/projectdocument.latex
|
||||
cd build/projectdocument && xelatex ../../latex/projectdocument.latex
|
||||
cd build/projectdocument && xelatex ../../latex/projectdocument.latex
|
||||
cd build/projectdocument && xelatex ../../latex/projectdocument.latex
|
||||
mv build/projectdocument/projectdocument.pdf pdf/projectdocument.pdf
|
||||
|
||||
pdf/projectdocument.booklet.pdf: converters/bookletify.latex pdf/projectdocument.pdf
|
||||
mkdir -p build/projectdocument.booklet
|
||||
sed -e 's|?pdf?|../../pdf/projectdocument.pdf|' converters/bookletify.latex >build/projectdocument.booklet/bookletify.latex
|
||||
pdflatex -interaction=nonstopmode -output-directory="build/projectdocument.booklet" "build/projectdocument.booklet/bookletify.latex"
|
||||
mv build/projectdocument.booklet/bookletify.pdf pdf/projectdocument.booklet.pdf
|
||||
|
||||
13
markdown/detailontwerp_stuursysteem.md
Normal file
13
markdown/detailontwerp_stuursysteem.md
Normal file
@ -0,0 +1,13 @@
|
||||
|
||||
### Vehicle Control Unit
|
||||
|
||||
De VCU is het belangrijkste onderdeel van het systeem, hiermee kunnen we het voertuig sturen, de belangrijkste keuze hierin is in welke taal we willen gaan programmeren. De reden hiervoor is zodat de volgende team makkelijker kan omgaan met de code. het makkelijkst is dan om met de Arduino IDE verder te gaan omdat het een bekent en veel gedocumenteerd systeem is. verder moet het ook draadloos verbinding kunnen maken met een controller zodat de volgende teams eventueel een andere keuze kunnen maken hoe ze willen sturen.
|
||||
|
||||
### Actuator
|
||||
|
||||
De actuator hebben we nodig om de wielen in een richting te kunnen sturen volgens Max Kappert(student automotive engineer) hebben we de volgende parameters gekregen die we nodig hebben om het voertuig te kunnen sturen.
|
||||
|
||||
|
||||
|
||||
Voor de Actuator is er een keuze gemaakt voor CDC (Continuous Damping Control) demper van SACHS, Maar vanwege de besteltijden van dit soort componenten kunnen we dit niet gebruiken. Daarom gebruiken we een actuator die er al staat, de A0-01/M van S-LINE.
|
||||
|
||||
@ -4,154 +4,450 @@ tags: kladjes, elektro, elektro/hr, elektro/hr/pee51
|
||||
|
||||
[parent](/tPb3Up1fQEuZ86yrJSkYRQ)
|
||||
|
||||
# Plan van Aaanplak
|
||||
# Plan van Aanpak
|
||||
|
||||
## Voorwoord
|
||||
|
||||
Voor u ligt het **Plan van aanpak** (PVA) voor het project **Superlight Personal Carrier (SPC) 2025**. Dit document vormt de leidraad voor de uitvoering van het project en beschrijft de probleemstelling, doelstellingen, methodologische aanpak en de verwachte resultaten.
|
||||
|
||||
Het SPC-project is een innovatief en interdisciplinair initiatief waarin studenten van verschillende opleidingen samenwerken om een lichtgewicht, zelf stabiliserend eenpersoonsvoertuig te ontwikkelen. Dit project bouwt voort op eerdere inspanningen en richt zich op het verder verfijnen en implementeren van cruciale systemen zoals de aandrijving, het stuurmechanisme en de Digital Twin-technologie.
|
||||
|
||||
Dit document is met zorg samengesteld en biedt een helder overzicht van de huidige status van het project, de uitdagingen die voor ons liggen en de strategieën die we hanteren om deze te overwinnen. We willen hierbij onze begeleiders, docenten en projectpartners bedanken voor hun ondersteuning en waardevolle inzichten.
|
||||
|
||||
## Inhoud
|
||||
|
||||
[toc]
|
||||
|
||||
## Achtergrond
|
||||
## Inleiding
|
||||
|
||||
Dit project is gestart in 2019 door een aantal studenten van opleiding Automotive van Hogeschool Rotterdam. Niels van Groningen is de opdracht gever voor dit project.
|
||||
Voor dit semester wordt er verder gewerkt aan het project **Superlight Personal Carrier (SPC)**. Het SPC-project is een samenwerking tussen studenten uit verschillende opleidingen bevordert, met als doel een lichtgewicht, zelf stabiliserend éénpersoonsvoertuig te ontwikkelen. Dit semester is gericht op het verfijnen en verbeteren van essentiële subsystemen, zoals het aandrijf- en stuursysteem en stabilisatie, waarbij er parameters uit een Digital Twin gehaald worden.
|
||||
|
||||
Dit project begint met een opgesteld **Plan van Aanpak (PvA)**. Dit document biedt een solide basis voor het project door de belangrijkste stappen, doelstellingen en methodologieën te beschrijven. Het PvA fungeert als leidraad en naslagwerk voor alle betrokkenen, en brengt duidelijkheid over wat er moet worden gedaan, hoe het moet worden uitgevoerd, en wat de verwachte resultaten zijn.
|
||||
|
||||
Naast een overzicht van de werkzaamheden biedt het PvA inzicht in essentiële aspecten zoals:
|
||||
|
||||
- **Planning:** Een gedetailleerd tijdschema dat de voortgang bewaakt en mijlpalen vastlegt.
|
||||
- **Kosten:** Een overzicht van de budgettaire eisen en financieringsmogelijkheden om het project binnen de gestelde grenzen te houden.
|
||||
- **Risico's:** Identificatie en beheersing van mogelijke obstakels om de betrouwbaarheid en kwaliteit van het eindresultaat te garanderen.
|
||||
|
||||
Door deze gestructureerde aanpak wordt een basis gelegd voor een uitvoering van het project. Het PvA maakt het mogelijk om op een doelgerichte manier toe te werken naar een functioneel en valideer baar eindresultaat: een rijdend voertuig dat klaar is voor verdere ontwikkeling.
|
||||
|
||||
## Probleemdefinitie
|
||||
|
||||
### Probleemstelling
|
||||
|
||||
Hedendaags worden er veel grote voertuigen gebruikt om enkele personen te vervoeren. In 2019 zaten er gemiddeld 1,37 mensen in 1 auto in het woon-werkverkeer, dit terwijl een auto vaak 2 tot 5 personen kan vervoeren^[verkeerskunde.nl, 2023]. Doordat men in grotere voertuigen rijden leidt dit tot meer drukte op de weg en dus minder files.
|
||||
Het probleem is dat er onzekerheden zijn over het voertuig en dat de SPC niet correct ontwikkeld is om te valideren. Hierdoor is het moeilijk om aan te tonen of de functionaliteit voldoet aan de gestelde eisen en of de subsystemen daadwerkelijk bruikbaar zijn in de praktijk.
|
||||
|
||||
### De Voorgestelde Oplossing
|
||||
### Doelstelling
|
||||
|
||||
De Superlight Personal Carrier is een lichtgewicht één persoonsvoertuig. Dit voertuig is veel kleiner dan andere auto's en neemt dus minder ruimte in op de weg. Dit resulteert in meer voertuigen per uur over dezelfde weg kunnen.
|
||||
Het doel van het project is om de functionaliteit van de SPC te verbeteren door een functionele aandrijving en een stuurmechanisme te ontwerpen die praktisch toepasbaar zijn in het fysieke voertuig. Deze systemen zullen worden ontworpen en geoptimaliseerd met behulp van data uit een Digital Twin, die als leidraad dient voor het gehele ontwikkelingsproces. Daarnaast zal het stabilisatiesysteem verder ontwikkeld worden, met als uiteindelijk doel een full- scale implementatie in het voertuig.
|
||||
|
||||
### Oplossing van onze voorgangers
|
||||
### Vraagstelling
|
||||
|
||||
Er is al een concept voor een twee wiel voertuig ontworpen een deels gefabriceerd. Deze heeft de een elektro motor in elk van de wielen. Het stuur mechanisme wordt elektrische aangestuurd. De bestuurder kan dus met een joystick alles aansturen. Het idee is om het semiautomatsche rijdend te maken. Het voertuig wordt rechtgehouden door een reactie wiel.
|
||||
#### Hoofdvraag
|
||||
|
||||
### Betrokken partijen
|
||||
"Hoe ziet een functioneel en valideer baar aandrijf- en stuursysteem voor de SPC eruit, waarbij stabilisatie is geïntegreerd in het ontwerp en gebruik wordt gemaakt van een digital twin voor ontwikkeling, optimalisatie en validatie?"
|
||||
|
||||
| Functie | Naam | opleining | Email |
|
||||
|-------------------|---------------------|------------|------------------|
|
||||
| Opdracht gever | Niels van Groningen | Automotive | ...@hr.nl |
|
||||
| Docentbegeleider | Joris Straver | ELE | j.g.Straver@hr.nl|
|
||||
| Project lid | Max Kappert | Automotive | 1030682@hr.nl |
|
||||
| Project lid | Tijn Snijders | Automotive | 1001829@hr.nl |
|
||||
| Project lid | Chris Tan | ELE | 0992143@hr.nl |
|
||||
| Project lid | Gryvon Belfor | ELE | 0985890@hr.nl |
|
||||
| Project lid | Mohamed El Morabiti | ELE | 1014780@hr.nl |
|
||||
| Project lid | Finley van Reenen | ELE | 0964590@hr.nl |
|
||||
#### Deelvragen
|
||||
|
||||
## Projectresultaat
|
||||
1. **Huidige situatie & knelpunten**
|
||||
- Wat is de huidige status van de SPC en welke onzekerheden bestaan er in het huidige ontwerp?
|
||||
- Welke technische beperkingen belemmeren de validatie van de SPC?
|
||||
2. **Ontwerp en validatie van het aandrijf- en stuursysteem**
|
||||
- Welke ontwerpcriteria moeten worden gehanteerd voor een functionele en bruikbare aandrijving?
|
||||
- Hoe kan een stuurmechanisme worden ontworpen dat werkt zonder een traditioneel stuur?
|
||||
- Welke methoden kunnen worden gebruikt om de werking van deze systemen te valideren?
|
||||
3. **Gebruik van een Digital** **Twin**
|
||||
- Hoe kan een digital twin bijdragen aan de ontwikkeling en validatie van de aandrijving en het stuurmechanisme?
|
||||
- Welke parameters en data zijn nodig om een betrouwbare digital twin op te stellen?
|
||||
4. **Stabilisatie en implementatie**
|
||||
- Hoe kan het stabilisatiesysteem verder worden ontwikkeld en geoptimaliseerd?
|
||||
- Op welke manier kan een full-scale implementatie van de SPC worden gerealiseerd?
|
||||
5. **Kwaliteitsborging en testen**
|
||||
- Hoe kan de functionaliteit van het systeem worden gekwantificeerd en geëvalueerd?
|
||||
- Welke testmethoden kunnen worden gebruikt om de prestaties van de SPC te meten en te valideren?
|
||||
|
||||
## Doelstelling
|
||||
### Current State
|
||||
|
||||
- Er wordt een Digital Twin gemaakt om te kunnen berekenen wat er nodig is om de de eisen te halen.
|
||||
- Het reactiewiel om het voertuig te stabaliseren verder ontwikkeld zodat deze in het voertuig geplaatst kan worden.
|
||||
- Het stuur mechnisme wordt gerepareerd en bedienbaar gemaakt met een joystick.
|
||||
- Het mechanisme voor de wielaandrijving, en als het binnen de tijd lukt wordt deze ook bedienbaar gemaakt met de joystick.
|
||||
In de vorige projectfasen is een prototype ontwikkeld van de **Superlight Personal Carrier (SPC)**, waarin verschillende technologieën en subsystemen zijn getest. Op dit moment bestaat de SPC uit:
|
||||
|
||||
## De opdracht
|
||||
- Een testframe waarop componenten kunnen worden gemonteerd en geëvalueerd.
|
||||
- Een op schaal geteste opstelling met een reactiewiel om de stabilisatie te behouden.
|
||||
- Een ruwe simulatie met geschatte parameters voor de aandrijving en het stuursysteem.
|
||||
|
||||
In dit project wordt the stuursysteem herontworpen, een digital twin en het reactiewiel voor sabilisatie gemaakt.
|
||||
#### Huidige status van het aandrijfsysteem
|
||||
|
||||
### stuursysteem
|
||||
##### Motor en aandrijving
|
||||
|
||||
De vorige groep heeft geconstateerd dat er gebrekken zijn aan het huidige mechanisme voor het stuuren. Om deze gebrekken te verbeteren moet het systeem opnieuw optworpen en gefabriseerd worden.
|
||||
Het huidige ontwerp maakt gebruik van een elektromotor met een geplande accupakketcapaciteit van 20,4 kWh, wat resulteert in een geschat gewicht van 94 kg (gewicht per cel \* benodigde cellen).
|
||||
|
||||
Wij gaat dit systeem herontwerpen zodat de volgende groep zich kan focusen op de aandrijving van de wielen.
|
||||
Er is nog geen definitieve keuze gemaakt tussen directe aandrijving (zoals een naafmotor) en een indirecte aandrijving (zoals een centrale motor met riem- of kettingoverbrenging).
|
||||
|
||||
### digital twin
|
||||
De huidige aandrijving is nog niet geïntegreerd met het stuursysteem, waardoor het effect op rijgedrag en stabiliteit onbekend is.
|
||||
|
||||
Om goed in beeld te krijgen wat er nodig is om het de snelheid en actieradius doelen te behalen, wordt er een ditital twin gamaakt. Deze word zo gamaakt zodat de keuze voor aandrijving en andere keuzes die nog niet vast staan eenvouding aan te passen zijn.
|
||||
##### Simulatie en validatie
|
||||
|
||||
### reactiewiel
|
||||
De stabilisatie is op kleine schaal getest, maar is nog niet gevalideerd in combinatie met de aandrijving op het testframe.
|
||||
|
||||
Het reactiewiel is n tot nu toe alleen getest in schaal. Wij gaat dit schaal model vertalen naar de 1:1 versie en indien er voldoende budget is wordt deze ook geinstaleerd in het frame.
|
||||
De huidige simulaties zijn gebaseerd op geschatte parameters en vereisen een nauwkeurigere data-invoer om realistische testresultaten te kunnen leveren.
|
||||
|
||||
### afbakeningen
|
||||
##### Uitdagingen en knelpunten
|
||||
|
||||
Wij hebben niet als doel om alle eisen de behalen. Er wordt een platform gebouwd waar mee bij vervolg projecten deze eisen wel te behalen zijn.
|
||||
Het accupakket is relatief zwaar, wat invloed heeft op de prestaties en balans van de SPC.
|
||||
|
||||
Er wordt niet gewerkt aan het wiel aandrijf systeem, accu's, chacie (maar dan goed geschreven), of andere systeemen die niet temaken hebben met de drie eerder genoemde onderdelen waar wel aangewerkt worden.
|
||||
Er is nog onduidelijkheid over de samenwerking tussen aandrijving en besturing, waardoor het risico op bumpsteer en vermogensverlies bestaat.
|
||||
|
||||
## Het projectresultaat
|
||||
Er is nog geen uitgebreid testprotocol ontwikkeld om de prestaties van de aandrijving systematisch te valideren.
|
||||
|
||||
### Projectactiviteiten
|
||||
De huidige status van het project vormt de basis voor verdere ontwikkelingen. De volgende stappen zijn gericht op het verder ontwikkelen van het aandrijf- en stuursysteem en de stabilisatie, zodat er een rijdend 2x2x2 voertuig gerealiseerd wordt.
|
||||
|
||||
### Projectgrenzen
|
||||
|
||||
|
||||
|
||||
## Scope & Afbakening
|
||||
|
||||
### Scope
|
||||
|
||||
De scope van een project bepaald wat er wel en niet behandeld gaat worden. Een scope wordt op meerdere aspecten gesteld. De aspecten waar onze scope over gaat zijn hieronder neergezet.
|
||||
Dit project richt zich op het ontwikkelen van functionele kernsystemen voor het voertuig, waarbij de nadruk ligt op de **aandrijving, de Digital Twin, het stuurmechanisme en de stabilisatie**.
|
||||
|
||||
#### Aandrijving en Stuursysteem
|
||||
|
||||
Een nieuw stuursysteem en doorgerekende aandrijving zijn nodig voor basis functionaliteit van het voertuig. Deze systemen moeten aan de hand van de Digital Twin ontworpen worden. Het doel licht hierop bij goed ontwerp en onderbouwing. Het is daarom essentieel dat er goed nagedacht wordt over de nodige veiligheidsfactoren en limieten van componenten.
|
||||
|
||||
#### Digital Twin
|
||||
|
||||
Wij willen aan de hand van een Digital Twin andere subsystemen op het voertuig kunnen ontwerpen, valideren en optimaliseren. Deze gegevens moeten dus de rode draad vormen voor het gehele project.
|
||||
|
||||
|
||||
|
||||
#### Stabilisatie
|
||||
|
||||
Het doel van het project is om het voertuig te kunnen laten stabiliseren. Dit stabiliseren zal op het full scale voertuig gaan plaats vinden. Dit systeem moet werken door middel van het correctiewiel wat op de schaal testopstelling gedemonstreerd is te werken. Het is nu de taak om dit op full scale werkend te krijgen.
|
||||
|
||||
#### Afbakening
|
||||
|
||||
- Het project richt zich primair op **functionele en fysiek implementeerbare systemen**, niet op aerodynamische optimalisatie of esthetische aspecten van het voertuig.
|
||||
- Autonome functies vallen buiten de scope van dit project.
|
||||
|
||||
## Tussenresultaten
|
||||
|
||||
> TODO: nog een leuk intro praatje toevoegen
|
||||
|
||||
### Analyse fase
|
||||
|
||||
In de analyse fase worden de volgende documenten opgesteld:
|
||||
|
||||
- **Plan van Aanpak**
|
||||
Dit document.
|
||||
- **Plan van Aanpak**: Dit document.
|
||||
- **Risico analyse**: Hier worden alle risico’s beschreven en wat we doen om de risico’s te verminderen.
|
||||
- **Pakket van eisen**: Hier worden alle eisen waar het product aan moet gaan voldoen
|
||||
- **Globale planning**: Zie hoofdstuk [Planning](#planning).
|
||||
- **Functioneel prototype?**: Een prototype om te controleren of het concept mogelijk en realistisch is.
|
||||
|
||||
- **Risico analyse**
|
||||
Hier worden alle risico's beschreven en wat we doen om de risico's te verminderen.
|
||||
### Concept fase
|
||||
|
||||
- **Pakket van eisen**
|
||||
Hier worden alle eisen waar het product aan moet gaan voldoen
|
||||
- Persoonlijk PVA
|
||||
- Het ontwerp van het product
|
||||
- Bom (Bill of Materials)
|
||||
|
||||
- **Globale planning**
|
||||
Zie hoofdstuk [Planning](#Planning).
|
||||
### Ontwerpfase
|
||||
|
||||
- **Functioneel prototype?**
|
||||
Een prototype om te controleren of het concept mogelijk en realistisch is.
|
||||
- Testprocedures
|
||||
- Het ontwerp van het product
|
||||
- Bom (Bill of Materials)
|
||||
|
||||
### Ontwerp fase
|
||||
#### Test Fase
|
||||
|
||||
- testprocedures
|
||||
- het ontwerp van het product
|
||||
- bom
|
||||
- Test rapporten
|
||||
|
||||
### test fase
|
||||
## Methodologische aanpak
|
||||
|
||||
- test raporten
|
||||
### DMADV-model
|
||||
|
||||
## Kwaliteit
|
||||
In dit hoofdstuk wordt besproken over de aanpak van de opdracht en welke methode gevolgd zal worden tijdens het semester. Dit zal gedaan worden door middel van het DMADV-model. Dat staat voor Define, Measure, Analyze, Design en Verify.
|
||||
|
||||
De kwalitijd wordt continu getest, dit word gedaan volgende de Scrum methodiek. Er worden sprintd van twee weken gedaan.
|
||||
|
||||
|
||||
#### Define
|
||||
|
||||
De eerste fase in het dmadv model is definiëren. Het is essentieel om vooraf een lijst te hebben van de taken die gedaan moeten worden en de onderdelen die gemaakt moeten worden. Als je in het begin goed hebt gedefinieerd wat en hoe het gedaan moet worden zal het makkelijker worden om naar het gewenste resultaat toe te werken. De onderdelen die zullen worden ontwikkeld en geïmplementeerd zijn de aandrijving en de sturing. Een eis is dat het voertuig in-wheel motoren moet hebben, hiervoor zal er extra aandacht aan gegeven moeten worden vanwege de complexiteit van dit onderwerp.
|
||||
|
||||
#### Measure
|
||||
|
||||
In de fase van measure verzamel en neem je de gegevens op die relevant zijn voor de CTQ-maatregelen die tijdens de eerste fase werden gedefinieerd. Deze gegevens meet je om resultaten te verkrijgen waarmee later in het proces
|
||||
|
||||
In die tabel wordt de VOC (voice of customer) genoteerd en bij punten daarvan wordt onder het kopje van drijfveer de technische of functionele kenmerken beschreven die nodig zijn om de wensen van de klant te behalen. Bij de CTQ rij wordt weergegeven wat de fysieke onderdelen zijn om die drijfveren te behalen.
|
||||
|
||||
De CTQ’s die uit de View of Client en View of Business zijn gehaald die voor dit onderzoek belangrijk zijn, zijn hieronder in tabelvorm genoteerd.
|
||||
|
||||
|
||||
|
||||
De eisen opgesteld vanuit de opdrachtgever (klant) zijn als volgt:
|
||||
|
||||
- Het voertuig is elektrisch aangedreven
|
||||
- Het voertuig is zelf stabiliserend
|
||||
- Het voertuig is voor het vervoeren van 1 persoon
|
||||
|
||||
Het voertuig heeft een 2x2x2 aandrijving (2 wielen, 2 wiel gestuurd, 2 wiel aangedreven)
|
||||
|
||||
De laatste twee punten zijn eisen die van toepassing zijn op het uiteindelijke eindproduct. Dat is iets wat in de tijdsduur van dit project niet behaald zal worden. Daarom zijn die punten niet een prioriteit voor dit projectteam.
|
||||
|
||||
#### Analyze
|
||||
|
||||
In de fase van analyse worden alle verzamelde data uit de meetfase gebruikt om te analyseren en testen uit te voeren van de verschillende concepten die zijn opgesteld voor onderdelen en systemen. Die onderdelen wordt verder op gerekend en geoptimaliseerd voor hun functie en de gestelde eisen. Die eisen komen vanuit het pakket van eisen wat wordt gebruikt als referentie om ervoor te zorgen dat de onderdelen zich voldoen aan de gestelde randvoorwaarden.
|
||||
|
||||
Uit deze fase kan dan ook een ruw concept komen wat voldoet aan functionele eisen en aan de eerder gestelde CTQ's.
|
||||
|
||||
#### Design
|
||||
|
||||
In de fase van design worden alle gegevens uit eerdere fasen gebruikt zodat er een product ontwikkeld kan worden wat dichter bij het definitieve eindproduct komt. Daaruit kunnen mogelijke aanpassingen en wijzigingen worden gemaakt uit fouten die worden geïdentificeerd en kan het aan de klant worden laten zien, wat zal voldoen aan hun eisen en weer mogelijk kan worden aangepast waar nodig is.
|
||||
|
||||
#### Verify
|
||||
|
||||
De verificatiefase van het DMADV-model is weliswaar de laatste fase, maar niet het einde van het proces. Om de kwaliteit te waarborgen is het belangrijk om, continue te verifiëren en het product aanpassen waar dat dan nodig is. In deze fase zal het ontwerp dan ook definitief klaar zijn en kan er feedback worden gekregen van de klant waarmee mogelijke aanpassingen kunnen worden gemaakt die weer kunnen worden verifieerd.
|
||||
|
||||
## Organisatiestructuur (OBS, PBS, WBS)
|
||||
|
||||
### Organisatie leden
|
||||
|
||||
| Functie | Naam | Opleiding | Email |
|
||||
| --- | --- | --- | --- |
|
||||
| Opdrachtgever | Niels van Groningen | Automotive | <N.van.groningen@hr.nl> |
|
||||
| Docentbegeleider | Joris Straver | ELE | <J.g.Straver@hr.nl> |
|
||||
| Project lid | Max Kappert | Automotive | <1030682@hr.nl> |
|
||||
| Project lid | Tijn Snijders | Automotive | <1001829@hr.nl> |
|
||||
| Project lid | Thomas Braam | Automotive | <0989527@hr.nl> |
|
||||
| Project lid | Chris Tan | ELE | <0992143@hr.nl> |
|
||||
| Project lid | Gryvon Belfor | ELE | <0985890@hr.nl> |
|
||||
| Project lid | Mohamed El Morabiti | ELE | <1014780@hr.nl> |
|
||||
| Project lid | Finley van Reenen | ELE | [0964590@hr.nl](mailto:0964590@hr.nl) |
|
||||
|
||||
### OBS (Organization Breakdown Structure)
|
||||
|
||||
|
||||
|
||||
### PBS (Product Breakdown Structure)
|
||||
|
||||
|
||||
|
||||
### WBS (Work Breakdown Structure)
|
||||
|
||||
|
||||
|
||||
## Risico- en stakeholder analyse
|
||||
|
||||
### Risico’s
|
||||
|
||||
Het Superlight Personal Carrier (SPC) project brengt studenten uit verschillende opleidingen samen, waaronder Automotive en Elektrotechniek. Dit interdisciplinaire karakter biedt kansen, maar brengt ook risico's met zich mee, vooral op het gebied van planning, communicatie en technische realisatie. In deze risicoanalyse worden de belangrijkste bedreigingen geïdentificeerd en mogelijke beheersmaatregelen besproken.
|
||||
|
||||
#### Communicatieproblemen
|
||||
|
||||
Doordat studenten uit verschillende opleidingen samenwerken, kunnen er communicatieproblemen ontstaan. Elk teamlid heeft een andere achtergrond, werkwijze en planning. Hierdoor kunnen misverstanden ontstaan over verwachtingen, deadlines en verantwoordelijkheden. Dit kan leiden tot vertragingen, inefficiënte samenwerking en fouten in het ontwerp of de uitvoering van het project.
|
||||
|
||||
##### Maatregelen
|
||||
|
||||
- Regelmatige vergaderingen inplannen om voortgang en knelpunten te bespreken.
|
||||
- Duidelijke communicatiekanalen en documentatie opzetten, zoals een gedeeld projectplan of online platform.
|
||||
- Taken en verantwoordelijkheden expliciet vastleggen, zodat iedereen weet wat er van hen verwacht wordt.
|
||||
|
||||
#### Verschillende planningen en beschikbaarheid
|
||||
|
||||
Studenten van verschillende opleidingen hebben verschillende lesroosters, deadlines en toets momenten. Dit kan ertoe leiden dat sommige teamleden minder beschikbaar zijn of moeilijker in te plannen zijn voor gezamenlijke werkzaamheden. Bovendien kunnen studenten vakken moeten herkansen, wat hun inzetbaarheid verder vermindert.
|
||||
|
||||
##### Maatregelen
|
||||
|
||||
- Een flexibele maar realistische projectplanning maken die rekening houdt met toets weken en herkansingen.
|
||||
- Taken verdelen op basis van beschikbaarheid, zodat het project niet stilvalt bij de afwezigheid van een teamlid.
|
||||
- Alternatieve communicatiemiddelen gebruiken, zoals online vergaderingen en asynchrone updates.
|
||||
|
||||
#### Te veel hooi op de vork nemen
|
||||
|
||||
Binnen het project kan de neiging ontstaan om te veel taken op je te nemen. Dit verhoogt de werkdruk en kan ertoe leiden dat taken niet goed worden uitgevoerd of deadlines niet worden gehaald. Hierdoor kunnen cruciale onderdelen van het project mislukken of niet naar behoren functioneren.
|
||||
|
||||
##### Maatregelen
|
||||
|
||||
- Duidelijke taakverdeling maken en monitoren of de werklast eerlijk is verdeeld.
|
||||
- Wekelijkse statusupdates organiseren om eventuele overbelasting te signaleren.
|
||||
- Teamleden stimuleren om tijdig hulp te vragen als ze vastlopen.
|
||||
|
||||
#### Studenten stoppen of komen niet opdagen
|
||||
|
||||
Een ander risico is dat studenten uitvallen, stoppen met het project of hun taken niet afmaken. Dit kan grote impact hebben op de voortgang en de verdeling van verantwoordelijkheden binnen het team.
|
||||
|
||||
##### Maatregelen
|
||||
|
||||
- Vanaf de start duidelijke afspraken maken over commitment en inzet.
|
||||
- Een back-up plan opstellen voor cruciale taken, zodat het project door kan gaan bij onverwachte uitval.
|
||||
- Vroegtijdig signaleren wanneer een teamlid minder betrokken raakt en hier proactief op inspelen.
|
||||
|
||||
#### Realisatie kan fout gaan
|
||||
|
||||
Tijdens de realisatie van het project kunnen technische problemen ontstaan, zoals fouten in de hardware of software, compatibiliteitsproblemen en onvoorziene storingen. Dit kan ertoe leiden dat onderdelen niet correct werken of dat het eindproduct niet aan de gestelde eisen voldoet.
|
||||
|
||||
##### Maatregelen
|
||||
|
||||
- Duidelijke technische specificaties opstellen en testen in verschillende fasen.
|
||||
- Gebruik maken van bestaande en bewezen technologieën waar mogelijk.
|
||||
- Regelmatig overleg tussen teamleden om technische obstakels snel te identificeren en op te lossen.
|
||||
|
||||
#### Unittesten en integratietesten
|
||||
|
||||
Een belangrijk onderdeel van het project is het testen van afzonderlijke componenten (unittesten) en het integreren van deze componenten in een werkend geheel (integratietesten). Zonder gedegen teststrategie kunnen fouten pas laat in het proces worden ontdekt, wat tot vertraging en herwerk leidt.
|
||||
|
||||
##### Maatregelen
|
||||
|
||||
- Een gestructureerd testplan opstellen en uitvoeren in verschillende ontwikkelingsfasen.
|
||||
- Automatische en handmatige testen toepassen om betrouwbaarheid te garanderen.
|
||||
- Problemen documenteren en direct oplossen om verdere complicaties te voorkomen.
|
||||
|
||||
#### Conclusie
|
||||
|
||||
Om het SPC-project succesvol af te ronden, is een goede planning, communicatie en technische aanpak essentieel. Door risico’s tijdig te identificeren en maatregelen te nemen, kan het team effectiever samenwerken en problemen minimaliseren. Duidelijke afspraken, regelmatige evaluaties, een evenwichtige taakverdeling en een gestructureerd testplan zijn cruciaal om de uitdagingen binnen dit interdisciplinaire project te overwinnen en een succesvol eindresultaat te garanderen.
|
||||
|
||||
### Risico matrix
|
||||
|
||||
|
||||
|
||||
### Stakeholder analyse
|
||||
|
||||
Hierin wordt een analyse gemaakt over de rollen, invloed en belangen van de verschillende belanghebbenden in dit project. Dit helpt om communicatie en samenwerking te verbeteren en eventuele conflicten te voorkomen.
|
||||
|
||||
Hieronder zijn de volgende partijen die invloed hebben op dit project bekend:
|
||||
|
||||
- Projectteemleden:
|
||||
- Gryvon Belfor
|
||||
- Tijn Snijders
|
||||
- Thomas Braam
|
||||
- Max Kappert
|
||||
- Finley van Reenen
|
||||
- Mohamed El Morabiti
|
||||
- Chris Tan
|
||||
- Begeleiders (school):
|
||||
- Niels van Groningen
|
||||
- Joris Straver
|
||||
- Eindgebruiker/klant:
|
||||
- Niels van Groningen
|
||||
|
||||
Het belang en invloed wordt in dit tabel weergeven:
|
||||
|
||||
| Stakeholder | Belang | Invloed |
|
||||
| --- | --- | --- |
|
||||
| Projectteamleden | Verder ontwikkelen van de SPC naar validatie | Hoog |
|
||||
| Begeleiders (school) | Begeleiden van kwaliteit en validiteit van het eindproduct | Gemiddeld |
|
||||
| Eindgebruiker/klant | Een gebruiksklaar product voor eventuele vervolgproject | Hoog |
|
||||
|
||||
### RACI-model
|
||||
|
||||
De letters van het RACI-model staan voor rollen van de leden in een proces, namelijk:
|
||||
|
||||
R – Responsible (Verantwoordelijk): degene die de taak uitvoert is verantwoordelijk voor de uitvoering hiervan.
|
||||
|
||||
A – Accountable (Eindverantwoordelijk): deze persoon draagt de uiteindelijke eindverantwoording voor de juiste voltooiing van een of meerdere projecttaken.
|
||||
|
||||
C – Consulted (Geraadpleegd): dit is de persoon aan wie vooraf advies gevraagd wordt.
|
||||
|
||||
I – Informed (Geïnformeerd): deze persoon wordt tussentijds geïnformeerd over de beslissingen, over de voortgang, bereikte resultaten enz.
|
||||
|
||||
| | Projectleider Tijn | Max | Thomas | Gryvon | Chris | Projectleider Finley | Mohammed | Van Groningen |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| Projectplanning | R | I | I | I | I | I | I | |
|
||||
| PVE | I | I | I | I | R | A/R | I | C |
|
||||
| Sponsering | A | R | I | I | I | I | I | I |
|
||||
| Stuursysteem | I | A/R | I | I | R | I | I | C/I |
|
||||
| Aandrijving | I | I | I | A/R | I | I | R | C/I |
|
||||
| Stabilisatie | A/R | I | I | I | I | R | I | C/I |
|
||||
| Sim model | C/I | C/I | A/R | I | I | I | I | C |
|
||||
| Concept ontwikkelen | R | R | R | R | R | R | R | C/I |
|
||||
| Begroting & kosten | A | C | C | C | R | C | C | C/I |
|
||||
|
||||
## Planning
|
||||
|
||||
Er worden twee niveaus aan van planningen gemaakt: globale planning en een detail planning. De globale planning worden de grotere lijnen van het project geplant. Het doel is om te zorgen dat de hele groep weet wanneer andere onderdelen klaar zijn om de onderdelen met elkaar te kunnen testen.
|
||||
### Tussenresultaten
|
||||
|
||||
De detailplanning is voor het plannen van deze onderdelen. Elk onderdeel zal een beperkt aantal ingenieurs aan werken, deze ingenieurs houden zelf deze planning bij.
|
||||
Het project wordt op gedeeld in verschillende sprints
|
||||
|
||||
Elke week komt de groep samen op donderdag om de planningen door te nemen en waar nodig aanpassingen maken.
|
||||
#### Analyse fase
|
||||
|
||||
De globale planning is te vinden in de [bijlagen](#Globale-Planning).
|
||||
In de analyse fase worden de volgende documenten opgesteld:
|
||||
|
||||
## Kosten en baten
|
||||
- **Plan van Aanpak**
|
||||
Dit document.
|
||||
- **Risico analyse**
|
||||
Hier worden alle risico’s beschreven en wat we doen om de risico’s te verminderen.
|
||||
- **Pakket van eisen**
|
||||
Hier worden alle eisen waar het product aan moet gaan voldoen
|
||||
- **Globale planning**
|
||||
Zie hoofdstuk [Planning](#planning).
|
||||
- **Functioneel prototype?**
|
||||
Een prototype om te controleren of het concept mogelijk en realistisch is.
|
||||
|
||||
kosten: voor dit project is het budget nog onbekend.
|
||||
baten: omdat het budget nog onbekend is, is het moeijlijk te bepalen wat de baten voor het budget zijn.
|
||||
#### Ontwerpfase
|
||||
|
||||
## Risico’s
|
||||
- Testprocedures
|
||||
- Het ontwerp van het product
|
||||
- Bom (Bill of Materials)
|
||||
|
||||
in dit onderdeel worden de risico's uitgelegd. in de uitleg worden de risico's gedeeld in interne en externe risico's.
|
||||
Interne Risico's:
|
||||
#### Test fase
|
||||
|
||||
- communicatie en tijden afspreken
|
||||
- te kort aan kennis
|
||||
- onbekend budget
|
||||
- niet behaalde deadlines
|
||||
- Test rapporten
|
||||
|
||||
externe risico's:
|
||||
### Value planning
|
||||
|
||||
- componenten niet meer op voorraad
|
||||
- lange levertijden
|
||||
- werkzaamheden buiten de scope van het project uitvoeren
|
||||
|
||||
|
||||
In de bijlagen is een tabel van een risicoanalyse te vinden.
|
||||
### Dynamische planning
|
||||
|
||||
## Bijlage
|
||||
Deze planning geeft een overzicht van de verschillende fasen en bijbehorende taken binnen dit project. Door middel van een Gantt-diagram worden de doorlooptijden, afhankelijkheden en mijlpalen visueel weergegeven. De planning is opgedeeld in meerdere sprints, waaronder **Sprint Analyseren**, **Sprint Realiseren**, **Sprint Optimaliseren**, en **Sprint Valideren**, waarmee het project stapsgewijs wordt ontwikkeld en geoptimaliseerd.
|
||||
|
||||
### Globale Planning
|
||||
De blauwe balken geven de duur van elke taak aan, terwijl de diamantvormige symbolen belangrijke mijlpalen markeren. De rode verticale lijn geeft de huidige voortgang weer. Dit overzicht helpt bij het bewaken van deadlines, het coördineren van werkzaamheden en het tijdig bijsturen van het project waar nodig
|
||||
|
||||
waro?
|
||||
|
||||
### Risico analyse
|
||||
|
||||
|
||||
waro?
|
||||
## Begroting
|
||||
|
||||
Het project moet uiteindelijk een rijdend en zelf stabiliserend voertuig produceren, het moet op 2 wielen rijden en bestuurd worden d.m.v. vehicle control unit (een joystick of een controller). We baseren de prijzen op de keuzes die gemaakt zijn door het vorige projectteam en een vooronderzoek dat is gedaan. Voor de wielmotoren hebben een 8kW nodig om de originele eisen van 150km/u te behalen, daarbij komt ook een batterijpakket bij kijken die minimaal 120V en 280Ah moet zijn. Voor het stabilisatie systeem hebben we ook hoogstwaarschijnlijk een motor met veel koppel nodig. Om de drive by wire besturing te kunnen implementeren hebben we 2 actuatoren nodig, één voor en één achter. Daarnaast hebben we een vehicle control unit nodig om het voertuig te besturen.
|
||||
|
||||
Kosten: voor dit project is het budget nog onbekend.
|
||||
|
||||
Baten: omdat het budget nog onbekend is, is het moeilijk te bepalen wat de baten voor het budget zijn.
|
||||
|
||||
De volgende tabel geeft een schatting van het benodigde budget:
|
||||
|
||||
| Item | Begroting |
|
||||
| --- | --- |
|
||||
| 2x Wielmotor | 1000-1500 |
|
||||
| Stabilisatie motor | 500-600 |
|
||||
| Banden | 100-150 |
|
||||
| Actuatoren | 400-500 |
|
||||
| Wielen | 200-300 |
|
||||
| 2x Encoders | 100-150 |
|
||||
| Vehicle control unit | 50-80 |
|
||||
| Motor controller | 100-150 |
|
||||
| Batterijpakket | 900 |
|
||||
| Frame | ??? |
|
||||
| Remmen | 200-300 |
|
||||
|
||||
## Pakket van Eisen (PvE)
|
||||
|
||||
Het volgende PVE is opgesteld in een apart document.
|
||||
|
||||
## Voertuig Validatie
|
||||
|
||||
Na de realisatie en optimalisatie van het voertuig, zal er een grondige validatie plaats vinden. De validatie zal bestaan uit verschillende hoofd criteria. Die uit geleid zijn van uit het pakket van eisen. Deze hoofd criteria zijn statische dynamische en integratie validatie testen.
|
||||
|
||||
### Statische validatie
|
||||
|
||||
|
||||
Tijdens de statische validatie zal het voertuig gevalideerd worden op de statische parameters van uit het pakket van eisen. Dit zal gebeuren door een
|
||||
|
||||
- Voertuig gewicht validatie (<250 kg ex persoon) (REQ-A-1[MH] in PvE)
|
||||
- Afmetingen (REQ-A-2[MH], REQ-A-3[MH], REQ-A-10[SH], REQ-A-11[MH] en REQ-A-12[SH] in PvE)
|
||||
|
||||
### Dynamische validatie
|
||||
|
||||
- Aandrijving (REQ-W-4[MH] in PvE)
|
||||
- Draaicirkel (REQ-W-8[MH] in PvE)
|
||||
- Stabilisatie tot hellingshoek 5 graden
|
||||
|
||||
|
||||
### Integratie validatie
|
||||
|
||||
Een volledig rollend sturen d stabiliserend voertuig test. (REQ-S-1[MH], REQ-W-2[MH] en REQ-W-3[SH] in PvE)
|
||||
|
||||
14
markdown/projectdocument.md
Normal file
14
markdown/projectdocument.md
Normal file
@ -0,0 +1,14 @@
|
||||
|
||||
# Superlight Persian Carier (SPC)
|
||||
|
||||
##
|
||||
|
||||
## bijlagen
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
152
markdown/testen_sabilisatie.md
Normal file
152
markdown/testen_sabilisatie.md
Normal file
@ -0,0 +1,152 @@
|
||||
## Unit Testen Atabilisatie
|
||||
|
||||
### voedingen
|
||||
|
||||
#### benodigdheden
|
||||
|
||||
- 12V voeding
|
||||
|
||||
#### procedure
|
||||
|
||||
1. snel de voeding in op 12V met een stroom berensing van 50 mA
|
||||
2. sluit de 12V voeding aan op de 12V en GND ingnangen op de driver
|
||||
3. meet de uitgangen van de twee voedingen, vul de tabel hieronder in
|
||||
|
||||
| | $5V$ | $12V$ |
|
||||
| -------- | ------:| -------:|
|
||||
| minimaal | $4.5V$ | $11.5V$ |
|
||||
| maximaal | $5.5V$ | $12.5V$ |
|
||||
| gemeeten | | |
|
||||
|
||||
Geslaagd:
|
||||
|
||||
opmergingen:
|
||||
|
||||
### microcontroller
|
||||
|
||||
#### benodigdheden
|
||||
|
||||
- 12V voeding als de voedingen werken, anders met een 5V en 3.3v voeding
|
||||
- computer met Arduino IDE geinstaleerd
|
||||
- USB B kabel naar de computer
|
||||
- ledje met bijhoren de weerstand voor 3.3V
|
||||
|
||||
#### procedure
|
||||
|
||||
1. sluit een ledje aan op een van de GPIO pinnen
|
||||
2. snel de voeding in op 12V met een stroom berensing van 150 mA
|
||||
3. sluit de 12V voeding aan op de 12V en GND ingnangen op de driver
|
||||
4. sluit de USB kabel aan op de computer (dit is veilig omdat de USB alleen verbonden is met ground, de V+ is floating)
|
||||
5. upload een blinky voorbeeld progamma met de GPIO ingesteld van de led
|
||||
6. bekijk of het lidje knipperd
|
||||
|
||||
Geslaagd:
|
||||
|
||||
opmergingen:
|
||||
|
||||
### half brug
|
||||
|
||||
#### benodigdheden
|
||||
|
||||
- als de microcontoller werkt:
|
||||
- 12V voeding als de voedingen werken, anders met een 5V en 3.3v voeding
|
||||
- 30V voor V Motor
|
||||
- computer met Arduino IDE geinstaleerd
|
||||
- USB B kabel naar de computer
|
||||
- ocsiloscoop
|
||||
- zo niet:
|
||||
- 10V voor V motor
|
||||
- signaal generator met twee kanalen
|
||||
- ocsioscoop
|
||||
|
||||
#### procedure
|
||||
|
||||
1. sluit de ociloscoop aan op een van de uitgangen van de drijver (er komt 30V op te staan, beruik de juiste probe; geen juiste probe bij de hand, zelt de voeding voor V motor wa lager)
|
||||
2. snel de voeding in op 12V met een stroom berensing van 150 mA
|
||||
3. sluit de 12V voeding aan op de 12V en GND ingnangen op de driver
|
||||
4. sluit de USB kabel aan op de computer (dit is veilig omdat de USB alleen verbonden is met ground, de V+ is floating)
|
||||
5. upload een test progamma die de PWM aansuurt voor de FET's
|
||||
- de PWM per half bridge zijn aangesloten op de a en b uitganen van 1 timer per half brug. zorg dat een van de uitput geinverteerd is en de twee vergeleijk waardes zo zijn zodat er een korte dead time is. ze mogen nooit tegerlijk hoog zijn!
|
||||
6. bekijk het signaal op de osciloscoop
|
||||
7. herhaal de test voor alle drie de half bruggen
|
||||
|
||||
resultaat:
|
||||
|
||||
- brug a:
|
||||
- brug b:
|
||||
- brug c:
|
||||
|
||||
opmerkingen:
|
||||
|
||||
### IMU
|
||||
|
||||
#### benodigdheden
|
||||
|
||||
- een microcontroller met I2C (kan de motoro driver zelf zijn)
|
||||
- computer met Arduino IDE geinstaleerd
|
||||
- USB B kabel naar de computer
|
||||
|
||||
#### procedure
|
||||
|
||||
1. sluit de IMU aan op de motor driver
|
||||
2. snel de voeding in op 12V met een stroom berensing van 150 mA
|
||||
3. sluit de 12V voeding aan op de 12V en GND ingnangen op de driver
|
||||
4. sluit de USB kabel aan op de computer (dit is veilig omdat de USB alleen verbonden is met ground, de V+ is floating)
|
||||
5. upload een blinky voorbeeld progamma met de GPIO ingesteld van de led
|
||||
6. bekijk de serial plotter terwel je de IMU draait.
|
||||
|
||||
Geslaagd:
|
||||
|
||||
opmergingen:
|
||||
|
||||
### stroom meting
|
||||
|
||||
#### benodigdheden
|
||||
|
||||
- 12V voeding (of 5V bij beperking van beschikbaare voedingen)
|
||||
- voeding die 50A kan leveren (of zoveel mogenlijk) voor V motor
|
||||
- bij voorkeur een load die de $50A_{DC}$ kan op nemen, ander kan de uitgang korgesloten worden als de voeding dat toestaat.
|
||||
- multimeter
|
||||
- computer met Arduino IDE geinstaleerd
|
||||
- USB B kabel naar de computer
|
||||
|
||||
#### procedure
|
||||
|
||||
1. sluit de load aan op deen van de uitgangen van de motor driver
|
||||
2. snel de voeding in op 12V met een stroom berensing van 150 mA
|
||||
3. sluit de 12V voeding aan op de 12V en GND ingnangen op de driver
|
||||
4. sluit de USB kabel aan op de computer (dit is veilig omdat de USB alleen verbonden is met ground, de V+ is floating)
|
||||
5. upload een programma die alle high side fet's dicht zet en de low side fet's open
|
||||
6. sluit de voeding voor V motor aan
|
||||
7. meet uitgang van de stroom meeting
|
||||
8. zet de v motor voeding uit en verlaats de load naar een andere uitgang
|
||||
9. zet de voeding weer aan en meet de stoom meting
|
||||
10. herhaal dit voor de laaste uitgang
|
||||
|
||||
TODO: add meet table
|
||||
|
||||
Geslaagd:
|
||||
|
||||
opmergingen:
|
||||
|
||||
### encoder
|
||||
|
||||
#### benodigdheden
|
||||
|
||||
- een microcontroller met I2C (kan de motoro driver zelf zijn)
|
||||
- computer met Arduino IDE geinstaleerd
|
||||
- USB B kabel naar de computer
|
||||
|
||||
#### procedure
|
||||
|
||||
1. sluit de Encoder aan op de motor driver
|
||||
2. snel de voeding in op 12V met een stroom berensing van 150 mA
|
||||
3. sluit de 12V voeding aan op de 12V en GND ingnangen op de driver
|
||||
4. sluit de USB kabel aan op de computer (dit is veilig omdat de USB alleen verbonden is met ground, de V+ is floating)
|
||||
5. upload een voorbeeld progamma voor de encoder.
|
||||
6. bekijk de serial plotter terwel je de magneer van de encoder draait
|
||||
|
||||
Geslaagd:
|
||||
|
||||
opmergingen:
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user