Compare commits

...

34 Commits

Author SHA1 Message Date
c51d907d01 udpates van Andrea 2025-10-20 20:24:02 +02:00
c37246c68d merge template with RTS10 2025-10-20 20:20:47 +02:00
cfcfc61458 updates 2025-09-24 13:41:43 +02:00
bb47b3eec5 update 2025-09-22 12:47:32 +02:00
effb36ffe9 update 2025-09-19 17:28:28 +02:00
d06c6301a7 fix bugs and add refs to images 2025-09-19 14:41:20 +02:00
be30ae7a81 update template 2025-09-18 13:17:02 +02:00
7c97a84dfb small updates 2025-09-05 12:01:46 +02:00
0628fc7bea update hedgedoc update scripts 2025-09-04 10:58:30 +02:00
0063600c66 add auther in md propertys 2025-09-04 09:37:13 +02:00
a9acfa4288 update from hedgedoc 2025-09-03 09:49:57 +02:00
1aa8f364a6 add file for foc_onderzoek and remove build files 2025-09-03 09:18:40 +02:00
0a392aa7fe backup 2025-09-03 09:07:17 +02:00
c63fa968f7 more analisys and architecture
All checks were successful
generate pdf files / build (push) Successful in 2m39s
2025-08-19 15:52:52 +02:00
79cb5f9f39 detailontwerp: add more context for analisys and fix minor issues
All checks were successful
generate pdf files / build (push) Successful in 2m22s
2025-08-11 22:10:24 +02:00
3e4ab04fe3 ingeleverd!!
All checks were successful
generate pdf files / build (push) Successful in 2m34s
2025-06-22 23:56:31 +02:00
c20921eded update
All checks were successful
generate pdf files / build (push) Successful in 2m43s
2025-06-22 22:46:53 +02:00
f294d6094c update
All checks were successful
generate pdf files / build (push) Successful in 2m40s
2025-06-22 22:30:13 +02:00
adf92b3886 meer updates
All checks were successful
generate pdf files / build (push) Successful in 2m49s
2025-06-22 21:44:44 +02:00
ec5dc0975a add architectuur ontwerp
All checks were successful
generate pdf files / build (push) Successful in 2m39s
2025-06-22 21:13:18 +02:00
07ba46a75f add softwareontwerp stabilisatie to make
All checks were successful
generate pdf files / build (push) Successful in 2m41s
2025-06-22 19:31:45 +02:00
272d264a07 update project document
All checks were successful
generate pdf files / build (push) Successful in 2m33s
2025-06-22 19:20:44 +02:00
6d8e21bb80 sync with hedgedoc
All checks were successful
generate pdf files / build (push) Successful in 2m35s
2025-06-22 15:53:40 +02:00
91e0f9264f fix pva
Some checks failed
generate pdf files / build (push) Failing after 2m4s
2025-06-22 12:22:50 +02:00
fc6a086ca2 add project document and sync with live.kladjes.nl
Some checks failed
generate pdf files / build (push) Failing after 2m4s
2025-06-22 12:06:51 +02:00
d9498b8135 rename softwareontwerp
All checks were successful
generate pdf files / build (push) Successful in 2m11s
2025-06-22 10:11:22 +02:00
621fbc043b spellings controlle op detailontwerp stabilisatie
Some checks failed
generate pdf files / build (push) Has been cancelled
2025-06-22 10:08:19 +02:00
691a26574a update detail ontwerp stabilisatie
All checks were successful
generate pdf files / build (push) Successful in 2m13s
2025-06-22 00:32:32 +02:00
53b8cbe7d4 stabilisatie: update some more
All checks were successful
generate pdf files / build (push) Successful in 2m14s
2025-06-12 15:45:11 +02:00
ada885c54f add sabalisation detail design
All checks were successful
generate pdf files / build (push) Successful in 2m14s
2025-06-11 18:58:32 +02:00
7b43836f14 update pve
Some checks failed
generate pdf files / build (push) Failing after 7m17s
2025-03-20 15:35:01 +01:00
37bcb4823a add pve to make
Some checks failed
generate pdf files / build (push) Has been cancelled
2025-03-14 10:09:10 +01:00
e4a2c21224 update pve
Some checks are pending
generate pdf files / build (push) Waiting to run
2025-03-13 11:20:05 +01:00
bc998288b6 add pve 2025-03-13 10:51:43 +01:00
23 changed files with 3451 additions and 174 deletions

2
.gitignore vendored
View File

@@ -1,3 +1,5 @@
/latex
/build
/pdf
.obsidian
.trash

644
converters/diagrams.lua Normal file
View File

@@ -0,0 +1,644 @@
--[[
diagram create images and figures from code blocks.
MIT License
Copyright © 2019-2023 Albert Krewinkel
Copyright © 2019 Thorsten Sommer
Copyright © 2018 Florian Schätzig
Copyright © 2018 John MacFarlane
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
]]
-- The filter uses the Figure AST element, which was added in pandoc 3.
PANDOC_VERSION:must_be_at_least '3.0'
local version = pandoc.types.Version '1.2.0'
-- Report Lua warnings to stderr if the `warn` function is not plugged into
-- pandoc's logging system.
if not warn then
-- fallback
warn = function(...) io.stderr:write(table.concat({ ... })) end
elseif PANDOC_VERSION < '3.1.4' then
-- starting with pandoc 3.1.4, warnings are reported to pandoc's logging
-- system, so no need to print warnings to stderr.
warn '@on'
end
local io = require 'io'
local pandoc = require 'pandoc'
local system = require 'pandoc.system'
local utils = require 'pandoc.utils'
local List = require 'pandoc.List'
local stringify = utils.stringify
local with_temporary_directory = system.with_temporary_directory
local with_working_directory = system.with_working_directory
--- Returns a filter-specific directory in which cache files can be
--- stored, or nil if no such directory is available.
local function cachedir ()
local cache_home = os.getenv 'XDG_CACHE_HOME'
if not cache_home or cache_home == '' then
local user_home = system.os == 'windows'
and os.getenv 'USERPROFILE'
or os.getenv 'HOME'
if not user_home or user_home == '' then
return nil
end
cache_home = pandoc.path.join{user_home, '.cache'} or nil
end
-- Create filter cache directory
return pandoc.path.join{cache_home, 'pandoc-diagram-filter'}
end
--- Path holding the image cache, or `nil` if the cache is not used.
local image_cache = nil
local mimetype_for_extension = {
jpeg = 'image/jpeg',
jpg = 'image/jpeg',
pdf = 'application/pdf',
png = 'image/png',
svg = 'image/svg+xml',
}
local extension_for_mimetype = {
['application/pdf'] = 'pdf',
['image/jpeg'] = 'jpg',
['image/png'] = 'png',
['image/svg+xml'] = 'svg',
}
--- Converts a list of format specifiers to a set of MIME types.
local function mime_types_set (tbl)
local set = {}
local mime_type
for _, image_format_spec in ipairs(tbl) do
mime_type = mimetype_for_extension[image_format_spec] or image_format_spec
set[mime_type] = true
end
return set
end
--- Reads the contents of a file.
local function read_file (filepath)
local fh = io.open(filepath, 'rb')
local contents = fh:read('a')
fh:close()
return contents
end
--- Writes the contents into a file at the given path.
local function write_file (filepath, content)
local fh = io.open(filepath, 'wb')
fh:write(content)
fh:close()
end
--- Like `pandoc.pipe`, but allows "multi word" paths:
-- Supplying a list as the first argument will use the first element as
-- the executable path and prepend the remaining elements to the list of
-- arguments.
local function pipe (command, args, input)
local cmd
if pandoc.utils.type(command) == 'List' then
command = command:map(stringify)
cmd = command:remove(1)
args = command .. args
else
cmd = stringify(command)
end
return pandoc.pipe(cmd, args, input)
end
--
-- Diagram Engines
--
-- PlantUML engine; assumes that there's a `plantuml` binary.
local plantuml = {
line_comment_start = [[']],
mime_types = mime_types_set{'pdf', 'png', 'svg'},
compile = function (self, puml)
local mime_type = self.mime_type or 'image/svg+xml'
-- PlantUML format identifiers correspond to common file extensions.
local format = extension_for_mimetype[mime_type]
if not format then
format, mime_type = 'svg', 'image/svg+xml'
end
local args = {'-t' .. format, "-pipe", "-charset", "UTF8"}
return pipe(self.execpath or 'plantuml', args, puml), mime_type
end,
}
--- GraphViz engine for the dot language
local graphviz = {
line_comment_start = '//',
mime_types = mime_types_set{'jpg', 'pdf', 'png', 'svg'},
mime_type = 'image/svg+xml',
compile = function (self, code)
local mime_type = self.mime_type
-- GraphViz format identifiers correspond to common file extensions.
local format = extension_for_mimetype[mime_type]
if not format then
format, mime_type = 'svg', 'image/svg+xml'
end
return pipe(self.execpath or 'dot', {"-T"..format}, code), mime_type
end,
}
--- Mermaid engine
local mermaid = {
line_comment_start = '%%',
mime_types = mime_types_set{'pdf', 'png', 'svg'},
compile = function (self, code)
local mime_type = self.mime_type or 'image/svg+xml'
local file_extension = extension_for_mimetype[mime_type]
return with_temporary_directory("diagram", function (tmpdir)
return with_working_directory(tmpdir, function ()
local infile = 'diagram.mmd'
local outfile = 'diagram.' .. file_extension
write_file(infile, code)
pipe(
self.execpath or 'mmdc',
{"--pdfFit", "--input", infile, "--output", outfile},
''
)
return read_file(outfile), mime_type
end)
end)
end,
}
--- TikZ
--
--- LaTeX template used to compile TikZ images.
local tikz_template = pandoc.template.compile [[
\documentclass{standalone}
\usepackage{tikz}
$for(header-includes)$
$it$
$endfor$
$additional-packages$
\begin{document}
$body$
\end{document}
]]
--- The TikZ engine uses pdflatex to compile TikZ code to an image
local tikz = {
line_comment_start = '%%',
mime_types = {
['application/pdf'] = true,
},
--- Compile LaTeX with TikZ code to an image
compile = function (self, src, user_opts)
return with_temporary_directory("tikz", function (tmpdir)
return with_working_directory(tmpdir, function ()
-- Define file names:
local file_template = "%s/tikz-image.%s"
local tikz_file = file_template:format(tmpdir, "tex")
local pdf_file = file_template:format(tmpdir, "pdf")
-- Treat string values as raw LaTeX
local meta = {
['header-includes'] = user_opts['header-includes'],
['additional-packages'] = {pandoc.RawInline(
'latex',
stringify(user_opts['additional-packages'] or '')
)},
}
local tex_code = pandoc.write(
pandoc.Pandoc({pandoc.RawBlock('latex', src)}, meta),
'latex',
{template = tikz_template}
)
write_file(tikz_file, tex_code)
-- Execute the LaTeX compiler:
local success, result = pcall(
pipe,
self.execpath or 'pdflatex',
{ '-interaction=nonstopmode', '-output-directory', tmpdir, tikz_file },
''
)
if not success then
warn(string.format(
"The call\n%s\nfailed with error code %s. Output:\n%s",
result.command,
result.error_code,
result.output
))
end
return read_file(pdf_file), 'application/pdf'
end)
end)
end
}
--- Asymptote diagram engine
local asymptote = {
line_comment_start = '%%',
mime_types = {
['application/pdf'] = true,
},
compile = function (self, code)
return with_temporary_directory("asymptote", function(tmpdir)
return with_working_directory(tmpdir, function ()
local pdf_file = "pandoc_diagram.pdf"
local args = {'-tex', 'pdflatex', "-o", "pandoc_diagram", '-'}
pipe(self.execpath or 'asy', args, code)
return read_file(pdf_file), 'application/pdf'
end)
end)
end,
}
--- Cetz diagram engine
local cetz = {
line_comment_start = '%%',
mime_types = mime_types_set{'jpg', 'pdf', 'png', 'svg'},
mime_type = 'image/svg+xml',
compile = function (self, code)
local mime_type = self.mime_type
local format = extension_for_mimetype[mime_type]
if not format then
format, mime_type = 'svg', 'image/svg+xml'
end
local preamble = [[
#import "@preview/cetz:0.3.4"
#set page(width: auto, height: auto, margin: .5cm)
]]
local typst_code = preamble .. code
return with_temporary_directory("diagram", function (tmpdir)
return with_working_directory(tmpdir, function ()
local outfile = 'diagram.' .. format
local execpath = self.execpath
if not execpath and quarto and quarto.version >= '1.4' then
-- fall back to the Typst exec shipped with Quarto.
execpath = List{'quarto', 'typst'}
end
pipe(
execpath or 'typst',
{"compile", "-f", format, "-", outfile},
typst_code
)
return read_file(outfile), mime_type
end)
end)
end,
}
local default_engines = {
asymptote = asymptote,
dot = graphviz,
mermaid = mermaid,
plantuml = plantuml,
tikz = tikz,
cetz = cetz,
}
--
-- Configuration
--
--- Options for the output format of the given name.
local function format_options (name)
local pdf2svg = name ~= 'latex' and name ~= 'context'
local is_office_format = name == 'docx' or name == 'odt'
-- Office formats seem to work better with PNG than with SVG.
local preferred_mime_types = is_office_format
and pandoc.List{'image/png', 'application/pdf'}
or pandoc.List{'application/pdf', 'image/png'}
-- Prefer SVG for non-PDF output formats, except for Office formats
if is_office_format then
preferred_mime_types:insert('image/svg+xml')
elseif pdf2svg then
preferred_mime_types:insert(1, 'image/svg+xml')
end
return {
name = name,
pdf2svg = pdf2svg,
preferred_mime_types = preferred_mime_types,
best_mime_type = function (self, supported_mime_types, requested)
return self.preferred_mime_types:find_if(function (preferred)
return supported_mime_types[preferred] and
(not requested or
(pandoc.utils.type(requested) == 'List' and
requested:includes(preferred)) or
(pandoc.utils.type(requested) == 'table' and
requested[preferred]) or
-- Assume string, Inlines, and Blocks values specify the only
-- acceptable MIME type.
stringify(requested) == preferred)
end)
end
}
end
--- Returns a configured diagram engine.
local function get_engine (name, engopts, format)
local engine = default_engines[name] or
select(2, pcall(require, stringify(engopts.package)))
-- Sanity check
if not engine then
warn(PANDOC_SCRIPT_FILE, ": No such engine '", name, "'.")
return nil
elseif engopts == false then
-- engine is disabled
return nil
elseif engopts == true then
-- use default options
return engine
end
local execpath = engopts.execpath or os.getenv(name:upper() .. '_BIN')
local mime_type = format:best_mime_type(
engine.mime_types,
engopts['mime-type'] or engopts['mime-types']
)
if not mime_type then
warn(PANDOC_SCRIPT_FILE, ": Cannot use ", name, " with ", format.name)
return nil
end
return {
execpath = execpath,
compile = engine.compile,
line_comment_start = engine.line_comment_start,
mime_type = mime_type,
opt = engopts or {},
}
end
--- Returns the diagram engine configs.
local function configure (meta, format_name)
local conf = meta.diagram or {}
local format = format_options(format_name)
meta.diagram = nil
-- cache for image files
if conf.cache then
image_cache = conf['cache-dir']
and stringify(conf['cache-dir'])
or cachedir()
pandoc.system.make_directory(image_cache, true)
end
-- engine configs
local engine = {}
for name, engopts in pairs(conf.engine or default_engines) do
engine[name] = get_engine(name, engopts, format)
end
return {
engine = engine,
format = format,
cache = image_cache and true,
image_cache = image_cache,
}
end
--
-- Format conversion
--
--- Converts a PDF to SVG.
local pdf2svg = function (imgdata)
-- Using `os.tmpname()` instead of a hash would be slightly cleaner, but the
-- function causes problems on Windows (and wasm). See, e.g.,
-- https://github.com/pandoc-ext/diagram/issues/49
local pdf_file = 'diagram-' .. pandoc.utils.sha1(imgdata) .. '.pdf'
write_file(pdf_file, imgdata)
local args = {
'--export-type=svg',
'--export-plain-svg',
'--export-filename=-',
pdf_file
}
return pandoc.pipe('inkscape', args, ''), os.remove(pdf_file)
end
local function properties_from_code (code, comment_start)
local props = {}
local pattern = comment_start:gsub('%p', '%%%1') .. '| ' ..
'([-_%w]+): ([^\n]*)\n'
for key, value in code:gmatch(pattern) do
if key == 'fig-cap' then
props['caption'] = value
else
props[key] = value
end
end
return props
end
local function diagram_options (cb, comment_start)
local attribs = comment_start
and properties_from_code(cb.text, comment_start)
or {}
for key, value in pairs(cb.attributes) do
attribs[key] = value
end
local alt
local caption
local fig_attr = {id = cb.identifier}
local filename
local image_attr = {}
local user_opt = {}
for attr_name, value in pairs(attribs) do
if attr_name == 'alt' then
alt = value
elseif attr_name == 'caption' then
-- Read caption attribute as Markdown
caption = attribs.caption
and pandoc.read(attribs.caption).blocks
or nil
elseif attr_name == 'filename' then
filename = value
elseif attr_name == 'label' then
fig_attr.id = value
elseif attr_name == 'name' then
fig_attr.name = value
else
-- Check for prefixed attributes
local prefix, key = attr_name:match '^(%a+)%-(%a[-%w]*)$'
if prefix == 'fig' then
fig_attr[key] = value
elseif prefix == 'image' or prefix == 'img' then
image_attr[key] = value
elseif prefix == 'opt' then
user_opt[key] = value
else
-- Use as image attribute
image_attr[attr_name] = value
end
end
end
return {
['alt'] = alt or
(caption and pandoc.utils.blocks_to_inlines(caption)) or
{},
['caption'] = caption,
['fig-attr'] = fig_attr,
['filename'] = filename,
['image-attr'] = image_attr,
['opt'] = user_opt,
}
end
local function get_cached_image (hash, mime_type)
if not image_cache then
return nil
end
local filename = hash .. '.' .. extension_for_mimetype[mime_type]
local imgpath = pandoc.path.join{image_cache, filename}
local success, imgdata = pcall(read_file, imgpath)
if success then
return imgdata, mime_type
end
return nil
end
local function cache_image (codeblock, imgdata, mimetype)
-- do nothing if caching is disabled or not possible.
if not image_cache then
return
end
local ext = extension_for_mimetype[mimetype]
local filename = pandoc.sha1(codeblock.text) .. '.' .. ext
local imgpath = pandoc.path.join{image_cache, filename}
write_file(imgpath, imgdata)
end
-- Executes each document's code block to find matching code blocks:
local function code_to_figure (conf)
return function (block)
-- Check if a converter exists for this block. If not, return the block
-- unchanged.
local diagram_type = block.classes[1]
if not diagram_type then
return nil
end
local engine = conf.engine[diagram_type]
if not engine then
return nil
end
-- Unified properties.
local dgr_opt = diagram_options(block, engine.line_comment_start)
for optname, value in pairs(engine.opt or {}) do
dgr_opt.opt[optname] = dgr_opt.opt[optname] or value
end
local run_pdf2svg = engine.mime_type == 'application/pdf'
and conf.format.pdf2svg
-- Try to retrieve the image data from the cache.
local imgdata, imgtype
if conf.cache then
imgdata, imgtype = get_cached_image(
pandoc.sha1(block.text),
run_pdf2svg and 'image/svg+xml' or engine.mime_type
)
end
if not imgdata or not imgtype then
-- No cached image; call the converter
local success
success, imgdata, imgtype =
pcall(engine.compile, engine, block.text, dgr_opt.opt)
-- Bail if an error occurred; imgdata contains the error message
-- when that happens.
if not success then
warn(PANDOC_SCRIPT_FILE, ': ', tostring(imgdata))
return nil
elseif not imgdata then
warn(PANDOC_SCRIPT_FILE, ': Diagram engine returned no image data.')
return nil
elseif not imgtype then
warn(PANDOC_SCRIPT_FILE, ': Diagram engine did not return a MIME type.')
return nil
end
-- Convert SVG if necessary.
if imgtype == 'application/pdf' and conf.format.pdf2svg then
imgdata, imgtype = pdf2svg(imgdata), 'image/svg+xml'
end
-- If we got here, then the transformation went ok and `img` contains
-- the image data.
cache_image(block, imgdata, imgtype)
end
-- Use the block's filename attribute or create a new name by hashing the
-- image content.
local basename, _extension = pandoc.path.split_extension(
dgr_opt.filename or pandoc.sha1(imgdata)
)
local fname = basename .. '.' .. extension_for_mimetype[imgtype]
-- Store the data in the media bag:
pandoc.mediabag.insert(fname, imgtype, imgdata)
-- Create the image object.
local image = pandoc.Image(dgr_opt.alt, fname, "", dgr_opt['image-attr'])
-- Create a figure if the diagram has a caption; otherwise return
-- just the image.
return dgr_opt.caption and
pandoc.Figure(
pandoc.Plain{image},
dgr_opt.caption,
dgr_opt['fig-attr']
) or
pandoc.Plain{image}
end
end
return setmetatable(
{{
Pandoc = function (doc)
local conf = configure(doc.meta, FORMAT)
return doc:walk {
CodeBlock = code_to_figure(conf),
}
end
}},
{
version = version,
}
)

69
converters/headers.lua Normal file
View File

@@ -0,0 +1,69 @@
local pagebreak = {
asciidoc = '<<<\n\n',
context = '\\page',
epub = '<p style="page-break-after: always;"> </p>',
html = '<div style="page-break-after: always;"></div>',
latex = '\\newpage{}',
ms = '.bp',
ooxml = '<w:p><w:r><w:br w:type="page"/></w:r></w:p>',
odt = '<text:p text:style-name="Pagebreak"/>'
}
local title = '';
local title_inHaders = true;
local stringify_orig = (require 'pandoc.utils').stringify
local function stringify(x)
return type(x) == 'string' and x or stringify_orig(x)
end
local function newpage(format)
if format:match 'asciidoc' then
return pandoc.RawBlock('asciidoc', pagebreak.asciidoc)
elseif format == 'context' then
return pandoc.RawBlock('context', pagebreak.context)
elseif format == 'docx' then
return pandoc.RawBlock('openxml', pagebreak.ooxml)
elseif format:match 'epub' then
return pandoc.RawBlock('html', pagebreak.epub)
elseif format:match 'html.*' then
return pandoc.RawBlock('html', pagebreak.html)
elseif format:match 'latex' then
return pandoc.RawBlock('tex', pagebreak.latex)
elseif format:match 'ms' then
return pandoc.RawBlock('ms', pagebreak.ms)
elseif format:match 'odt' then
return pandoc.RawBlock('opendocument', pagebreak.odt)
else
-- fall back to insert a form feed character
return pandoc.Para{pandoc.Str '\f'}
end
end
function Meta(meta)
title = (meta.title and stringify(meta.title)) or title
if title ~= '' then
title_inHaders = false;
end
end
function Header(el)
if title_inHaders then
if el.level == 1 then
title = el.content
return {}
else
el.level = el.level - 1;
end
end
if el.level == 1 or el.level == 2 then
return { newpage(FORMAT), el }
end
end
return {
{Meta = Meta},
{Header = Header},
{Meta = function (meta) meta.title = title; return meta end}
}

View File

@@ -0,0 +1,127 @@
--- include-files.lua filter to include Markdown files
---
--- Copyright: © 20192021 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 }
}

View File

@@ -1,27 +1,75 @@
#!/usr/bin/env bash
MD_FILE="$1"
set -e
BASE_DIR="$(pwd)"
TEX_FILE="${BASE_DIR}/latex/$(basename "$MD_FILE" | sed -e 's/\.md$/.latex/')"
PDF_FILE="${BASE_DIR}/pdf/$(basename "$MD_FILE" | sed -e 's/\.md$/.pdf/')"
BUILD_DIR="${BASE_DIR}/build/$(basename "$MD_FILE" | sed -e 's/\.md$//')"
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 \
-e 's|\[toc\]|\\tableofcontents|' \
-e 's|^\[parent\].*$||' \
-e 's|^# .*$||' \
-e 's|^#||' \
-e 's|^# |\\newpage\n# |' \
-e 's|\[\([^]]*\)\](#\([^)]*\))|[\1](#\L\2)|' \
>"$TEMP_MD_FILE"
function download_images() {
echo "download images for $1"
for line in $(grep '!\[.*\](https://.*\.png)' "$1" | sed -e 's/ /%20;/g')
do
src=$(echo "$line" | sed -e 's/^.*(//' -e 's/).*$//' -e 's/%20;/ /g')
echo "download remote image: $src"
mkdir -p "${BASE_DIR}/pdf/images"
name=$(echo "$src" | sed -e 's|^.*/\([^/]*\)$|\1|')
if [[ ! -f "${BASE_DIR}/pdf/images/$name" ]]
then
curl "$src" >"${BASE_DIR}/pdf/images/$name"
else
echo " image already exists"
fi
sed -i "$1" -e "s|$src|${BASE_DIR}/pdf/images/$name|"
done
echo "download done"
}
for line in $(grep '^!\[.*\](.*\.md)$' "$TEMP_MD_FILE" | sed -e 's/ /%20;/g')
do
md_src=$(echo "$line" | sed -e 's/^.*(//' -e 's/).*$//' -e 's/%20;/ /g')
echo "include found: $md_src"
cp "$(pwd)/markdown/$md_src" "$BUILD_DIR/$(basename "$md_src")"
download_images "$BUILD_DIR/$(basename "$md_src")"
sed -i "$BUILD_DIR/$(basename "$md_src")" \
-e 's|\[toc\]||' \
-e 's|^\[parent\].*$||' \
-e 's|^> \[!todo\]|> \\textcolor{cyan}{TODO:}|' \
-e 's|^> \[!warn\]|> \\textcolor{orange}{WARNING:}|' \
-e "s|\`\`\`mermaid|\`\`\`{.mermaid loc=${BASE_DIR}/pdf/images/$(basename "$md_src")}|"
sed -i "$TEMP_MD_FILE" \
-e "s|^\!\[.*\]($md_src)\$|\`\`\`\\{.include shift-heading-level-by=1\\}\n$(basename "$md_src")\n\`\`\`|"
done
download_images "$TEMP_MD_FILE"
sed -i "$TEMP_MD_FILE" \
-e 's|^> \[!todo\]|> \\textcolor{cyan}{TODO:}|' \
-e 's|^> \[!warn\]|> \\textcolor{orange}{WARNING:}|' \
-e "s|\`\`\`mermaid|\`\`\`{.mermaid loc=${BASE_DIR}/pdf/images/$(basename "$MD_FILE")}|"
mkdir -p ${BASE_DIR}/pdf/images/$(basename "$MD_FILE")
cd "$BUILD_DIR"
pandoc --to=latex --template "${BASE_DIR}/converters/template.latex" -o "$TEX_FILE" "$(basename "$TEMP_MD_FILE")"
pandoc --standalone \
--lua-filter=../../converters/include-files.lua \
--lua-filter=../../converters/headers.lua \
-t latex --pdf-engine=xelatex \
--from=markdown+abbreviations \
--template "${BASE_DIR}/converters/template.latex" \
-F "${XDG_DATA_HOME}/npm/bin/mermaid-filter" \
-o "$PDF_FILE" \
"$(basename "$TEMP_MD_FILE")"
cd "$BASE_DIR"
sed --in-place \
-e "s|?title?|$title|" \
"$TEX_FILE"

109
converters/pagebreak.lua Normal file
View File

@@ -0,0 +1,109 @@
--[[
pagebreak convert raw LaTeX page breaks to other formats
Copyright © 2017-2021 Benct Philip Jonsson, Albert Krewinkel
Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
]]
local stringify_orig = (require 'pandoc.utils').stringify
local function stringify(x)
return type(x) == 'string' and x or stringify_orig(x)
end
--- configs these are populated in the Meta filter.
local pagebreak = {
asciidoc = '<<<\n\n',
context = '\\page',
epub = '<p style="page-break-after: always;"> </p>',
html = '<div style="page-break-after: always;"></div>',
latex = '\\newpage{}',
ms = '.bp',
ooxml = '<w:p><w:r><w:br w:type="page"/></w:r></w:p>',
odt = '<text:p text:style-name="Pagebreak"/>'
}
local function pagebreaks_from_config (meta)
local html_class =
(meta.newpage_html_class and stringify(meta.newpage_html_class))
or os.getenv 'PANDOC_NEWPAGE_HTML_CLASS'
if html_class and html_class ~= '' then
pagebreak.html = string.format('<div class="%s"></div>', html_class)
end
local odt_style =
(meta.newpage_odt_style and stringify(meta.newpage_odt_style))
or os.getenv 'PANDOC_NEWPAGE_ODT_STYLE'
if odt_style and odt_style ~= '' then
pagebreak.odt = string.format('<text:p text:style-name="%s"/>', odt_style)
end
end
--- Return a block element causing a page break in the given format.
local function newpage(format)
if format:match 'asciidoc' then
return pandoc.RawBlock('asciidoc', pagebreak.asciidoc)
elseif format == 'context' then
return pandoc.RawBlock('context', pagebreak.context)
elseif format == 'docx' then
return pandoc.RawBlock('openxml', pagebreak.ooxml)
elseif format:match 'epub' then
return pandoc.RawBlock('html', pagebreak.epub)
elseif format:match 'html.*' then
return pandoc.RawBlock('html', pagebreak.html)
elseif format:match 'latex' then
return pandoc.RawBlock('tex', pagebreak.latex)
elseif format:match 'ms' then
return pandoc.RawBlock('ms', pagebreak.ms)
elseif format:match 'odt' then
return pandoc.RawBlock('opendocument', pagebreak.odt)
else
-- fall back to insert a form feed character
return pandoc.Para{pandoc.Str '\f'}
end
end
local function is_newpage_command(command)
return command:match '^\\newpage%{?%}?$'
or command:match '^\\pagebreak%{?%}?$'
end
-- Filter function called on each RawBlock element.
function RawBlock (el)
-- Don't do anything if the output is TeX
if FORMAT:match 'tex$' then
return nil
end
-- check that the block is TeX or LaTeX and contains only
-- \newpage or \pagebreak.
if el.format:match 'tex' and is_newpage_command(el.text) then
-- use format-specific pagebreak marker. FORMAT is set by pandoc to
-- the targeted output format.
return newpage(FORMAT)
end
-- otherwise, leave the block unchanged
return nil
end
-- Turning paragraphs which contain nothing but a form feed
-- characters into line breaks.
function Para (el)
if #el.content == 1 and el.content[1].text == '\f' then
return newpage(FORMAT)
end
end
return {
{Meta = pagebreaks_from_config},
{RawBlock = RawBlock, Para = Para}
}

View File

@@ -1,7 +1,7 @@
\documentclass[11pt]{article}
\usepackage[a4paper, portrait, includehead, includefoot, margin=1.5cm]{geometry}
\usepackage[dutch]{babel}
\usepackage[$if(lang)$$lang$$else$dutch$endif$]{babel}
\usepackage{pdfpages}
@@ -38,6 +38,11 @@
% for images
\usepackage{graphbox}
\usepackage{sectsty}
\sectionfont{\clearpage}
\newcommand\pandocbounded{}
\setkeys{Gin}{width=.99\linewidth}
% add bookmarks with \hypertarget
\usepackage{bookmark}
@@ -60,79 +65,78 @@
\let\tmpenditem\enditemize
\renewenvironment{itemize}{\tmpitem\setlength\itemsep{-.4em}}{\tmpenditem}
$if(highlighting-macros)$
$highlighting-macros$
$endif$
\begin{document}
\raggedright
\pagecolor{darkishyellow}
\begin{titlepage}
\null\vfill
\begin{center}
{\Huge\fontUbuntu ?title? \par}
\vskip 3em
% \includegraphics{assets/eriks.50.png}
\vskip 3em
{\huge\fontUbuntu Superlight Personal Carrier \par}
\end{center}
\vskip 25em
{
\large
\lineskip .75em
\begin{tabular}{r l}
gemaakt door: & Finley van Reenen (0964590@hr.nl) \\
& Gryvon Belfor (0985890@hr.nl) \\
& Chris Tan (0992143@hr.nl) \\
& Mohamed El Morabiti (1014780@hr.nl) \\\\
vak code: & ELEPEE51 \\\\
ge\"exporteerd op: & \today
\end{tabular}
}
\vfill\null
.
\vskip 10em
\begin{center}
{\Huge\fontUbuntu $title$ \par}
\vskip 3em
{\huge\fontUbuntu $sub_title$ \par}
\end{center}
\null\vfill
{
\large
\lineskip .75em
\begin{tabular}{r l}
$if(lang)$Auther$else$Gemaakt door$endif$: $for(auther)$& $auther.name$ <$auther.email$> \\
$endfor$\\
$if(class_code)$
$if(lang)$Class code$else$Vak code$endif$: & $class_code$ \\\\
$endif$
$if(lang)$Exported on$else$Ge\"exporteerd op$endif$: & \today
\end{tabular}
}
\end{titlepage}
\pagestyle{fancy}
\fancyhead{} % clear all header fields
\fancyhead[LO]{\color{gray}\fontUbuntu ?title?}
\fancyhead[RO]{\color{gray}\fontUbuntu Superlight Personal Carrier}
\fancyhead[LO]{\color{gray}\fontUbuntu $title$}
\fancyhead[RO]{\color{gray}\fontUbuntu $sub_title$}
\fancyfoot{} % clear all footer fields
\fancyfoot[LO]{\color{gray}\fontUbuntu E.L.F. van Reenen, G. Belfor, C. Tan en M.E. Morabiti}
\fancyfoot[LO]{\color{gray}\fontUbuntu $for(auther)$$auther.name_short$${sep}, $endfor$}
\fancyfoot[CO]{\color{gray}\fontUbuntu }
\fancyfoot[RO]{\color{gray}\fontUbuntu \thepage}
$if(toc)$
\tableofcontents
$endif$
$if(lof)$
\listoffigures
$endif$
$if(lot)$
\listoftables
$endif$
$if(linestretch)$
\setstretch{$linestretch$}
$endif$
$body$
$if(nocite-ids)$
\nocite{$for(nocite-ids)$$it$$sep$, $endfor$}
$endif$
$if(natbib)$
$if(bibliography)$
$if(biblio-title)$
$if(has-chapters)$
\renewcommand\bibname{$biblio-title$}
$else$
\renewcommand\refname{$biblio-title$}
$endif$
$endif$
\bibliography{$for(bibliography)$$bibliography$$sep$,$endfor$}
% $if(nocite-ids)$
% \nocite{$for(nocite-ids)$$it$$sep$, $endfor$}
% $endif$
% $if(natbib)$
% $if(bibliography)$
% $if(biblio-title)$
% $if(has-chapters)$
% \renewcommand\bibname{$biblio-title$}
% $else$
% \renewcommand\refname{$biblio-title$}
% $endif$
% $endif$
% \bibliography{$for(bibliography)$$bibliography$$sep$,$endfor$}
$endif$
$endif$
$if(biblatex)$
\printbibliography$if(biblio-title)$[title=$biblio-title$]$endif$
% $endif$
% $endif$
% $if(biblatex)$
% \printbibliography$if(biblio-title)$[title=$biblio-title$]$endif$
$endif$
% $endif$
\end{document}
\end{document}

Binary file not shown.

Binary file not shown.

Binary file not shown.

140
makefile
View File

@@ -1,15 +1,21 @@
all: prepare pdf/plan_van_aanpak.pdf pdf/plan_van_aanpak.booklet.pdf
all: all_docduments package
all_docduments: prepare pdf/plan_van_aanpak.pdf pdf/detailontwerp_stabilisatie.pdf pdf/detailontwerp_stuursysteem.pdf pdf/unittest_stabilisatie.pdf pdf/softwareontwerp_stabilisatie.pdf pdf/projectdocument.pdf pdf/pakket_van_eisen.pdf pdf/competenties.pdf pdf/foc_onderzoek.pdf
all_booklets: prepare pdf/plan_van_aanpak.booklet.pdf pdf/detailontwerp_stabilisatie.booklet.pdf pdf/detailontwerp_stuursysteem.booklet.pdf pdf/unittest_stabilisatie.booklet.pdf pdf/softwareontwerp_stabilisatie.booklet.pdf pdf/projectdocument.booklet.pdf pdf/pakket_van_eisen.booklet.pdf pdf/competenties.booklet.pdf pdf/foc_onderzoek.booklet.pdf
prepare:
mkdir -p latex pdf
mkdir -p pdf
clean:
rm -r build
clean_all:
rm -r build pdf
install_arch:
mkdir -p build/install
pacman -S --noconfirm --needed curl unzip texlive-basic texlive-langeuropean pandoc
pacman -Sy --noconfirm --needed curl zip unzip texlive-basic texlive-langeuropean pandoc
test -e build/install/ubuntu.zip || curl https://assets.ubuntu.com/v1/0cef8205-ubuntu-font-family-0.83.zip -o build/install/ubuntu.zip
test -d build/install/ubuntu && rm -r build/install/ubuntu || echo
@@ -22,7 +28,7 @@ install_arch:
test -e build/install/roboto.zip || curl https://dl.dafont.com/dl/?f=roboto -o build/install/roboto.zip
test -d build/install/roboto && rm -r build/install/roboto || echo
mkdir build/install/roboto
mkdir build/install/roboto
unzip build/install/roboto.zip -d build/install/roboto
mkdir -p /usr/share/fonts/roboto
cp build/install/roboto/*.ttf /usr/share/fonts/roboto/
@@ -33,7 +39,7 @@ install_ubuntu:
mkdir -p build/install
apt-get update
DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
curl unzip texlive texlive-lang-european texlive-lang-greek texlive-xetex pandoc
curl zip unzip texlive texlive-lang-european texlive-lang-greek texlive-xetex pandoc
test -e build/install/ubuntu.zip || curl https://assets.ubuntu.com/v1/0cef8205-ubuntu-font-family-0.83.zip -o build/install/ubuntu.zip
test -d build/install/ubuntu && rm -r build/install/ubuntu || echo
@@ -46,33 +52,129 @@ install_ubuntu:
test -e build/install/roboto.zip || curl https://dl.dafont.com/dl/?f=roboto -o build/install/roboto.zip
test -d build/install/roboto && rm -r build/install/roboto || echo
mkdir build/install/roboto
mkdir build/install/roboto
unzip build/install/roboto.zip -d build/install/roboto
mkdir -p /usr/share/fonts/roboto
cp build/install/roboto/*.ttf /usr/share/fonts/roboto/
chmod 0775 /usr/share/fonts/roboto
chmod 0664 /usr/share/fonts/roboto/*
# =======================================
# === latex generation ==================
# =======================================
latex/plan_van_aanpak.latex: converters/mdToLatex.sh converters/template.latex markdown/plan_van_aanpak.md
mkdir -p build/plan_van_aanpak
bash converters/mdToLatex.sh markdown/plan_van_aanpak.md latex/plan_van_aanpak.latex
# =======================================
# === pdf generation ====================
# =======================================
pdf/plan_van_aanpak.pdf: latex/plan_van_aanpak.latex
cd build/plan_van_aanpak && xelatex ../../latex/plan_van_aanpak.latex
cd build/plan_van_aanpak && xelatex ../../latex/plan_van_aanpak.latex
cd build/plan_van_aanpak && xelatex ../../latex/plan_van_aanpak.latex
mv build/plan_van_aanpak/plan_van_aanpak.pdf pdf/plan_van_aanpak.pdf
pdf/plan_van_aanpak.pdf: converters/* markdown/plan_van_aanpak.md
mkdir -p build/plan_van_aanpak
bash converters/mdToLatex.sh markdown/plan_van_aanpak.md
pdf/pakket_van_eisen.pdf: converters/* markdown/pakket_van_eisen.md
mkdir -p build/pakket_van_eisen
bash converters/mdToLatex.sh markdown/pakket_van_eisen.md pdf/pakket_van_eisen.pdf
pdf/detailontwerp_stabilisatie.pdf: converters/* markdown/detailontwerp_stabilisatie.md
mkdir -p build/detailontwerp_stabilisatie
bash converters/mdToLatex.sh markdown/detailontwerp_stabilisatie.md pdf/detailontwerp_stabilisatie.pdf
pdf/detailontwerp_stuursysteem.pdf: converters/* markdown/detailontwerp_stuursysteem.md
mkdir -p build/detailontwerp_stuursysteem
bash converters/mdToLatex.sh markdown/detailontwerp_stuursysteem.md pdf/detailontwerp_stuursysteem.pdf
pdf/unittest_stabilisatie.pdf: converters/* markdown/unittest_stabilisatie.md
mkdir -p build/unittest_stabilisatie
bash converters/mdToLatex.sh markdown/unittest_stabilisatie.md pdf/unittest_stabilisatie.pdf
# pdf/unittest_stuursysteem.pdf: converters/* markdown/unittest_stuursysteem.md
# mkdir -p build/unittest_stuursysteem
# bash converters/mdToLatex.sh markdown/unittest_stuursysteem.md pdf/unittest_stuursysteem.pdf
pdf/softwareontwerp_stabilisatie.pdf: converters/* markdown/softwareontwerp_stabilisatie.md
mkdir -p build/softwareontwerp_stabilisatie
bash converters/mdToLatex.sh markdown/softwareontwerp_stabilisatie.md pdf/softwareontwerp_stabilisatie.pdf
pdf/projectdocument.pdf: converters/* markdown/projectdocument.md
mkdir -p build/projectdocument
bash converters/mdToLatex.sh markdown/projectdocument.md pdf/projectdocument.pdf
pdf/competenties.pdf: converters/* markdown/competenties.md
mkdir -p build/competenties
bash converters/mdToLatex.sh markdown/competenties.md pdf/competenties.pdf
pdf/foc_onderzoek.pdf: converters/* markdown/foc_onderzoek.md
mkdir -p build/foc_onderzoek
bash converters/mdToLatex.sh markdown/foc_onderzoek.md pdf/foc_onderzoek.pdf
# =======================================
# === booklet generation ================
# =======================================
pdf/plan_van_aanpak.booklet.pdf: converters/bookletify.latex pdf/plan_van_aanpak.pdf
mkdir -p build/plan_van_aanpak.booklet
sed -e 's|?pdf?|../../pdf/plan_van_aanpak.pdf|' converters/bookletify.latex >build/plan_van_aanpak.booklet/bookletify.latex
pdflatex -interaction=nonstopmode -output-directory="build/plan_van_aanpak.booklet" "build/plan_van_aanpak.booklet/bookletify.latex"
mv build/plan_van_aanpak.booklet/bookletify.pdf pdf/plan_van_aanpak.booklet.pdf
pdf/pakket_van_eisen.booklet.pdf: converters/bookletify.latex pdf/pakket_van_eisen.pdf
mkdir -p build/pakket_van_eisen.booklet
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/detailontwerp_stabilisatie.booklet.pdf: converters/bookletify.latex pdf/detailontwerp_stabilisatie.pdf
mkdir -p build/detailontwerp_stabilisatie.booklet
sed -e 's|?pdf?|../../pdf/detailontwerp_stabilisatie.pdf|' converters/bookletify.latex >build/detailontwerp_stabilisatie.booklet/bookletify.latex
pdflatex -interaction=nonstopmode -output-directory="build/detailontwerp_stabilisatie.booklet" "build/detailontwerp_stabilisatie.booklet/bookletify.latex"
mv build/detailontwerp_stabilisatie.booklet/bookletify.pdf pdf/detailontwerp_stabilisatie.booklet.pdf
pdf/detailontwerp_stuursysteem.booklet.pdf: converters/bookletify.latex pdf/detailontwerp_stuursysteem.pdf
mkdir -p build/detailontwerp_stuursysteem.booklet
sed -e 's|?pdf?|../../pdf/detailontwerp_stuursysteem.pdf|' converters/bookletify.latex >build/detailontwerp_stuursysteem.booklet/bookletify.latex
pdflatex -interaction=nonstopmode -output-directory="build/detailontwerp_stuursysteem.booklet" "build/detailontwerp_stuursysteem.booklet/bookletify.latex"
mv build/detailontwerp_stuursysteem.booklet/bookletify.pdf pdf/detailontwerp_stuursysteem.booklet.pdf
pdf/unittest_stabilisatie.booklet.pdf: converters/bookletify.latex pdf/unittest_stabilisatie.pdf
mkdir -p build/unittest_stabilisatie.booklet
sed -e 's|?pdf?|../../pdf/unittest_stabilisatie.pdf|' converters/bookletify.latex >build/unittest_stabilisatie.booklet/bookletify.latex
pdflatex -interaction=nonstopmode -output-directory="build/unittest_stabilisatie.booklet" "build/unittest_stabilisatie.booklet/bookletify.latex"
mv build/unittest_stabilisatie.booklet/bookletify.pdf pdf/unittest_stabilisatie.booklet.pdf
pdf/competenties.booklet.pdf: converters/bookletify.latex pdf/competenties.pdf
mkdir -p build/competenties.booklet
sed -e 's|?pdf?|../../pdf/competenties.pdf|' converters/bookletify.latex >build/competenties.booklet/bookletify.latex
pdflatex -interaction=nonstopmode -output-directory="build/competenties.booklet" "build/competenties.booklet/bookletify.latex"
mv build/competenties.booklet/bookletify.pdf pdf/competenties.booklet.pdf
pdf/foc_onderzoek.booklet.pdf: converters/bookletify.latex pdf/foc_onderzoek.pdf
mkdir -p build/foc_onderzoek.booklet
sed -e 's|?pdf?|../../pdf/foc_onderzoek.pdf|' converters/bookletify.latex >build/foc_onderzoek.booklet/bookletify.latex
pdflatex -interaction=nonstopmode -output-directory="build/foc_onderzoek.booklet" "build/foc_onderzoek.booklet/bookletify.latex"
mv build/foc_onderzoek.booklet/bookletify.pdf pdf/foc_onderzoek.booklet.pdf
# pdf/unittest_stuursysteem.booklet.pdf: converters/bookletify.latex pdf/unittest_stuursysteem.pdf
# mkdir -p build/unittest_stuursysteem.booklet
# sed -e 's|?pdf?|../../pdf/unittest_stuursysteem.pdf|' converters/bookletify.latex >build/unittest_stuursysteem.booklet/bookletify.latex
# pdflatex -interaction=nonstopmode -output-directory="build/unittest_stuursysteem.booklet" "build/unittest_stuursysteem.booklet/bookletify.latex"
# mv build/unittest_stuursysteem.booklet/bookletify.pdf pdf/unittest_stuursysteem.booklet.pdf
pdf/softwareontwerp_stabilisatie.booklet.pdf: converters/bookletify.latex pdf/softwareontwerp_stabilisatie.pdf
mkdir -p build/softwareontwerp_stabilisatie.booklet
sed -e 's|?pdf?|../../pdf/softwareontwerp_stabilisatie.pdf|' converters/bookletify.latex >build/softwareontwerp_stabilisatie.booklet/bookletify.latex
pdflatex -interaction=nonstopmode -output-directory="build/softwareontwerp_stabilisatie.booklet" "build/softwareontwerp_stabilisatie.booklet/bookletify.latex"
mv build/softwareontwerp_stabilisatie.booklet/bookletify.pdf pdf/softwareontwerp_stabilisatie.booklet.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
# =======================================
# === zip generation ====================
# =======================================
package: pdf/projectdocument.pdf pdf/competenties.pdf externe_bijlagen/*
test -d build/export && rm -r build/export || echo
mkdir -p build/export
cp externe_bijlagen/* build/export/
cp pdf/projectdocument.pdf build/export/verslag.pdf
cp pdf/competenties.pdf build/export/competentie_verantwoording_Finley.pdf
cd build/export && zip ../../pdf/spc_documentatie.zip *

64
markdown/competenties.md Normal file
View File

@@ -0,0 +1,64 @@
---
sub_title: Superlight Personal Carrier
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
---
# Competentie verantwoording
## Analyseren (8)
Hoofdstuk 3 van `verslag.pdf` wordt uitgelegd hoe de analyse is gedaan. Ik heb in deze fase de voortouw genomen en het PVE gemaakt en beheerd.
Daarnaast heb ik ook geanalyseerd voor de stabilisatie unit zelf (hoofdstuk 6 in `verslag.pdf`; of 8.3.2 voor een uitgebreidere variant). Hier heb ik samen met Tijn de motor keuze gemaakt, en alle berekeningen over de motor heb ik zelf gedaan.
## Ontwerpen (8)
Het was eerst de bedoeling dat ik samen met Gryvon het ontwerp voor de
motordriver te maken, maar die is gestopt met het project voor dat er aan
begonnen is. Dus ik heb het ontwerp alleen gedaan. Chirs, de enige andere van
elektrotechniek, heeft niet veel ervaring van het ontwerpen van motordrivers,
dus ik dacht dat het uitleggen hoe het moet meer tijd kost dan het zelf doen.
zie hoofdstuk 6 van `verslag.pdf` of 8.3 voor het detailontwerp.
## Realiseren (O)
De motordriver heb ik gesoldeerd in het SMD lab op Accademiplein, en getest
eerst op Accademiplein voor te testen of de hardware werkt en later op het RDM
met een motor aangesloten de software en integratie te testen. deze testen zijn nog niet gedocumenteerd.
## Beheren (O)
Zowel documentatie als de software is gebruikt gemaakt van git voor versiebeheer. Deze zet ik standaard pas openbaar als het project is afgerond.
> [!todo]
> software ontwerp en test rapport moeten verder gemaakt worden.
## Managen (6)
Elke week hebben we op donderdag gewerkt en vergaderd op het RDM. Hier hielden
we eiders voortgang updates, en er werd ook regelmatig samen na gedacht over de
uitdagingen waar tegengelopen werd.
## Adviseren (O)
> [!todo]
> moet nog geschreven worden
## Onderzoeken (O)
> [!todo]
> moet nog geschreven worden
## professionaliseren (6)
Er is elke week een presentatie gehouden voor de opdrachtgever en Automotive
docenten.

View File

@@ -0,0 +1,536 @@
---
sub_title: Superlight Personal Carrier
toc: true
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
- name: "Chris Tan"
email: "0992143@hr.nl"
name_short: "c. Tan"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
- name: "Max Kappert"
email: "1030682@hr.nl"
name_short: "m. Kappert"
- name: "Thomas Braam"
email: "0989527@hr.nl"
name_short: "t. Braam"
---
# Detailontwerp Stabilisatie
## Inleiding
De SPC^[Superlight Personal Carrier] is een twee wielig concept eenpersoons
voertuig. Zonder actieve stabilisatie gaat deze omvallen, hiervoor is een
reactie wiel ontworpen. Het aansturen van de motor voor dit wiel is lastig, de
volledige kracht moet gehaald worden vanaf stilstand. Dit is alleen mogelijk met
FOC^[Field oriented Controll].
## Analyse
Er zijn nog veel onbekenden over het voertuig. De belangrijkste parameters die
nodig zijn om de stabilisatie te ontwerpen is het totaal gewicht van het
voertuig en waar het midden van de massa is. Deze parameters kan je alleen maar
weten als het voertuig af is of exact bekent is wat en waar alles in het
voertuig komt. Dit weten we nog niet, om deze inschatting te maken hebben de
automotive studenten een inschatting gemaakt. Deze inschatting is gemaakt op
basis de het huidige frame, hiervoor zijn is het voertuig gewogen en de hoogte
van midden punt van de massa gemeten. En inschattingen van wat er
nog in het voertuig moet komen.
Met deze inschattingen is berekent door Tijn zwaar, de benodigde kracht en
snelheid om de eisen te halen. Hieruit kwam een reactiewiel van $10 Kg$ en
$45 Nm$ op een maximumsnelheid van $1000 rpm$ gehaalt moet kunnen worden.
Dit komt neer op $4.5 kW$ meganishce vermogen.
### Motor Keuze
Het is voor ons niet toegestaan om boven de $50 V$ te testen op de RDM wegens
veiligheid. Er zijn erg weinig motoren beschikbaar die onder deze spanning aan
de eisen voldoet. Hierom wordt het ontwerp voor een hogere spanning ontworpen en
niet op volledig vermogen getest.
De volgende motor is gekozen:
[referentie BLDC-motor](https://nl.aliexpress.com/item/1005006301690150.html?spm=a2g0o.productlist.main.2.6673ifiZifiZQm&algo_pvid=d6292651-bb7c-46b1-a220-6690a13ff967&algo_exp_id=d6292651-bb7c-46b1-a220-6690a13ff967-1&pdp_ext_f=%7B%22order%22%3A%2214%22%2C%22eval%22%3A%221%22%7D&pdp_npi=4%40dis%21EUR%21168.69%21168.69%21%21%211350.60%211350.60%21%402103847817496360886601361e6a7e%2112000036679171853%21sea%21NL%210%21ABX&curPageLogUid=wQDO26xezkrq&utparam-url=scene%3Asearch%7Cquery_from%3A)
De gegeven specificatie zijn:
| | |
|---|---|
| maximale spanning | 60V |
| nominaal vermogen | 3000 W |
| maximaal vermogen | 6000w |
| piek vermogen | 7000w-8000W |
| onbelaste snelheid | 3500 rpm |
| maximaal rendement | 90% |
| maximaal koppel | 10 Nm |
| piekkoppel | 30 Nm |
| nettogewicht | 4,5 kg |
| max. stroombegrenzing | 150A |
![grafiek test data van de motor](https://live.kladjes.nl/uploads/f2dbe830-87ac-4a88-95da-f53177a114a1.png)
| | $U$ (V) | $I$ (A) | $P_{in}$ (W) | rpm | koppel (N.m) | $P_{out}$ (W) | efficiëntie (%) | tijd (s) |
|----------|-------|-------|-------|------|-----|-------|-----|---|
| onbelast | 47.49 | 3.666 | 174.1 | 3264 | 0.03 | 11.1 | 6.4 | 1 |
| test eindpunt^[of wat er ook bedoeld wordt met "测试结束点"] | 42.99 | 60.35 | 2594 | 2294 | 8.77 | 2108 | 81.3 | 71 |
| beoordeelde punten^[of wat er ook bedoeld wordt met "額定点"] | 44.03 | 47.71 | 2101 | 2471 | 6.82 | 1800 | 84.1 | 62 |
| max. koppel | 42.99 | 60.35 | 2594 | 2294 | 8.77 | 2108 | 81.3 | 71 |
| max. $P_{out}$ | 42.99 | 60.35 | 2594 | 2294 | 8.77 | 2108 | 81.3 | 71 |
| max. efficiëntie | 44.72 | 38.53 | 1723 | 2605 | 5.41 | 1476 | 85.7 | 55 |
| 编号(No. ) | 电压 (V) | 电流 (A) | 输入功率 (W) | 转速 (rpm) | 转矩 (Nm) | 输出功率 (W) | 效率 (%) | 时间 (s) |
|----|-------|-------|-------|------|------|-------|------|----|
| 1 | 47.49 | 3.666 | 174.1 | 3264 | 0.03 | 11.1 | 6.4 | 1 |
| 2 | 47.5 | 3.635 | 172.6 | 3262 | 0.03 | 11.14 | 6.5 | 4 |
| 3 | 47.5 | 3.684 | 175 | 3259 | 0.03 | 11.44 | 6.5 | 7 |
| 4 | 47.48 | 3.846 | 182.6 | 3256 | 0.05 | 18.52 | 10.1 | 10 |
| 5 | 47.44 | 4.244 | 201.3 | 3246 | 0.12 | 42.5 | 21.1 | 13 |
| 6 | 47.39 | 5.001 | 237 | 3233 | 0.23 | 79.21 | 33.4 | 16 |
| 7 | 47.31 | 5.93 | 280.5 | 3214 | 0.37 | 126.7 | 45.2 | 19 |
| 8 | 47.21 | 7.09 | 334.7 | 3186 | 0.55 | 184.5 | 55.1 | 22 |
| 9 | 47.1 | 8.719 | 410.7 | 3154 | 0.77 | 254.5 | 62.0 | 25 |
| 10 | 46.95 | 10.76 | 505.3 | 3114 | 1.04 | 341.9 | 67.7 | 28 |
| 11 | 46.78 | 13.04 | 610.3 | 3076 | 1.35 | 437.9 | 71.8 | 31 |
| 12 | 46.6 | 15.34 | 715 | 3040 | 1.71 | 547.4 | 76.6 | 34 |
| 13 | 46.38 | 17.9 | 830.3 | 2980 | 2.12 | 662.2 | 79.8 | 37 |
| 14 | 46.14 | 20.68 | 954.7 | 2917 | 2.57 | 786.9 | 82.4 | 40 |
| 15 | 45.88 | 23.75 | 1090 | 2859 | 3.08 | 922.6 | 84.6 | 43 |
| 16 | 45.61 | 27.55 | 1256 | 2801 | 3.6 | 1057 | 84.2 | 46 |
| 17 | 45.32 | 31.6 | 1432 | 2750 | 4.16 | 1198 | 83.7 | 49 |
| 18 | 45.04 | 34.65 | 1561 | 2676 | 4.75 | 1331 | 85.3 | 52 |
| 19 | 44.72 | 38.53 | 1723 | 2605 | 5.41 | 1476 | 85.7 | 55 |
| 20 | 44.38 | 43.17 | 1916 | 2539 | 6.08 | 1617 | 84.4 | 58 |
| 21 | 44.03 | 47.71 | 2101 | 2471 | 6.82 | 1800 | 84.1 | 62 |
| 22 | 43.67 | 52.13 | 2277 | 2415 | 7.48 | 1892 | 83.1 | 65 |
| 23 | 43.33 | 56.41 | 2444 | 2357 | 8.13 | 2006 | 82.1 | 68 |
| 24 | 42.99 | 60.35 | 2594 | 2294 | 8.77 | 2108 | 81.3 | 71 |
Er missen wat gegevens om verder te kunnen. De hoeveelheid stroom bij krachten
groter dan $8.77 Nm$ en hoelang de piek kracht volgehouden kan worden.
### koppel constante
Om de stroom bij grotere krachten te berekenen is de koppel constante nodig.
Dit is de hoeveelheid koppel die per Ampère levert. In dit geval kan deze
berekend worden met de volgende formule.
$$
K_T = \frac{\tau}{I-I_{noload}}
$$
$K_T$: koppel constante in Nm/A
$\tau$: koppel in Nm
$I$: de stroom nodig om de koppel te halen
$I_{noload}$: de stroom die verbruikt wordt als de motor vrij draait
$\tau$ en $I$ is gegeven in de test data. De beste inschatting voor $I_{noload}$ is het gemiddelde van test 1, 2 en 3. Deze hebben allemaal $0.03Nm$ koppel, er is geen informatie hoe deze koppel gemeten is. Om te controleren of dit correct is is een plot gemaakt voor elke regel van de test data.
![Plot van koppel constanten met 3.662 A voor I_noload](https://live.kladjes.nl/uploads/4aa438b9-f968-4ed9-97f3-dfb934130f6d.png)
x as: test nummer
y as: koppel constante
blauwe punten: berekende koppel constante vanuit de test data
oranje lijn: regressie van de berekende koppel constante
In deze grafiek is een duidelijke curve te zien aan het begin te zien. Dit duidt er op dat $I_{noload}$ te hoog is. Dit kan verklaard worden als de meting is uitgevoerd wanneer de tegenmotor nog aangesloten was maar uitgeschakeld. De $0.03 Nm$ komt, als deze theorie correct is, waarschijnlijk van de lagers van de tegenmotor. Waarschijnlijk mist ook de weerstand van de lagers in de motor zelf.
Met $3.52 A$ voor $I_{noload}$ ziet de grafiek er als volgt uit.
![Plot van koppel constanten met 3.52 A voor I_noload](https://live.kladjes.nl/uploads/fcc86ab9-d051-411d-8379-9d4223c5f4a4.png)
Dit is waarschijnlijk dichter bij de werkelijke $I_{noload}$. Het is hier ook te zien dat de koppel constante ongeveer $0.15 Nm/A$ is.
### Snelheidsconstante en Weerstand Stator
De snelheidsconstante is het aantal rpm dat de motor draait zonder belasting per volt. Deze kan berekend worden met de volgende formule.
$$
K_v = \frac{\omega}{U-U_{th}}
$$
$K_v$: de snelheidsconstante in rpm/v
$\omega$: de snelheid dat de motor draait in rpm
$U$: de spanning
$U_{th}$: de spanning waarop de motor start met draaien
Onbelast draait met $47.49V$ ($U$) draait de motor 3264 rpm ($\omega$). $U_{th}$ is niet gegeven, met de gegeven die er wel zijn is de beste methode met de volgende formules.
$$
U=\frac{\omega}{K_v} + \frac{\tau}{K_T} R + U_{th}
$$
$$
I=\frac{\omega}{K_vR} + \frac{\tau}{K_T} + I_{noload}
$$
$U$: de motor spanning
$\omega$: de snelheid dat de motor draait in rpm
$K_v$: de snelheidsconstante in rpm/v
$\tau$: koppel in Nm
$K_T$: koppel constante in Nm/A
$R$: de weerstand van de stator
$U_{th}$: de spanning waarop de motor start met draaien
$I$: de stroom nodig om de koppel te halen
$I_{noload}$: de stroom die verbruikt wordt als de motor vrij draait
Als $\omega = 0$ gelt $U = \frac{\tau}{K_T} R + U_{th}$ en $I = \frac{\tau}{K_T} + I_{noload} \Rightarrow IR = U = \frac{\tau}{K_T} R + I_{noload} R$ dus $U_{th} = R I_{noload}$
Hiermee kan de volgende formule opgesteld worden
$$
U = \frac{\omega}{K_v} + \frac{\tau}{K_T} R + R I_{noload}
$$
$$
\Rightarrow RU=R\frac{\omega}{K_v} + R^2(\frac{\tau}{K_T} + I_{noload})
$$
$$
\Rightarrow \sqrt{\frac{U}{\frac{\omega}{K_v} (\frac{\tau}{K_T} + I_{noload})}} = R
$$
Met de methode gebruikt voor het berekenen van $I_{noload}$ komen we op de waardes $K_v = 69rpm/V$, $R = 170m\Omega$ en $U_{th} = 598mV$. Hieronder is de grafiek van alle spannignserrors met deze waardes
![Grafiek van spanningserror met berekende waarde](https://live.kladjes.nl/uploads/99a21b34-2ff8-475c-8fef-296368d93bae.png)
x as: test nummer
y as: spannigs error tussen test data en $U=\frac{\omega}{K_v} + \frac{\tau}{K_T} R + U_{th}$
### Koppel Tijdens het Draaien
Om de koppel van $45 Nm$ te kunnen halen op $1000 rpm$ is een gearbox nodig. We hebben alles al berekend om de direct de benodigde spanning en stroom te krijgen van koppel en snelheid met de volgende formule.
$$
U = \frac{\omega}{K_v} + \frac{\tau}{K_T} R + U_{th} = \frac{\omega}{69} + \frac{\tau}{0.15} \cdot 0.17 + 0.598
$$
$$
I = \frac{\tau}{K_T} + I_{noload} = \frac{\tau}{0.15} + 3.52
$$
| gearbox | snelheid | koppel | spanning | stroom | vermogen | efficiëntie[^efficentie-berekening] |
| ------- | --------:| -------:| --------:| -------:| --------:| ------:|
| 1:1 | 1000 rpm | 45.0 Nm | 66.1 V | 303.5 A | 20060 W | 22.4 % |
| 1:2 | 2000 rpm | 22.5 Nm | 55.1 V | 153.5 A | 8456 W | 53.2 % |
| 1:3 | 3000 rpm | 15.0 Nm | 61.1 V | 103.5 A | 6323 W | 71.2 % |
| 1:4 | 4000 rpm | 11.3 Nm | 71.3 V | 78.5 A | 5600 W | 80.4 % |
| 1:5 | 5000 rpm | 9.0 Nm | 83.3 V | 63.5 A | 5289 W | 85.1 % |
[^efficentie-berekening]: op basis van 4.5 kW mechanisch vermogen dat berekend is door automotive studenten
Met een 1:4 gearbox kan een maximale snelheid van 875 rpm halen (de motor kan maximaal 3500 rpm draaien). Dit is iets onder de eisen, maar een betere motor hebben wij niet gevonden voor een redelijke prijs.
voor $3500rpm$ met $11.3 Nm$ is een spanning nodig van $71.3V$.
> Er is zat een grote fout in eerdere berekeningen. Terug regekent was dat voor 25 Nm i.p.v. 45 Nm. Dan is er maar ongeveer 45 A met de 1:4 gearbox nodig. De motor driver is dus ontworpen voor 50 A (inclusief een marge) i.p.v. de 80 A die het eigenlijk had moeten zijn. Volgende keer de berekeningen beter controleren.
> Verder in dit document zal de $50 A$ gebruik worden
### Specificaties
- De drijver moet minimaal $72 V$ aan kunnen, met voorkeur van $120 V$ [^1]
- de drijver moet minimaal $50 A$ continu kunnen leveren [^1]
- maakt gebruik van Field Orented Controll, om het volledige vermogen te kunnen
halen vanaf stilstand.
- De hoek van het voertuig moet gemeten worden.
- Er is een regel loop tussen de hoek sensor en de kracht van de motor.
- Er is een SPI-client connector waarmee verschillende instellingen ingesteld
mee kan worden, waaronder het maximaal vermogen.
- Er is een mogenlijkheid om later de SPI-client te kunnen vervangen met een
CAN-bus.
CAN-bus is de sandaart communicatie potocol in autos, maar er is gekozen om dit
protocool nog niet te implementeeren, wegens de complexitijd van dit protocool.
[^1]: Er wordt tot $50 V$ getest, deze waardes word het voor ontworpen, maar
niet tot de limiet getest.
## Ontwerp
Motordrivers die dit vermogen aan kunnen en FOC ontersteunen zijn erg schaarst,
op de markt. We hebben geen driver kunnen vinden die niet op maat gemaakt wordt.
Zelf een maken is goedkoper, aangezien er geen certificeertingen gedaan hoeven
worden en geen abrijds kosten hoeven te rekenen voor onszelf.
Daarbij heeft het team ook al ervaring. Finley heeft al een motor driver
ontworpen op haar stage. Dat was ook een grote factor in het maken van deze
keuze.
### Componenten
Een FOC BLDC motor driver bestaat minimaal uit drie half driver en een
controller voor de FOC. Eleke halfbridge driver bestaat uit twee transistoren
en een gate driver.
#### Transistoren
Tyristoren werken niet, omdat de voeding direct van een accu komt dus geen 'zero
crossing' om ze uit te zetten. BJT's zijn niet bepaalt geschikt voor grote
stromen. De stroom is zelf erg hoog voor FET's, maar dat is eigenlijk onze enige
optie.
MOSFET's was de eerste waar naar gezocht is. Van bijna alle FET's is de maximale
stroom in de datasheet is niet realistisch haalbaar, dit vereist veel koeling
dat erg lastig is te realiseren. Dit maakt het vinden van een geschikte MOSFET
lastig, de meeste kunnen het niet aan alleen. Het is mogelijk om meerde parallel
te zetten, maar dit vereist goede thermisch beheer.
Een andere optie is GaNFET's, hier hebben we een fabrikant (Efficiënt Power
Converters; EPC) gevonden die veel redelijkere maximale stroom geven. De
EPC3207^[[https://epc-co.com/epc/products/gan-fets-and-ics/epc2307](https://epc-co.com/epc/products/gan-fets-and-ics/epc2307)]
lijkt met meest geschikt voor dit project. Deze kan $62A$ aan volgens de
datasheet, en verliest ongeveer $15W$ bij $50A$. Dit vermogen is goed te koelen
met een koelblok.
#### Gate Driver
EPC geeft een lijst aan aangeraden gate drivers
IC's^[[https://epc-co.com/epc/design-support/gan-first-time-right/drivers-and-controllers](https://epc-co.com/epc/design-support/gan-first-time-right/drivers-and-controllers)].
Er is gekozen voor de NCP51820 van On-Semi uit deze lijst. Deze kan hoge
spanningen aan, de schakeling er om heen is makkelijk te maken door een aparte
source en sync pinnen, en is goed verkrijgbaar voor een goede prijs.
##### Verliezen in de FET
De EPC2307 kan tot $62A$ continu schakelen volgens EPC.
$$
P_{loss} = I^2R_{DS(on)} + P_{loss,sw}
$$
$P_{loss,sw}$: schakel verliezen
$R_{DS(on)} = 10m\Omega$ dus bij $50A$:
$$
P_{loss} = 50^2 \cdot 0.01 + P_{loss,sw} = 25W + P_{loss,sw}
$$
$P_{loss,sw}$ is voor GaNFET's erg laag, in de simulatie - die gebaseerd is op de voorbeeld simulatie van EPC - schakelt die binnen $4ns$. Als we vanuit gaan van linieer schakelgedrag met liniare oplopende stroom (wat tot veel hogeve verliezen lijd dan de werkelijkheid)
$$
P_{loss,sw} = \frac{UIt}{2} \cdot 2f_s
$$
$U$: voedings spanning
$I$: stroom
$t$: schakeltijd
$f_s$: de schakel frequentie
Als je dit invult:
$U = 120V$, $I = 50A$, $t = 4 ns$, $f_s = 50 kHz$ dan is $P_{loss,sw} = 1.2 W$.
Dit geeft een totaal van $P_{loss} = 16.2W$. Dit is berekent met een ruime
schakelverlies met bijna $100\%$ PWM. De werkelijkheid zal het minder zijn.
#### Stroom Meting
Heel eerlijk, deze was ik een beetje vergeten, dus heb snel de ACS724
toegevoegd. Nu hopen dat die de piek stromen aan kan.
#### Hoek Sensor
Het meten van de hoek hebben we drie manieren voor gevonden:
- afstand sensoren naar de grond
Als de grond wat scheef is zal het reactiewiel het voertuig scheef (ten opzichte
van zwaartekracht), waardoor het wiel steeds sneller gaat draaien tot die de
maximale snelheid bereikt, dan valt het voertuig om. Niet heel handig dus.
- MEMS-Gyroscoop
Meet direct de hoek en is snel. Nadeel is als deze afwijkt veranderd de nul
positie en gaat die balanceren op het verkeerde punt.
- MEMS-Versnellingsmeter
Meet de zwaartekracht direct, dus verliest de nul positie niet, maar wordt
verstoord bij een stoot.
De beste optie is een combinatie van een MEMS-gyroscoop en een
MEMS-versnellingsmeter. De versnellingsmeter zorgt er voor dat de nul positie
niet verloren gaat. En de gyroscoop voor nauwkeurige meting van de hoek. Deze
combinatie wordt ook een IMU (Inertial measurement unit) genoemd.
Uiteindelijk is de M5Stack IMU Pro Mini gekozen, dit is een module in behuizing
met een connector. Dit is erg handig, omdat deze goed schokvrij bevestigt moet
worden. Er zit ook nog een kompas en luchtdruk sensor op, maar er zijn geen
plannen om deze te gebruiken.
In deze module zit de
BMI270^[[https://www.bosch-sensortec.com/products/motion-sensors/imus/bmi270/](https://www.bosch-sensortec.com/products/motion-sensors/imus/bmi270/)]
van Bosch. De I^2^C bus van deze IC is direct verbonden met de connector naar
buiten toe.
#### Microcontroller
Er zijn niet veel vereisten voor de microcontroller, bijna alle microcontrollers
hebben SPI, I2C interfaces en een ADC voor de stroom meting. Het belangrijkste
is dat die genoeg rekenkracht heeft voor de FOC berekeningen.
Uiteindelijk is gekozen voor een RP2040 van Raspberry Pi, deze heeft twee ARM
Cortex M0+ cores die tot 150 MHz aan kunnen. Het grote voordeel van deze
microcontroller is dat ik al een ontwerp klaar heb liggen met alle benodigde
componenten.
#### Encoder
Voor FOC moet de positie van polen (magneten) in de rotor ten opzichte van de
slots (elektro magneten) in de rotor. Hoe nauwkeuriger dit is hoe effectiever
de FOC is om met maximale vermogen uit de motor te kunnen halen.
Veel motoren worden geleverd met drie hall-effect sensoren die deze relatieve
positie direct meten, allen zijn deze niet heel nauwkeurig op lage snelheden.
Een Relatieve rotary encoder, zoals een optische die sloten telt in een schrijf
die gemonteerd is aan de rotor, kan veel nauwkeuriger. Het nadeel is dat deze
gekalibreerd moet worden elke keer als de stroom er afgaat.
Een absolute rotary encoder hoeft maar 1 keer gekalibreerd te worden. De meeste.
Er zijn twee soorten absolute encoders die veel gebruikt worden, een die om een
as gemonteerd worden (zoals de
AMT212B-V^[[https://www.sameskydevices.com/product/motion-and-control/rotary-encoders/absolute/modular/amt212b-v](https://www.sameskydevices.com/product/motion-and-control/rotary-encoders/absolute/modular/amt212b-v)])
of een die de oriëntatie van een magneet meet (zoals de
AS5600^[[https://ams-osram.com/products/sensor-solutions/position-sensors/ams-as5600-position-sensor](https://ams-osram.com/products/sensor-solutions/position-sensors/ams-as5600-position-sensor)]).
Er is gekozen voor een breakout board te kopen van de AS5600, deze is het
makkelijkst de monteren en goed verkrijgbaar van de absolute encoders.
### Schema
Het schema is gemaakt in KiCad
#### Half-bridge
Voor een BLDC-motor driver zijn drie half-bridges nodig. Bij een ontwerp van een
half bridge zijn twee belangrijke dingen, naast component keuze. De gate driver
en de power filtering.
##### Power Filtering
In dit ontwerp worden GaNFET's gebruikt, deze schadelijk binnen enkele
nanosecondes. Eleke hoeveelheid aan inductie vanaf de voeding vertraagt deze
snelheid, en is een antenne voor de honderden MHz dat door deze schakelsnelheid
gegenereerd wordt. Er moeten dus condensatoren zo dicht mogelijk bij de FET's om
de inductie zo minimaal mogelijk te maken. Deze moeten ook keramische zijn door
de lage ESR. Een nadeel is dat deze voor veel motor drijvers eigenlijk te groot
zijn waardoor de afstand tussen de condensator en FET's te groot wordt als de
filtering in 1 stage gaat.
Om te berekenen hoeveel stages nodig zijn, moet eerste de layout gemaakt worden
(hier meer over in het hooftstuk PCB). Bij de layout is het geluk om $7.2 \mu F$
(5 x $1\mu F$ en 1 x $2.2\mu F$) in de eerste stage te plaatsen.
> TODO: ref to hooftstuk pcb needed!
Na veel experimenteren in een simulatie in LTspice lijkt $7.2\mu F$ wel weinig,
het zal een stuk beter zijn als er $20\mu F$ zal passen.
De tweede stage is wat klein gehouden, om in inschakelstroom beperkt te houden.
Dit betekent wel dat er erg dikke kabels nodig zijn om het volledige vermogen
aan te kunnen.
Helaas is de simulatie gecrasht en het bestand corrupt geraakt. Het is hierna
niet meer gelukt om de simulatie stabiel opnieuw op te bouwen (vermogens van
honderden KW bij een kleine aanpassing). Onder staat is de schakeling van de
opnieuw opgebouwde schakeling die dus niet werkt.
![Schakeling simulatie power filter\label{detil_stab_sim_fet}](https://live.kladjes.nl/uploads/7f783ce7-ee05-4193-844f-240cbec98bce.png)
In figuur \ref{detil_stab_sim_fet} is C2 zijn de keramische condensatoren vlak bij de FET's (eerste stage), C3 en C1
zijn solid polymer aluminum capacitors voor de tweede stage. L4 is een
ingeschatte inductie van de verbinding tussen de condensatoren en L5 is de
inductie van de kabels vanaf de accu.
De condensator waardes zijn een stuk groter dan op het evaluatiebord. Hier
zitten 7 condensatoren van $22nF$ op ($125nF$ totaal). Ik vermoed dat mijn
simulaties wat pessimistischer zijn dat de werkelijkheid.
##### Gate Driver
Het simulatiemodel van de gate driver IC is alleen beschikbaar voor Simplus. Het
is mij niet gelukt om de gratis versie van deze software werkend te krijgen of
het model te converteren naar een ander format. Dus het berekenen of simuleren
voor gate driver gaat niet lukken. Dus ik heb een referentieontwerp van EPC
overgenomen met een $0\Omega$ weerstand bij de sync (hier is wel een $0\Omega$
jumper gebruikt zodat die later vervangen kan worden met een weerstand) en
$0.39\Omega$ voor de source.
#### Microcontroller
De microcontroller schakeling is een kopie van een hobby project, deze
schakeling is al getest. Er is niks veranderd aan dit ontwerp voor dit project,
behalve dat er andere io pinnen gebruikt worden.
### PCB
#### Stroom Distributie
Vijftig ampère is erg veel voor een PCB.
> KiCad Calculator Tools:
> "The calculations are valid for currents up to $35 A$ (external) or $17.5 A$
(internal), temperature rises up to $100^\circ C$, and widths of up to 400
mils (10mm)"
Deze tool geeft voor $35A$, $150mm$ spoor lengte en $10^\circ C\Delta$ met
$70\mu m$ koper een spoor breedte van $20.2mm$. De spoorbreedte is al buiten het
berijk van deze tool. Als we toch de stroom verandert naar $50A$ wordt dit
$33.1mm$.
Met dezelfde instellingen voor $50A$ in de calculator van DigiKey keeft die
dezelfde resultatie. En die van AdvancedPCB, PCBWay en OMNI calculator. Of ze
gebruiken allemaal dezelfde beperkte formule of het klopt redelijk.
Er is gekozen om een spoor breedte van $40mm$ te gebruiken om iets marge te
hebben als deze rekenmachines afwijken. Dit is erg breed, dus dit verdeeld gedaan
over een buiten laag en een binnen laag plus nog een extra marge omdat
binnenlagen minder goed koelen. De lagen zijn om en om gedaan, zodat het beetje
capaciteit tussen deze lagen de inductie ietsje compenseert.
#### Half-bridges
Gelukkig heeft EPC (de fabrikant van de FET's) een aantal aangeraden layouts (figuur \ref{detil_stab_fet_ref}).
![Aangeraden PCB layout van EPC\label{detil_stab_fet_ref}](https://live.kladjes.nl/uploads/e4a587e6-798b-4fed-8518-9574473bdf79.png)
Bij dit project worden de high-side (HS) en low-side (LS) FET's ongeveer
hetzelfde belast, dus ze hebben dezelfde koeling nodig. Dus er is voor de
middelste optie gekozen.
![3D render van een van de half-brdige layouts\label{detil_stab_fet_layout}](https://live.kladjes.nl/uploads/43a7f9a1-a3d6-4f2b-844e-be65623e1b12.png)
In figuur \ref{detil_stab_fet_layout} is de layout te zien. De rij condensatoren in het midden tussen de
twee FET's (met veel vias er omheen). Rechts daar van de SOIC-8 is de stroom
meting IC en rechts onderin de gate driver.
De uitgang van de FET's voor de stroom meet IC is er ook in de binnen laag
direct onder de top laat (de render is van de top laag). Deze zit er om de
stroom loop zo'n klein mogelijk oppervlak te geven met de condensatoren, door er
onder door te gaan. Hierom stoppen de vias van de voeding ook zo abrupt.
## Productie
De PCB en stencel zijn gepoduceert door JLCPCB en de componenten zijn gelaats en
in de reflow oven gegaan in het SMD-lab op Accademiplein.
Na dat die uit de over kwam zijn er een aantal soleer balletjes weggehaald, twee
soldeer bruggen weg gehaald bij een van de gate driver IC's en de
microcontroller opnieuwe met de hand erop gelaast. De microcontroller had teveel
tin op de groundpad aan de onderkant, waardoor deze omhoog kwam en de pinnen aan
de zijkant boven de PCB zweefde onder contact.

View File

@@ -0,0 +1,50 @@
---
sub_title: Superlight Personal Carrier
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
- name: "Chris Tan"
email: "0992143@hr.nl"
name_short: "c. Tan"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
- name: "Max Kappert"
email: "1030682@hr.nl"
name_short: "m. Kappert"
- name: "Thomas Braam"
email: "0989527@hr.nl"
name_short: "t. Braam"
---
## Vehicle Control unit
De VCU is een belangrijk onderdeel van het systeem, hiermee kunnen we het voertuig in een richting sturen en vooruit bewegen, de belangrijkste keuzes hierin zijn in welke taal we willen gaan programmeren en wat voor soort microcontroller we willen. De reden hiervoor is zodat de volgende team makkelijker kan omgaan met de code en het systeem makkelijker kunnen uitbreiden. het makkelijkst is dan om met de Arduino IDE en framework verder te gaan, omdat het een bekent en veel gedocumenteerd systeem is waar je veel over kan vinden op internet tegenover veel andere IDE's, programmeer talen en microcontrollers. verder moet het ook draadloos verbinding kunnen maken met een console controller zodat de volgende teams eventueel een andere keuze kunnen maken hoe ze willen sturen. Daarom hebben we voor de ESP32 gekozen omdat het alles aantikt met een gezond aantal GPIO pinnen.
## 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.
| Parameter | Waarde | Eenheid | Opmerking |
| ------------------------------ | ------------- | ---------- | --------------------------------------------------- |
| Voertuigspanning | 12 - 14 | $V_{DC}$ | typisch voor auto-VCU's |
| Stuurspanningdemperkle | 0 - 5 | $V_{DC}$ | naloge regeling |
| PWM-signaal frequentie | 25000 - 30000 | $Hz$ | Typische range voor aansturing |
| PWM duty cycle | 10 - 90 | $\%$ | $0\%$: minimale demping, $90\%$: maximale demping * |
| Stroomverbruik klep | 0.5 - 2 | $A$ | Afhankelijk van de interne weerstand |
| Wielsnelheid | 0 - 250 | $km/h$ | Meet snelheid per wiel |
| Karrosserieversnelling | -3 tot +3 | $g$ | Laterale en verticale versnellingen |
| Axiale potentiometer (veerweg) | 0 - 50 | $mm$ | Meet veeruitslag |
| Temperatuur werkbereik | -40 tot +85 | $^\circ C$ | Automobielstandaard |
*demping voor de ophanging
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. om de actuator te besturen gebruiken we een motordriver, de MDD20A. Dit is omdat we het al hebben en werkt met de huidige actuatoren en voldoende de parameters van de actuatoren behaald, daarom hebben we besloten om niet een nieuwe te kopen of te ontwerpen. Om ervoor te zorgen dat de actuatoren niet te ver gaan gebruiken we de AS5600 magnetic encoder. Dit is omdat de encoder een absoluut positie meegeeft en daarom voor minder problemen zorgt als het voertuig opnieuw opstart.

42
markdown/foc_onderzoek.md Normal file
View File

@@ -0,0 +1,42 @@
---
sub_title: Superlight Personal Carrier
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
---
*[BLDC]: Brushless Direct Current motor
*[SPC]: Superlight Personal Carrier
# Onderzoek Efficentie BLDC
## Inleiding
Voor de stabilisatie van de SPC is gekozen om dit te doen met een reactiewiel.
Hiervoor is het nodig dat de volledige kracht geleverd kan worden vanaf stilstand.
Dit onderzoek kijkt naar hoe dit gedaan kan worden.
## Onderzoeks vraag
hoofdvraag: Hoe kan een BLDC aangestuurd worden om het moment te maximaliseren
vanaf stilstand.
### Deel vragen
- what control methods are there
- torque over speed graph
-
### Voor Onderzoek
zoek therm: "efficiency BLDC control method for low speed"

View File

@@ -0,0 +1,127 @@
---
sub_title: Superlight Personal Carrier
toc: true
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
- name: "Chris Tan"
email: "0992143@hr.nl"
name_short: "c. Tan"
- name: "Gryvon Belfor"
email: "0985890@hr.nl"
name_short: "g. Belfor"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
- name: "Max Kappert"
email: "1030682@hr.nl"
name_short: "m. Kappert"
- name: "Thomas Braam"
email: "0989527@hr.nl"
name_short: "t. Braam"
---
# Pakket van Eisen
## Inleiding
Bij dit project is de SPC^[Superlight Personal Carrier] opgesplitst in een aantal onderdelen. de eisen zijn verdeeld over deze onderdelen.
Deze onderdelen zijn gesplitst op basis van welke onderdelen die in dit project verbeterd worden.
## Eis identificatie code
```
REQ-X-X[XX]
| | |
| | +- MH: zonder is het product niet bruikbaar
| | SH: het product is zonder ook bruikbaar, maar is zeer gewenst
| | CH: als het binnen de tijd lukt is het gewenst
| | WH: niet gewenst
| |
| +--- uniek identificatie nummer
|
+----- A: algemeen
W: wiel assembly
S: stabilisatie
C: VCU
```
## Definities
**Het voertuig**: De Superlight Personal Carrier die tijdens dit project gemaakt/verbeterd wordt.
**Bestuurder**: De persoon die in het voertuig zit, en het voertuig bestuurd.
## Algemene eisen
**REQ-A-1[MH]: Het voertuig exclusief bestuurder weegt 250 kilogram of minder.**
**REQ-A-2[MH]: Het voertuig heeft een totale lengte van 4 meter of minder.**
**REQ-A-3[MH]: Het voertuig heeft een totale breedte van 60 centimeter of minder.**
**REQ-A-4[MH]: Het voertuig is ontworpen[^ontwerp] zodat de maximale snelheid 60 kilometer per uur of sneller is.**
60 km/h is de minimale snelheid voor op de snelweg^[[https://www.rijksoverheid.nl/onderwerpen/wegen/vraag-en-antwoord/wat-is-de-minimumsnelheid-voor-het-wegverkeer](https://www.rijksoverheid.nl/onderwerpen/wegen/vraag-en-antwoord/wat-is-de-minimumsnelheid-voor-het-wegverkeer)].
**REQ-A-5[SH]: Het voertuig is ontworpen[^ontwerp] zodat die 150 kilometer per uur of sneller kan rijden in ideale omstandigheden[^omstandig].**
**REQ-A-6[SH]: Het voertuig is ontworpen[^ontwerp] zodat die 100 kilometer actieradius of meer kan bereiken in ideale omstandigheden[^omstandig].**
De opdracht gever wil graag tussen Amsterdam van Rotterdam kunnen rijden.
**REQ-A-7[CH]: Het voertuig is ontworpen[^ontwerp] zodat die 250 kilometer actieradius of meer kan bereiken in ideale omstandigheden[^omstandig].**
[^ontwerp]: Binnen de tijdspan van dit project is het niet mogelijk om op deze eisen te testen buiten een simulatie of rekenmodel.
[^omstandig]: De ideale omstandigheden is op een vlakke rechte geasfalteerde weg zonder wind, regen, hagel, sneeuw of andere weersomstandigheden die een negatief gevolg op de test kunnen hebben.
**REQ-A-8[CH]: Het voertuig is bestand tegen corrosie**
**REQ-A-9[SH]: Het voertuig kan bedient worden door een bestuureder van 130 kilogram of minder.**
**REQ-A-10[SH]: Het voertuig kan bediend worden door een bestuurder met een lengte van 150 centimeter tot en met 200 centimeter.**
> bron [www.cbs.nl/nl-nl/maatwerk/2021/37/lichaamslengte](https://www.cbs.nl/nl-nl/maatwerk/2021/37/lichaamslengte)
> 8% van 19 jarige vrouwen zijn korter dan 160
> 10.2% van 19 jarige mannen zijn korter dan 175
**REQ-A-11[MH]: De bestuurder van het voertuig zit volledig binnen de afmetingen van het voertuig, met uitzondering van de hoogte.**
**REQ-A-12[SH]: Het zwaarte punt van het voertuig ligt 45 centimeter of minder boven de grond bij een vlakke grond.**
## Wiel Assembly
**REQ-W-1[MH]: het voertuig heeft twee wielen.**
**REQ-W-2[MH]: het voertuig wordt aangedreven door beide wielen.**
**REQ-W-3[SH]: het voertuig stuurt met beide wielen.**
**REQ-W-4[MH]: het voertuig wordt aangedreven door elektromotoren.**
**REQ-W-5[SH]: het voertuig kan remmen doormiddel van regenerative braking.**
**REQ-W-6[SH]: de aandrijving bevindt zich in het wiel.**
**REQ-W-7[MH]: het voertuig heeft een remvertraging van 6 meter per seconde per seconde of meer.**
**REQ-W-8[MH]: het voertuig heeft een draaicirkel van 6 meter in diameter of minder.**
## Stabilisatie
**REQ-S-1[MH]: Het voertuig wordt actief gestabaliseerd**
**REQ-S-2[SH]: Het voertuig kan uit zichzelf weer recht komen te zitten vanaf een roll hoek van 5 graden**
## VCU
**REQ-C-1[MH]: het voertuig wordt bestuurd doormiddel van een elektronisch input, zoals een joystick, die bedienbaar is door de bestuurder.**
**REQ-C-2[MH]: er is een noodstop aanwezig.**

View File

@@ -1,157 +1,585 @@
---
tags: kladjes, elektro, elektro/hr, elektro/hr/pee51
sub_title: Superlight Personal Carrier
toc: true
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
- name: "Chris Tan"
email: "0992143@hr.nl"
name_short: "c. Tan"
- name: "Gryvon Belfor"
email: "0985890@hr.nl"
name_short: "g. Belfor"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
- name: "Max Kappert"
email: "1030682@hr.nl"
name_short: "m. Kappert"
- name: "Thomas Braam"
email: "0989527@hr.nl"
name_short: "t. Braam"
---
[parent](/tPb3Up1fQEuZ86yrJSkYRQ)
# Plan van Aanpak
# Plan van Aaanplak
## Voorwoord
[toc]
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.
## Achtergrond
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 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.
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.
## Inleiding
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 (figuur \ref{pva_proto}) 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
![SPC-prototype\label{pva_proto}](https://live.kladjes.nl/uploads/fe818f96-0652-430d-a7db-36cbb07ccf09.png)
## 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**.
| scope | Beschrijving | Afbakening |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| Aandrijving en Stuur-systeem | Ontwerpen en ontwikkelen van een functionele aandrijving en stuursysteem, gemonteerd in het fysieke voertuig | Focus op fysiek implementeerbare systemen |
| | | |
| Digital Twin | Ontwerp, validatie en optimalisatie aan de hand van gegeven uit de **Digital Twin** | Geen aerodynamica optimalisatie of andere optimalisatie |
| | | |
| Stabilisatie-ontwikkeling | Verdere ontwikkeling van het **stabilisatiesysteem**, met als einddoel een **full-scale implementatie** in het voertuig | Alleen binnen gegeven snelheidsbereik |
#### 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 risicos beschreven en wat we doen om de risicos 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 (figuur \ref{pva_dmadv}). 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.
![DMADV-cyclus: een ontwerp om nieuwe processen te creëren\label{pva_dmadv}](https://live.kladjes.nl/uploads/506da834-573f-4c24-8b22-15e82df64301.png)
#### 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 CTQs die uit de View of Client en View of Business zijn gehaald die voor dit onderzoek belangrijk zijn, zijn hieronder in tabelvorm genoteerd.
| Voice of customer | Drijfveer | Critical To Quality |
| --------------------- | ------------------------------------------ | ----------------------------------------- |
| zelf sabiliserend | Rechtopstaand tijdens stilstaan | Vliegwiel of stabilisator |
| | goed bochten kunnen maken | Balans in voertuig |
| | | |
| Elektrish aangedreven | eleknische motor | in wiel motor |
| | elektrisch opladen | accupakket |
| | | |
| 2x2x2 aandrijving | 2 sturende wielen | stuurstysteem voor en achter |
| | 2 aangedreven wielen | motor voor en achter in het wiel |
| | | |
| openbareweg | mag op alle wegen tijden | kan minimaal 90 tijden |
| | is goedgekeurd door overheid | voldoet aan regelement |
| | | |
| autonoom voorbereid | kan vanaf meerdere plekken bestuurd worden | kan drive by wire bestuurd worden |
| | autonoom concept | worden concepten voor autonomie ontworpen |
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)
```mermaid
flowchart TD
tijn(Projectlijder <br/> Tijn Snijders)
niels(Opdrachtgever <br/> Niels van Groningen)
max(Automotive Engineer <br/> Max Kappert)
thomas(Automotive Engineer <br/> Thomas Braam)
Finley(Hoofd Elektro <br/> Finley van Reenen)
Chris(Elekntotechnishce Engeneer <br/> Chris Tan)
gryvon(Elekntotechnishce Engeneer <br/> Gryvon Belfor)
mohamed(Elekntotechnishce Engeneer <br/> Mohamed El Morabiti)
joris(Docentbegeleider <br/> Joris Straver)
tijn -..-> niels
tijn --> max & thomas & Finley
Finley -..-> joris
Finley --> Chris & gryvon & mohamed
```
### PBS (Product Breakdown Structure)
```mermaid
flowchart TD
proj(Superlight Personal Carrier 2025)
twin(Digital Twin)
stab(Geintergreerde Stabilisatie)
stuur(Struur Systeem)
Aand(Aandrijving)
tijn(Mechanische <br/> Tijn Snijders)
max(Mechanische <br/> Max Kappert)
thomas(Simulatie <br/> Thomas Braam)
Finley(Elektronishe <br/> Finley van Reenen)
Chris(Elektronishe <br/> Chris Tan)
gryvon(Hardware <br/> Gryvon Belfor)
mohamed(Software <br/> Mohamed El Morabiti)
proj --> twin & stab & stuur & Aand
twin --> thomas
stab --> tijn --> Finley
stuur --> max --> Chris
Aand --> gryvon --> mohamed
```
### WBS (Work Breakdown Structure)
```mermaid
flowchart TD
spc(Superlight Personal Carrier)
1(1\. Digital Twin)
1.1(1.1 Simulatieontwikkeling)
1.1.1(1.1.1 Modelvalidatie)
1.1.2(1.1.2 Data-integratie)
1.1.3(1.1.3 Testen en kalibreren)
2(2\. Geintegreerde Sabilisatie)
2.1(2.1 Mechanische ontwerp)
2.1.1(2.1.1 Conceptontwikkeling)
2.1.2(2.1.2 Simuleren)
2.1.3(2.1.3 Prototyping)
2.1.4(2.1.4 Realiseren)
2.1.5(2.1.5 Valideren)
2.2(2.2 Elektnoische ontwerp)
2.2.1(2.2.1 Concept ontwikkeling)
2.2.2(2.2.2 Defineren)
2.2.3(2.2.3 Realiseren)
2.2.4(2.2.4 Valideren)
3(3\. Stuursysteem)
3.1(3.1 Mechanische ontwerp)
3.1.1(3.1.1 Stuurmechanisme)
3.1.2(3.1.2 Montageontwerp)
3.1.3(3.1.3 Realiseren)
3.1.4(3.1.4 Valideren)
3.2(3.2 Elektnoische ontwerp)
3.2.1(3.2.1 Signaalverwerking)
3.2.2(3.2.2 actuatorbesturing)
3.2.3(3.2.3 Softwareconfiguratie)
4(4\. Aandrijving)
4.1(4.1 Hardware)
4.1.1(4.1.1 Motorselectie)
4.1.2(4.1.2 Vermogenselektronica)
4.1.3(4.1.3 Energiebeheer)
4.1.4(4.1.4 Realiseren)
4.2(4.2 software)
4.2.1(4.2.1 Regelsoftwere)
4.2.2(4.2.2 Veiligheidsprotocollen)
4.2.3(4.2.3 Communicatie-interfacd)
4.2.4(4.2.4 Realiseren)
spc --> 1 & 2 & 3 & 4
1 --> 1.1 --> 1.1.1 --> 1.1.2 --> 1.1.3
2 --> 2.1 & 2.2
2.1 --> 2.1.1 --> 2.1.2 --> 2.1.3 --> 2.1.4 --> 2.1.5
2.2 --> 2.2.1 --> 2.2.2 --> 2.2.3 --> 2.2.4
3 --> 3.1 & 3.2
3.1 --> 3.1.1 --> 3.1.2 --> 3.1.3 --> 3.1.4
3.2 --> 3.2.1 --> 3.2.2 --> 3.2.3
4 --> 4.1 & 4.2
4.1 --> 4.1.1 --> 4.1.2 --> 4.1.3 --> 4.1.4
4.2 --> 4.2.1 --> 4.2.2 --> 4.2.3 --> 4.2.4
```
## Risico- en stakeholder analyse
### Risicos
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 risicos 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
Er is een risico matirx gemaakt in Exel, dit bestand is samengevoed met dit documnet.
### 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.
| | Tijn | Max | Thomas | Gryvon | Chris | 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 risicos beschreven en wat we doen om de risicos 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
## Risicos
- 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
Zie `planned value.pdf`.
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 (figuur \ref{gantt}) 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
![Stroken planning\label{gantt}](https://live.kladjes.nl/uploads/74cc3813-2ec9-41ae-a4b4-0bde16c2b57e.png)
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 (REQ-S-2[SH] in PvE)
### 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)

509
markdown/projectdocument.md Normal file
View File

@@ -0,0 +1,509 @@
---
sub_title: Superlight Personal Carrier
toc: true
lof: true
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
- name: "Chris Tan"
email: "0992143@hr.nl"
name_short: "c. Tan"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
- name: "Max Kappert"
email: "1030682@hr.nl"
name_short: "m. Kappert"
- name: "Thomas Braam"
email: "0989527@hr.nl"
name_short: "t. Braam"
---
*[PvE]: Plan van Aanpak
*[MS Exel]: Microsoft Exel
*[SPC]: Superlight Personal Carier
*[VCU]: Vehicle Control Unit
# Superlight Personal Carier (SPC)
## Inleiding
Dit SPC-project is een samenwerking tussen de opleidingen Automotive en
Elektrotechniek. Het doel van het project is om een lichtgewicht, zelf
stabiliserend eenpersoonsvoertuig te ontwikkelen dat als een testplatform kan
dienen. Door het voertuig lichter te maken in gewicht zorgt dit voor een
kleinere milieuvriendelijke manier van persoonlijk transport te maken dan een
'gewone' auto.
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.
Het SPC-project is een innovatief en interdisciplinair initiatief waarin
studenten van de opleidingen Automotive en Electrotechniek samenwerken. 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.
#### Documentatie
In dit project is de documentatie gedaan in Markdown, dit is een tekstindeling
voor het schrijven van gestructureerde documenten. Het voordeel hiervan is dat
de opmaak meer consistent is en er van Git gebruikt gemaakt kan worden om
bewerkingen bij te houden. Dit maakt het voor de elektrotechnici eenvoudiger om
alle informatie overzichtelijk te beheren.
Om ook aan de eisen van de autotechnici te voldoen, die in Microsoft Word en
Excel moeten werken, zijn de gezamenlijke documenten hierin gemaakt.
Voor een effectieve samenwerking is er gebruikgemaakt van HedgeDoc (op
[live.kladjes.nl](https://live.kladjes.nl)). Dit is een open-source Markdown
editor. Op deze manier konden alle projectleden tegelijkertijd werken in
hetzelfde document. Vanuit HedgeDoc wordt de documentatie gesynchroniseerd naar
een Git repository om de bewerkingen bij te houden.
Om de Markdown om te zetten naar PDF wordt Pandoc en TexLive gebruikt. Pandoc
converteert de inhoud naar Latex. Deze output wordt vervolgens met TexLive
geconverteerd naar een PDF. Om dit proces te versimpelen is GNU Make gebruikt.
Hiermee is het proces geautomatiseerd en toegankelijker gemaakt voor alle
gebruikers.
Door wat extra moeite en tijd te besteden aan het begin van het project aan deze
opzet, werd het tijdens het project gemakkelijker en eenvoudiger om de
informatie vanuit verschillende kennisgebieden samen te brengen. Daarnaast
zorgde het er ook voor dat het document gemakkelijk als geheel in zowel opmaak
als inhoud opgeleverd kon worden.
#### Documentindeling
Het document is geschreven met het primaire doel dat de volgende projectgroep de
genomen stappen begrijpt en hier zelfstandig op verder kan bouwen.
Zometeen start het document met de analyse, waarin aan de hand van de eisen is
geanalyseerd wat er nodig is voor het project. Na de analyse zijn de benodigde
onderdelen en de bijbehorende eisen beschreven onder het kopje architectuur. Er
wordt per unit verdiepender ingegaan op wat er nodig is. Vervolgens wordt er
kort een update gegeven over het projectverloop. We sluiten af met een conclusie
en adviezen.
Veel gebruikte data en plannen zijn in de bijlage geplaatst, zodat het document
overzichtelijk blijft. Er wordt in het document verwezen naar de relevante
bijlagen.
Naar de gebruikte theorie voor het project is gerefereerd volgens de
IEEE-standaard.
## Analyse
De opdrachtgever voor dit project is Niels Groningen. Zijn opdracht is om een
testplatform te ontwerpen. De grootste uitdaging van dit testplatform is dat het
nog niet bekend is wat er precies getest gaat worden. Het is hierdoor lastig om
harde eisen te stellen. Het moet dus mogelijk zijn om verschillende soorten
testen te doen.
In overleg met de opdrachtgever zijn de verwachtingen vastgelegd. Deze zijn
binnen de projectgroep omgezet in meetbare en haalbare eisen. Hieruit is een
Plan van Eisen (PvE) samengesteld.
Dit plan is opgezet via de MoSCoW-methode. Dit is een projectmanagements- en
prioriteringsstrategie om eisen en taken te classificeren. Met deze methode
worden de eisen onderverdeeld in prioriteiten. Eisen waar zeker aan voldoen moet
worden om het project te laten slagen (MH), eisen die zeer gewenst zijn (SH),
eisen die extra toegevoegd kunnen worden (CH) en eisen die (op het moment) niet
verstandig zijn om aandacht aan te besteden (WH). In de bijlage is de \[PvE\] te
vinden. Hieronder een verklaring van de genomen beslissingen.
Er is voor beide opleidingen een PvE gevormd met dezelfde inhoud, maar een
andere opstelling. Het was lastig om deze op dezelfde manier op te bouwen, want
voor beide opleidingen was er andere inhoud nodig om de resultaten te
presenteren.
#### Actieradius
De opdrachtgever gaf aan dat het voertuig een redelijke actieradius moet hebben.
Volgens hem was dit bijvoorbeeld dat het voertuig comfortabel vanaf Amsterdam
naar Rotterdam kan rijden. In overleg met de opdrachtgever is deze eis zeer
gewenst (SH), maar geen eis (MH).
Hiervoor zijn de eisen **REQ-A-6\[SH\]** en **REQ-A-7\[CH\]** toegevoegd. Er is
om aan de wensne te voldoen onderzocht wat de afstand tussen Rotterdam en
Amsterdam via de weg is. Deze bedraagt ongeveer 75 kilometer
^[[https://www.google.com/maps/dir/Amsterdam/Rotterdam/data=\!4m10\!4m9\!1m2\!1m1\!1s0x47c63fb5949a7755:0x6600fd4cb7c0af8d\!1m2\!1m1\!1s0x47c5b7605f54c47d:0x5229bbac955e4b85\!2m1\!1b1\!3e0?sa=X\&ved=1t:3747\&ictx=111](https://www.google.com/maps/dir/Amsterdam/Rotterdam/data=!4m10!4m9!1m2!1m1!1s0x47c63fb5949a7755:0x6600fd4cb7c0af8d!1m2!1m1!1s0x47c5b7605f54c47d:0x5229bbac955e4b85!2m1!1b1!3e0?sa=X&ved=1t:3747&ictx=111)].
Voor de ondergrens (SH) is er met deze informatie gekozen voor een actieradius
van minimaal 100 kilometer in ideale omstandigheden. Als extra doel (CH) is er
een eis toegevoegd voor een actieradius van 250 kilometer in ideale
omstandigheden.
#### Snelweg
Volgens de opdrachtgever moet het voertuig in theorie over de snelweg kunnen,
maar hoeft niet aan alle regelgevingen te voldoen.
Hiervoor is de eis **REQ-A-4\[MH\]** opgesteld. 60 km/h is de minimale snelheid
voor op de snelweg^[https://www.rijksoverheid.nl/onderwerpen/wegen/vraag-en-antwoord/wat-is-de-minimumsnelheid-voor-het-wegverkeer].
#### Stabilisatie {#stabilisatie}
Er moet actieve stabilisatie op komen.
#### Wielen {#wielen}
Beide wielen moeten gestuurd en aangedreven worden.
#### Gewicht voertuig {#gewicht-voertuig}
Het voertuig moet zo licht mogelijk zijn, zonder te veel weg te nemen van
gebruiksvriendelijkheid voor de bestuurder.
#### Semiautomatisch {#semiautomatisch}
Het voertuig moet uiteindelijk semiautomatisch kunnen rijden.
## Architectuur
Het diagram in figuur \ref{doc_units} is een overzicht van de units van dit project.
![Units\label{doc_units}](https://live.kladjes.nl/uploads/50d15f05-0809-46b7-a6af-1f2e01a62452.png)
### unit: Vehicle Control Unit (VCU)
De VCU heeft alle ingangen voor de bestuurder voor het sturen, gas geven en remmen.
Voor deze unit gelden de volgende eisen van het PvA:
**REQ-C-1[MH]**: het voertuig wordt bestuurd doormiddel van een elektronisch
input, zoals een joystick, die bedienbaar is door de bestuurder.
**REQ-C-2[MH]**: er is een noodstop aanwezig.
### unit: Stuur systeem
Zodat het voertuig niet alleen rechtuit kan rijden. Er is een nouwe samenwerking
geweest tussen cd VCU en het stuursysteem, omdat de zelfde hoofd persoon de
elektronica voor bijde units is.
Voor deze unit gelden de volgende eisen van het PvA:
**REQ-W-3[SH]**: het voertuig stuurt met beide wielen.
**REQ-W-8[MH]**: het voertuig heeft een draaicirkel van 6 meter in diameter of
minder.
### unit: Stabilisatie
De stabilisatie is om het voertuig rechtop te houden bij bijvoorbeeld het
wachten bij een kruispunt of een stoplicht.
Voor deze unit gelden de volgende eisen van het PvA:
**REQ-S-1[MH]**: Het voertuig wordt actief gestabaliseerd
**REQ-S-2[SH]**: Het voertuig kan uit zichzelf weer recht komen te zitten vanaf
een roll hoek van 5 graden
### unit: Aandrijving
De aandrijving zorgt ervoor dat het voertuig zichzelf kan voortbewegen op genoeg
snelheid zodat er veilig op de weg gereden kan worden. de VCU stuurt een signaal
voor accelereren of remmen.
Voor deze unit gelden de volgende eisen van het PvA:
**REQ-A-4[MH]**: Het voertuig is ontworpen zodat de maximale snelheid 60
kilometer per uur of sneller is.
**REQ-A-5[SH]**: Het voertuig is ontworpen zodat die 150 kilometer per uur of
sneller kan rijden in ideale omstandigheden.
**REQ-A-6[SH]**: Het voertuig is ontworpen zodat die 100 kilometer actieradius
of meer kan bereiken in ideale omstandigheden.
**REQ-A-7[CH]**: Het voertuig is ontworpen zodat die 250 kilometer actieradius
of meer kan bereiken in ideale omstandigheden.
## Vehicle Control Unit (VCU) / Stuursysteem
De VCU is een belangrijk onderdeel van het systeem, hiermee kunnen we het
voertuig in een richting sturen en vooruit bewegen. De belangrijkste keuzes
hierin zijn in welke taal we willen gaan programmeren en wat voor soort
microcontroller we willen. De reden hiervoor is zodat de volgende team
makkelijker kan omgaan met de code en het systeem makkelijker kunnen uitbreiden.
Het makkelijkst is dan om met de Arduino IDE en framework verder te gaan, omdat
het een bekent en veel gedocumenteerd systeem is waar je veel over kan vinden op
internet tegenover veel andere IDE's, programmeertalen en microcontrollers.
Verder moet het ook draadloos verbinding kunnen maken met een console controller
zodat de volgende teams eventueel een andere keuze kunnen maken hoe ze willen
sturen. Daarom hebben we voor de ESP32 gekozen omdat het alles aantikt met een
gezond aantal GPIO pinnen.
### 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.
| Parameter | Waarde | Eenheid | Opmerking |
| ---------------------- | ------------- | -------- | ------------------------------------------------------------- |
| Voertuig-spanning | 12 - 14 | $V_{DC}$ | typisch voor auto-VCU's |
| Stuurspanning-demperkle | 0 - 5 | $V_{DC}$ | naloge regeling |
| PWM-signaal frequentie | 25000 - 30000 | $Hz$ | Typische range voor aansturing |
| PWM duty cycle | 10 - 90 | $\%$ | $10\%$: minimale demping, $90\%$: maximale demping^[demping voor de ophanging via de interne actuator demper] |
| Stroomverbruik klep | 0.5 - 2 | $A$ | Afhankelijk van de interne weerstand |
| Wielsnelheid | 0 - 250 | $km/h$ | Meet snelheid per wiel |
| Karrosserie-versnelling | -3 tot +3 | $g$ | Laterale en verticale versnellingen |
| Axiale potentiometer (veerweg) | 0 - 50 | $mm$ | Meet veeruitslag |
| Temperatuur werkbereik | -40 tot +85 | $^\circ C$ | Automobielstandaard |
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. om de actuator te besturen gebruiken we een motordriver, de
MDD20A. Dit is omdat we het al hebben en werkt met de huidige actuatoren en
voldoende de parameters van de actuatoren behaald, daarom hebben we besloten om
niet een nieuwe te kopen of te ontwerpen. Om ervoor te zorgen dat de actuatoren
niet te ver gaan gebruiken we de AS5600 magnetic encoder. Dit is omdat de
encoder een absoluut positie meegeeft en daarom voor minder problemen zorgt als
het voertuig opnieuw opstart.
## Stabilisatie
De groepen voor ons hebben al een klein schaal model voor een reactiewiel
gemaakt en een vliegwiel opstelling, wat volledige schaal lijkt te zijn, gemaakt.
Documentatie over de vliegwiel opstelling hebben wij niet terug gevonden. Maar
wel van het kleine schaal model, de reactiewiel opstelling is pas aan het einde van het project gevonden - Voor onze opvolgers, in het Proto Lab tussen de planten en de 3D
printers is de linker kast - De reactiewiel opstelling is later gemaakt dan de vliegwiel opstelling, er was dus blijkbaar een reden geweest dat de vliegwiel opstelling niet geschikt was. De automotive engineers onder ons hebben berekent wat de beste keuze is.
Dit heeft even geduurd, ondertussen zijn de elektronische engineers onderzoek gedaan naar wat voor soort motor drivers er zijn.
Uiteindelijk kwamen de automotive engineers uit op een vliegwiel van $10kg$ met een kracht van $45Nm$ en een maximale snelheid van $1000rpm$.
### De Motor
Het is er een die gevonden is op Aliexpress, niet een heel erg betrouwbare
verkoper, maar we kunnen geen andere geschikte vinden voor een redelijke prijs.
Er is wel test data beschikbaar waar een rekenmodel mee gemaakt kan worden.
Deze motor kan de kracht net niet continu aan, maar wel voor korte duur. De
snelheid is wel iets ingeperkt ten opzichte van de berekende $1000 rpm$ dat
nodig is, deze kan maar tot $875 rpm$. Dit is de reden geweest dat we geen motor
gaan inkopen, maar een testen met een motor uit de voorraad. Deze zal
waarschijnlijk niet voldoende vermogen kunnen halen, maar we kunnen wel testen
of het concept werkt voordat er grote bedragen uitgegeven gaan worden aan een
geschikte motor.
De specificaties van de motor:
- $K_T = 0.15 Nm/A$ - motor koppel constante
- $I_{noload} = 3.52 A$ - Stroom verbruik bij geen koppel
- $K_v = 69 rpm/V$ - motor snelheidsconstante
- $V_{th} = 598 mV$ - threshold voltage
- $I_{max} = 78.5 A$ - maximaal stroom verbruik voor onze applicatie ($11.2Nm$ met 1:4 gearbox)
- $U_{max} = 72 V$ - maximaal spanning benodigd voor onze applicatie
berekeningen voor deze waardes staan in het Detailontwerp Stabilisatie in
hoofdstuk [Motor Keuze](#motor-keuze) (zie bijlagen)
> Er is helaas iets fout gegaan bij de berekeningen die eerder gedaan hebben om de
> specificaties vast te stellen. Er is per ongeluk met $25 Nm$ gerekend i.p.v.
> $45 Nm$. Dit betekent dat de motor driver is ontworpen voor $50 A$ i.p.v.
> $80A$. Dit kan opgelost worden door een motor gearbox combinatie die te vinden is
> met $50A$ maar met een hogere spanning het vermogen haalt. Er is veel ruimte
> aan spanning, dus dit zal oplosbaar moeten zijn.
### Motor Driver
#### specificaties
- De drijver moet minimaal $72 V$ aan kunnen, met voorkeur van meer dan $120 V$ [^1]
De $120V$ komt van de vorige groep die aan dit project hebben gewerkt. Dit is de
spanning van de accu die zij hadden gebruikt om dingen mee te berekenen. Er is
nog geen besluit wat deze spanning werkelijk gaat worden.
- De drijver moet minimaal $50 A$ continu kunnen leveren (wat eigenlijk $80 A$
had moeten zijn) [^1]
- Maakt gebruik van Field Oriented Control, om het volledige vermogen te kunnen
halen vanaf stilstand.
- De hoek van het voertuig moet gemeten worden.
- Er is een regel loop tussen de hoek sensor en de kracht van de motor.
- Er is een SPI-client connector waarmee verschillende instellingen ingesteld
mee kan worden, waaronder het maximaal vermogen.
[^1]: Er wordt tot $50 V$ getest, voor deze waardes wordt het ontworpen, maar niet tot het limiet getest.
Met deze specificaties is het erg lastig om een motor driver voor te vinden. Zo
lastig dat - zonder een bedrijf één te laten ontwerpen - we er geen gevonden
hebben. Hierom is gekozen om zelf een motor driver te ontwerpen.
De SPI-client is afgesproken met de andere elektrotechnische ingenieurs als
algemeen communicatie protocol nadat was besloten om een eigen motor driver te
ontwerpen.
#### Ontwerp
Het ontwerp is gemaakt door Finley, zij heeft op haar stage al een motor driver
ontworpen. Hier heeft ze heel veel geleerd over het ontwerpen van een motor
driver. Hier komt ook veel van de kennis vandaan. Deze motordriver is niet
gebaseerd op die motor driver, deze kan maar $3A$ aan, dus compleet opnieuw
beginnen is makkelijker.
##### Half-bridges
De motor is een BLDC motor de volledige naam is een permanent magneet
borstelloze 3 fase synchrone motor. Dit betekent dat er permanente magneten in
zitten, geen borstels, aangestuurd met 3 fase en synchrone draait met deze 3
fases.
De motor driver wordt gevoed van een accu, dus DC. Om deze synchrone 3 fases te
genereren zijn drie half-brdiges nodig. Een voor elke fase.
Voor de FET's voor deze Half-bridges is gekozen voor de EPC2307, Dit zijn
GaNFET's in tegenstelling to de vaker gebruikte MOSFET's. MOSFET fabrikanten
hebben een gewoonte om de maximale stroom te berekenen met perfecte koeling. Dit
is dus niet realistisch haalbaar. Om achter te komen wat wel haalbaar is is een
thermal analyses nodig, dit is grof weg gedaan voor een redelijk wat MOSFET's,
maar geen enkel was geschik om de $50A$ te schakelen. EPC (Efiction Power
Converter; de fabrikant van de EPC2307) is een van de weinige fabrikanten wel
een realistisch beeld van de maximale stroom.
Om te bevestigen is een berekening vermaakt hoeveel de FET's aan vermogen
verliezen in deze applicatie. Dit is gedaan met de volgende formule.
$$
P_{loss} = I^2R_{DS(on)} + \frac{UIt}{2} \cdot 2f_s
$$
$I$: stroom
$U$: voedingsspanning
$t$: schakeltijd
$f_s$: de schakel frequentie
$U = 120V$, $I = 50A$ (uit specificaties motor driver)
$t = 4 ns$ (berekent in simulatie)
$f_s = 50 kHz$ (frequentie is gekozen omdat die buiten menselijk gehoor licht)
$P_{loss} = 26.2 W$.
Deze formule is erg pessimistisch, deze gaat uit van $100\%$ PWM terwel de
uitgang een sinus is dus gemiddeld is het altijd $50\%$ en de schakelverliezen
worden ook overschat. Voor meer informatie over deze berekening zie bijlagen
Detailontwerp Stabilisatie hoofdstuk [Verliezen in de FET](#verliezen-in-de-fet)
> Voor meer informatie over hoe de vermogens filtering is gedaan zie bijlagen
Detailontwerp Stabilisatie hoofdstuk [Power Filtering](#power-filtering)
##### Sensoren
Er zijn drie sensoren nodig, stroom meting, positie van de motor en de hoek van
het voertuig.
###### stroom meting
De stroom meting wordt gedaan met de ACS724xLCTR-50AB. Dit is een stroom meting
IC die van $-50A$ tot $+50A$ kan meten. Deze komt tussen de motor en de uitgang
van de half-bridges. Het is ook mogelijk om aan de lage FET in de half-bridge te
meten met een shunt, maar omdat het nog niet heel duidelijk is hoe het FOC
algoritme werkt, lijkt dit een makkelijkere manier om het algoritme te
implementeren.
Er is niet gekozen voor een shunt met een versterker, omdat er $200V$ op deze
uitgang komt te staan. De versterkers die dit aankunnen zijn erg duur en de
ACS724xLCTR-50AB wordt dan een goedkopere optie.
###### Hoek van de motor
de motor hoek is nodig voor FOC. Hoe nauwkeuriger deze sensor is hoe efficiënter
FOC wordt. De AS5600 is zowel makkelijk te monteren als nauwkeurig zonder dat
die elke keer bij het opstarten hoeft gekalibreerd hoeft te worden.
> Meer informatie waarom deze keuze is gemaakt, zie de bijlagen Detailontwerp
Stabilisatie hoofdstuk Encoder
###### Hoek van het voertuig
Een MEMS Gyroscoop kan verandering in de hoek meten, deze is erg snel hierin
maar bij afwijking verliest die de nul positie. Hiervoor is een combinatie
gekozen met een MEMS-acceleratiemeter. Deze kan met de zwaartekracht meten
zolang het voertuig niet te veel beweerd.
Om het makkelijk te maken is er gekozen voor de M5Stack IMU Pro Mini. Deze is
makkelijk te monteren, omdat die al in een behuizing zit met montage gaten. Deze
sensor komt met de BMI270 van Bosch die zowel een MEMS-acceleratiemeter als
gyroscoop heeft.
> Meer informatie warom deze keuze is gemaakt, zie bijlagen Detailontwerp
Stabilisatie hoofdstuk [Hoek Sensor](#hoek-sensor)
#### Productie en Testen Hardware
De PCB en stencil zijn geproduceerd door JLCPCB en de componenten zijn geplaatst
en in de reflow oven gegaan in het SMD-lab op Accademiplein.
Na dat die uit de over kwam zijn er een aantal soleer balletjes weggehaald, twee
soldeer bruggen weg gehaald bij een van de gate driver IC's en de
microcontroller opnieuw met de hand erop geplast. De microcontroller had te veel
tin op de grondpad aan de onderkant, waardoor deze omhoog kwam en de pinnen aan
de zijkant boven de PCB zweefde onder contact.
Tot hoever er getest is werkt alles, de FET's schakelen en de PWM wordt correct
gegenereerd. Helaas heb ik geen foto's van de scope kunnen maken, ik had beide
handen vol met de probes en het lukte me niet om met mijn neus de scope te
triggeren. Ik ga maandag 23 juni iemand om hulp vragen terwijl ik verder ga
testen.
> [!todo]
> latere testen toevoegen.
#### Software
De Software is geschreven in Rust, deze keuze is gemaakt door de beschikbaarheid an FOC library's.
Er is meer te vinden over de software inclusie onderbouwing waarom keuzes zijn gemaakt in bijlagen ...
> [!todo]
> software in rust, git, software documentatie?
#### Advies
> [!todo]
> upgrade to RP2350, RTIC (wegens I2C salve support), mcu aan de andere kant van de morot conn
## Project Verloop
Aan het begin was het vooral lastig om duidelijk te maken wat de vereisten van
beide opleidingen en tot een format te komen van het Plan van Aanpak en Pakket
van eisen die voor beide opleidingen voldoet. Het is ons niet gelukt om tot een
enkel Pakket van Eisen te komen, bij Automotive moet het in een Exel bestand.
Dit is alleen lastig om te exporteren naar bestand dat geschikt is om te kunnen
ondertekenen. Daarbij is het ook lastig om er onderbouwing van de eisen bij te
zetten, dit is niet nodig voor Automotive.
We hebben uiteindelijk ons eigen Pakket van Eisen gemaakt op onze manier en deze
vertaalt naar een Exel bestand voor Automotive.
Na deze twee documenten zijn er geen conflicten geweest tussen de eisen van
Elektrotechniek en Automotive.
Een van de projectleden, Mohamed, is erg weinig komen opdagen. En heeft de drie
waarschuwingen gekregen dat volgens de samenwerkingsovereenkomst dat wij hebben
opgesteld en getekend (inc. Mohamed), waar na die uit de groep gezet kan worden.
i.p.v. dit direct te doen hebben wij als groep samen met Joris Straver een
gesprek gehad, wat er toe heeft geleden dat die de groep heeft verlaten. Rond
deze tijd had Gryvon ook aangegeven dat die de groep verliet wegen te veel
stress met andere vakken.
Vanaf school week 4.1 waren we totaal nog maar met 5 personen i.p.v. 7. Dit
heeft er tot geleid dat de aandrijving van de wielen hebben laten vallen en de
motor driver voor de stabilisatie wat is uitgelopen.
## bijlagen
![Plan van Aanpak](plan_van_aanpak.md)
![Pakket van Eisen](pakket_van_eisen.md)
![Detailonwerp Stabilisatie](detailontwerp_stabilisatie.md)
![Softwareontwerp Stabilisatie](softwareontwerp_stabilisatie.md)
![Unit Testen Stabilisatie](unittest_stabilisatie.md)

View File

@@ -0,0 +1,73 @@
---
sub_title: Superlight Personal Carrier
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
- name: "Chris Tan"
email: "0992143@hr.nl"
name_short: "c. Tan"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
- name: "Max Kappert"
email: "1030682@hr.nl"
name_short: "m. Kappert"
- name: "Thomas Braam"
email: "0989527@hr.nl"
name_short: "t. Braam"
---
# Softwareontwerp Sabilisatie
## inleiding
> [!TODO]:
> schrijven
## FoC library
In C zijn er niet veel librarys voor FOC, de enige goede library die we hebben
gevonden is [SimpleFOCproject](https://www.simplefoc.com/). Dit komt er in
de buurt van een framework. In de video van de homepagina worden een aantal
gemeenschapsprojecten laten zien, waarvan meerdere een reactiewiel voor
sabilisatie laat zien. Dit belooft veel goeds, toch is er gekozen om een andere
library te kiezen. Het goed implementeren van een regel kring met de IMU vraagt
veel kennis van hoe dit 'framework' werkt. Onze implementatie is niet exact het
zelfde als die van deze gemeenschapsprojecten. Wij hebben dus de kennis nodig
om deze code aan te passen.
Er is gekozen om te werken met de [Rust library FOC](https://lib.rs/crates/foc).
Deze library is alleen een implementatie voor het FOC algaritme, waardoor er meer
flexibilitijd is hoe het systeem verder werkt. Dit kan dus ook verder
geoptimaliseerd worden en meer geconfigureerd. dat tweede is de grootste reden
waarom voor deze library is gekozen. Er is behoefte aan een systeem dat aangepast
kan worden naar wat later beter blijkt te zijn.
## Rust op RP2040
Rust voor microcontrollers is nog in een soort alpha versie. Het grootste deel is al stable, maar hier en daar zijn nog wat beperkingen. Vrijwel al deze
beperkingen hebben een workaround. Het grootste voordeel is dat er een 'officele'
standaard is voor het HAL interface^[embeded-hal: [https://docs.rs/embedded-hal](https://docs.rs/embedded-hal)].
Dit zorgt er voor dat er veel library's beschikbaar zijn die
gewoon werken.
## Async
De standaard async funtionalitijd in rust werkt nog niet voor
microcontrollers^[[https://www.youtube.com/watch?v=H7NtzyP9q8E](https://www.youtube.com/watch?v=H7NtzyP9q8E)].
Hier zijn wel alternative librarys voor^[[https://arewertosyet.com/](https://arewertosyet.com/)],
Embassy^[[https://embassy.dev/](https://embassy.dev/)] en RTIC^[[https://rtic.rs](https://rtic.rs)]
zijn de twee die het meest genoemd worden. Embassy ziet er wat eenvoudiger uit
als RTIC, daarvoor is ook gekozen om te gebruiken.
## AS5600
Er wordt gebruik gemaakt de AS5600 library van Rafael Bachmann^[[https://github.com/barafael/as5600-rs](https://github.com/barafael/as5600-rs)].
##

View File

@@ -0,0 +1,178 @@
---
sub_title: Superlight Personal Carrier
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Finley van Reenen"
email: "0964590@hr.nl"
name_short: "e.l.f. van Reenen"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
---
## Unit Testen Stabilisatie
### 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$ | $3.3V$ |
| -------- | -------:| --------:|
| minimaal | $4.5V$ | $3.0V$ |
| maximaal | $5.5V$ | $3.6V$ |
| gemeeten | $5.01V$ | $3.323V$ |
Geslaagd: ja
opmergingen: in idel de er wordt $28mA$ aan stroom verbruikt vanaf de $12V$ voeding
### 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 ledje knippert
Geslaagd: ja
opmergingen: getest met een PWM signaal en osciloscoop i.p.v. een ledje.
### Half-brug
#### Benodigdheden
- als de microcontroller werkt:
- $12V$ voeding als de voedingen werken, anders met een $5V$ en $3.3v$ voeding
- $30V$ voor _V Motor_
- computer met Arduino IDE geïnstalleerd
- USB B kabel naar de computer
- oscilloscope
- zo niet:
- $10V$ voor _V motor_
- signaal generator met twee kanalen
- oscilloscope
#### procedure
1. sluit de oscilloscope 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, zet de voeding voor _V motor_ wat lager)
2. snel de voeding in op $12V$ met een stroom begrenzing van $150 mA$
3. sluit de $12V$ voeding aan op de $12V$ en GND ingangen 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 programma die de PWM aanstuurt voor de FET's
- de PWM per half bridge zijn aangesloten op de a en b uitgangen van 1 timer per half brug. zorg dat een van de uitgangen geïnverteerd is en de twee vergelijk waardes zo zijn zodat er een korte dead time is. ze mogen nooit tegelijkertijd hoog zijn!
6. bekijk het signaal op de oscilloscope
7. herhaal de test voor alle drie de half bruggen
resultaat:
- brug a:
![](https://live.kladjes.nl/uploads/305bb926-d062-4601-ac91-1cad3a7d79e2.png)
- brug b:
![](https://live.kladjes.nl/uploads/4366b2e4-7742-4b9b-91dd-d2695e267462.png)
- brug c:
![](https://live.kladjes.nl/uploads/c1afebd0-99ae-40f1-97ef-2cf6404489b2.png)
Geslaagd: ja
opmerkingen: Er is een klein beetje ringing, maar het lijkt nog niet te veel dat dit problemen kan veroorzaken.
### 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 stroom 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:

View File

@@ -0,0 +1,66 @@
---
sub_title: Superlight Personal Carrier
tags:
- kladjes
- elektro
- elektro/hr
- elektro/hr/pee51
auther:
- name: "Chris Tan"
email: "0992143@hr.nl"
name_short: "c. Tan"
- name: "Tijn Snijders"
email: "1001829@hr.nl"
name_short: "t. Snijders"
- name: "Max Kappert"
email: "1030682@hr.nl"
name_short: "m. Kappert"
- name: "Thomas Braam"
email: "0989527@hr.nl"
name_short: "t. Braam"
---
# unit testen Stuur systeem
## unit test controller
- computer met Arduino IDE geinstaleerd
- een USB-C kabel aangesloten van de microcontroller naar een computer
- een controller om het voertuig mee te besturen
1. Upload het programma naar de esp32
2. pair de controller via bluetooth met de esp32
3. check voor de waardes op je computer
4. druk knoppen in en beweeg joysticks
5. kijk of er waardes binnenkomen.
de test is geslaagd wanneer alle knoppen consistent een waarde terug kunnen sturen naar de terminal van de Arduino IDE
## unit test Actuator
- voeding die minimaal 24 volt aankan
- computer met Arduino IDE geinstaleerd
- een USB-C kabel aangesloten van de microcontroller naar een computer
- een controller om het voertuig mee te besturen
1. sluit de voeding aan op de motorcontroller met 24 volt en een stroombegrensing van 2A
2. verbind de PWM en DIR pinnen tussen de eps32 en motorcontroller
3. pair de controller met de esp32
4. beweeg de linker joystick van links naar rechts.
5. check de reactie van het wiel
de test is geslaagd wanneer de controller het wiel links en rechts kan draaien en het wiel stopt in de aangegeven richting en niet te zijn eigen grens overschrijt.
## integratie test VCU
- computer met Arduino IDE geinstaleerd
- een USB-C kabel aangesloten van de microcontroller naar een computer
- een controller om het voertuig mee te besturen
1. sluit de de motor en de stabilisatie units met de VCU
2. pair de controller met de esp32
3. beweeg de rechter joystick omhoog en omlaag
4. check de reactie met het wiel en de stabilisator
de test is geslaagd wanneer de controller de motor kan aansturen en de stabilisatie zijn vermogen kan varieren gebaseerd op het wiel

49
pull_from_hd.sh Executable file
View File

@@ -0,0 +1,49 @@
#!/bin/bash
server='https://live.kladjes.nl'
main_index_id="tPb3Up1fQEuZ86yrJSkYRQ"
cli_url="https://raw.githubusercontent.com/hedgedoc/cli/refs/heads/master/bin/hedgedoc"
HEDGEDOC_SERVER="$server"
if [ ! -f "./hedgedoc" ]; then
curl $cli_url -o "./hedgedoc"
chmod +x "./hedgedoc"
fi
. ./hedgedoc --import
function download_cli() {
if [ ! -f "$hd_cli" ]; then
curl $cli_url -o "$hd_cli"
chmod +x "$hd_cli"
fi
}
function get_md() {
local note_id="$1"
local out_path="$2"
echo "get_md: '$note_id' '$out_path'"
export_note --md "$note_id" "$out_path"
}
function get_index() {
local note_id="$1"
local out_dir="$2"
local index_file="$(mktemp)"
echo "get_index: '$note_id' '$out_dir'"
get_md "$note_id" "$index_file"
# get all unsorted list line (`^- `) that have a link with lable ending with '.md'
local index=$(cat "$index_file" | grep -e '^- \[[^\}]*\.md\]' | sed -e 's/^.*\[\(.*\)\](\(.*\))/\1=\2/')
rm "$index_file"
for f in $index
do
local name="$(echo "$f" | sed -e 's/=.*$//')"
local id="$(echo "$f" | sed -e 's/^.*=//' | tr -dc '[:alnum:]-_')"
get_md "$id" "$out_dir/$name"
done
}
# mkdir -p "./out"
get_index "$main_index_id" "./markdown"

50
push_to_hd.sh Executable file
View File

@@ -0,0 +1,50 @@
#!/bin/bash
server='https://live.kladjes.nl'
main_index_id="tPb3Up1fQEuZ86yrJSkYRQ"
cli_url="https://raw.githubusercontent.com/hedgedoc/cli/refs/heads/master/bin/hedgedoc"
HEDGEDOC_SERVER="$server"
if [ ! -f "./hedgedoc" ]; then
curl $cli_url -o "./hedgedoc"
chmod +x "./hedgedoc"
fi
. ./hedgedoc --import
function get_md() {
local note_id="$1"
local out_path="$2"
echo "get_md: '$note_id' '$out_path'"
export_note --md "$note_id" "$out_path"
}
function push_md() {
local note_id="$1"
local src_path="$2"
echo "push_md: '$src_path' '$note_id'"
import_note "$src_path" "$note_id"
}
function get_index() {
local note_id="$1"
local src_dir="$2"
local index_file="$(mktemp)"
echo "get_index: '$note_id' '$src_dir'"
get_md "$note_id" "$index_file"
# get all unsorted list line (`^- `) that have a link with lable ending with '.md'
local index=$(cat "$index_file" | grep -e '^- \[[^\}]*\.md\]' | sed -e 's/^.*\[\(.*\)\](\(.*\))/\1=\2/')
rm "$index_file"
for f in $index
do
local name="$(echo "$f" | sed -e 's/=.*$//')"
local id="$(echo "$f" | sed -e 's/^.*=//' | tr -dc '[:alnum:]-_')"
push_md "$id" "$src_dir/$name"
done
}
user_login --email kladjes@finnvanreenen.nl
get_index "$main_index_id" "./markdown"